error-messages

# Error Message Style Guide Use this format for gh-aw validation errors. Keep messages clear, actionable, and example-driven. ## Error Message Template ``` [what's wrong]. [what's expected]. [example of correct usage] ``` Make each error message answer three questions: 1. **What's wrong?** - Clearly state the validation error 2. **What's expected?** - Explain the valid format or values 3. **How to fix it?** - Provide a concrete example of correct usage ## Constructive Language Avoid standalone negative wording. Pair it with expected behavior and a concrete fix. | Avoid only-negative wording | Prefer constructive wording | |---|---| | `invalid` | `expected` + valid format/options | | `cannot` | `requires` + precondition | | `must` | `should` + example | | `failed` | action context + recovery step | ❌ `invalid repo format: %s` ✅ `invalid repo format '%s' — expected 'owner/repo' format (for example: 'github/gh-aw')` ❌ `not in a git repository` ✅ `not in a git repository — run 'git init' or 'cd' to a git repository` ## When to use `NewValidationError` vs `fmt.Errorf` - Use `NewValidationError(field, value, reason, suggestion)` in `*_validation.go` logic. - Use `field` for the exact config path - Use `reason` for what failed - Use `suggestion` for an actionable fix with an example - Use `fmt.Errorf` for operational/wrapping errors (`%w`) where you are propagating a lower-level failure with context. - Avoid generic wrappers like `fmt.Errorf("failed to X: %w", e...