Add validation and interactive guidance to /create-capability

Integrates the validation features from issue #76 into the existing command.

- Add interactive guidance for component type selection
- Add model selection recommendations based on task complexity
- Add frontmatter validation (required fields, valid values)
- Add content validation (trigger conditions, steps, behavior)
- Add convention checks and anti-pattern warnings
- Add clear error messages and warning override option

Closes #76

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

agents/code-reviewer/AGENT.md

@@ -17,18 +17,67 @@ You are a code review specialist that provides immediate, structured feedback on
 You will receive a PR number to review. Follow this process:
 
 1. Fetch PR diff: checkout with `tea pulls checkout <number>`, then `git diff main...HEAD`
-2. Analyze the diff for issues in these categories:
+2. Detect and run project linter (see Linter Detection below)
+3. Analyze the diff for issues in these categories:
    - **Code Quality**: Readability, maintainability, complexity
    - **Bugs**: Logic errors, edge cases, null checks
    - **Security**: Injection vulnerabilities, auth issues, data exposure
-   - **Style**: Naming conventions, formatting, consistency
+   - **Lint Issues**: Linter warnings and errors (see below)
    - **Test Coverage**: Missing tests, untested edge cases
-3. Generate a structured review comment
-4. Post the review using `tea comment <number> "<review body>"`
+4. Generate a structured review comment
+5. Post the review using `tea comment <number> "<review body>"`
    - **WARNING**: Do NOT use heredoc syntax `$(cat <<'EOF'...)` with `tea comment` - it causes the command to be backgrounded and fail silently
    - Keep comments concise or use literal newlines in quoted strings
-5. **If verdict is LGTM**: Merge with `tea pulls merge <number> --style rebase`, then clean up with `tea pulls clean <number>`
-6. **If verdict is NOT LGTM**: Do not merge; leave for the user to address
+6. **If verdict is LGTM**: Merge with `tea pulls merge <number> --style rebase`, then clean up with `tea pulls clean <number>`
+7. **If verdict is NOT LGTM**: Do not merge; leave for the user to address
+
+## Linter Detection
+
+Detect the project linter by checking for configuration files. Run the linter on changed files only.
+
+### Detection Order
+
+Check for these files in the repository root to determine the linter:
+
+| File(s) | Language | Linter Command |
+|---------|----------|----------------|
+| `.eslintrc*`, `eslint.config.*` | JavaScript/TypeScript | `npx eslint <files>` |
+| `pyproject.toml` with `[tool.ruff]` | Python | `ruff check <files>` |
+| `ruff.toml`, `.ruff.toml` | Python | `ruff check <files>` |
+| `setup.cfg` with `[flake8]` | Python | `flake8 <files>` |
+| `.pylintrc`, `pylintrc` | Python | `pylint <files>` |
+| `go.mod` | Go | `golangci-lint run <files>` or `go vet <files>` |
+| `Cargo.toml` | Rust | `cargo clippy -- -D warnings` |
+| `.rubocop.yml` | Ruby | `rubocop <files>` |
+
+### Getting Changed Files
+
+Get the list of changed files in the PR:
+
+```bash
+git diff --name-only main...HEAD
+```
+
+Filter to only files matching the linter's language extension.
+
+### Running the Linter
+
+1. Only lint files that were changed in the PR
+2. Capture both stdout and stderr
+3. If linter is not installed, note this in the review (non-blocking)
+4. If no linter config is detected, skip linting and note "No linter configured"
+
+### Example
+
+```bash
+# Get changed TypeScript files
+changed_files=$(git diff --name-only main...HEAD | grep -E '\.(ts|tsx|js|jsx)$')
+
+# Run ESLint if files exist
+if [ -n "$changed_files" ]; then
+  npx eslint $changed_files 2>&1
+fi
+```
 
 ## Review Comment Format
 
@@ -54,8 +103,11 @@ Post reviews in this structured format:
 #### Security Concerns
 - [Finding or "No issues found"]
 
-#### Style Notes
-- [Finding or "Consistent with codebase"]
+#### Lint Issues
+- [Linter output or "No lint issues" or "No linter configured"]
+
+Note: Lint issues are stylistic and formatting concerns detected by automated tools.
+They are separate from logic bugs and security vulnerabilities.
 
 #### Test Coverage
 - [Finding or "Adequate coverage"]
@@ -67,12 +119,16 @@ Post reviews in this structured format:
 ## Verdict Criteria
 
 - **LGTM**: No blocking issues, code meets quality standards, ready to merge
-- **Needs Changes**: Minor issues worth addressing before merge
+- **Needs Changes**: Minor issues worth addressing before merge (including lint issues)
 - **Blocking Issues**: Security vulnerabilities, logic errors, or missing critical functionality
 
+**Note**: Lint issues alone should result in "Needs Changes" at most, never "Blocking Issues".
+Lint issues are style/formatting concerns, not functional problems.
+
 ## Guidelines
 
 - Be specific: Reference exact lines and explain *why* something is an issue
 - Be constructive: Suggest alternatives when pointing out problems
 - Be kind: Distinguish between blocking issues and suggestions
 - Acknowledge good solutions when you see them
+- Clearly separate lint issues from logic/security issues in your feedback

agents/issue-worker/agent.md

@@ -1,6 +1,10 @@
 ---
 name: issue-worker
 description: Autonomous agent that implements a single issue in an isolated git worktree
+# Model: sonnet provides balanced speed and capability for implementation tasks.
+# Implementation work benefits from good code understanding without requiring
+# opus-level reasoning. Faster iteration through the implement-commit-review cycle.
+model: sonnet
 tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite
 skills: gitea, issue-writing, software-architecture
 ---

agents/pr-fixer/agent.md

@@ -1,6 +1,10 @@
 ---
 name: pr-fixer
 description: Autonomous agent that addresses PR review feedback in an isolated git worktree
+# Model: sonnet provides balanced speed and capability for addressing feedback.
+# Similar to issue-worker, pr-fixer benefits from good code understanding
+# without requiring opus-level reasoning. Quick iteration on review feedback.
+model: sonnet
 tools: Bash, Read, Write, Edit, Glob, Grep, TodoWrite, Task
 skills: gitea, code-review
 ---

commands/commit.md

@@ -0,0 +1,86 @@
+---
+description: Create a commit with an auto-generated conventional commit message. Analyzes staged changes and proposes a message for approval.
+argument-hint:
+---
+
+# Commit Changes
+
+## Process
+
+1. **Check for staged changes**:
+   ```bash
+   git diff --staged --stat
+   ```
+
+   If no staged changes, inform the user and suggest staging files first:
+   - Show unstaged changes with `git status`
+   - Ask if they want to stage all changes (`git add -A`) or specific files
+
+2. **Analyze staged changes**:
+   ```bash
+   git diff --staged
+   ```
+
+   Examine the diff to understand:
+   - What files were changed, added, or deleted
+   - The nature of the changes (new feature, bug fix, refactor, docs, etc.)
+   - Key details worth mentioning
+
+3. **Generate commit message**:
+
+   Create a conventional commit message following this format:
+   ```
+   <type>(<scope>): <description>
+
+   [optional body with more details]
+
+   Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+   ```
+
+   **Types:**
+   - `feat`: New feature or capability
+   - `fix`: Bug fix
+   - `refactor`: Code restructuring without behavior change
+   - `docs`: Documentation changes
+   - `style`: Formatting, whitespace (no code change)
+   - `test`: Adding or updating tests
+   - `chore`: Maintenance tasks, dependencies, config
+
+   **Scope:** The component or area affected (optional, use when helpful)
+
+   **Description:**
+   - Imperative mood ("add" not "added")
+   - Lowercase first letter
+   - No period at the end
+   - Focus on the "why" when the "what" is obvious
+
+4. **Present message for approval**:
+
+   Show the proposed message and ask the user to:
+   - **Approve**: Use the message as-is
+   - **Edit**: Let them modify the message
+   - **Regenerate**: Create a new message with different focus
+
+5. **Create the commit**:
+
+   Once approved, execute:
+   ```bash
+   git commit -m "$(cat <<'EOF'
+   <approved message>
+   EOF
+   )"
+   ```
+
+6. **Confirm success**:
+
+   Show the commit result and suggest next steps:
+   - Push to remote: `git push`
+   - Continue working and commit more changes
+
+## Guidelines
+
+- Only commits what's staged (respects partial staging)
+- Never auto-commits without user approval
+- Keep descriptions concise (50 chars or less for first line)
+- Include body for non-obvious changes
+- Always include Co-Authored-By attribution

commands/dashboard.md

@@ -1,13 +1,88 @@
 ---
 description: Show dashboard of open issues, PRs awaiting review, and CI status.
+# Model: haiku is sufficient for fetching and displaying data.
+# This command only reads from Gitea and formats output - no complex reasoning needed.
+model: haiku
 ---
 
 # Repository Dashboard
 
 @~/.claude/skills/gitea/SKILL.md
 
-Fetch and display:
-1. All open issues
-2. All open PRs
+Fetch and display the following sections:
 
-Format as tables showing number, title, and author.
+## 1. Open Issues
+
+Run `tea issues` to list all open issues.
+
+Format as a table showing:
+- Number
+- Title
+- Author
+
+## 2. Open Pull Requests
+
+Run `tea pulls` to list all open PRs.
+
+Format as a table showing:
+- Number
+- Title
+- Author
+
+## 3. CI Status (Recent Workflow Runs)
+
+Run `tea actions runs` to list recent workflow runs.
+
+**Output formatting:**
+- Show the most recent 10 workflow runs maximum
+- For each run, display:
+  - Status (use indicators: [SUCCESS], [FAILURE], [RUNNING], [PENDING])
+  - Workflow name
+  - Branch or PR reference
+  - Commit (short SHA)
+  - Triggered time
+
+**Highlighting:**
+- **Highlight failed runs** by prefixing with a warning indicator and ensuring they stand out visually
+- Example: "**[FAILURE]** build - PR #42 - abc1234 - 2h ago"
+
+**Handling repos without CI:**
+- If `tea actions runs` returns "No workflow runs found" or similar, display:
+  "No CI workflows configured for this repository."
+- Do not treat this as an error - simply note it and continue
+
+## Output Format
+
+Present each section with a clear header. Example:
+
+\`\`\`
+## Open Issues (3)
+
+| #  | Title                  | Author |
+|----|------------------------|--------|
+| 15 | Fix login timeout      | alice  |
+| 12 | Add dark mode          | bob    |
+| 8  | Update documentation   | carol  |
+
+## Open Pull Requests (2)
+
+| #  | Title                  | Author |
+|----|------------------------|--------|
+| 16 | Fix login timeout      | alice  |
+| 14 | Refactor auth module   | bob    |
+
+## CI Status
+
+| Status      | Workflow | Branch/PR   | Commit  | Time    |
+|-------------|----------|-------------|---------|---------|
+| **[FAILURE]** | build    | PR #16      | abc1234 | 2h ago  |
+| [SUCCESS]   | build    | main        | def5678 | 5h ago  |
+| [SUCCESS]   | lint     | main        | def5678 | 5h ago  |
+\`\`\`
+
+If no CI is configured:
+\`\`\`
+## CI Status
+
+No CI workflows configured for this repository.
+\`\`\`

commands/plan-issues.md

@@ -16,12 +16,24 @@ context: fork
 3. **Identify job**: Which job to be done does this enable?
 4. **Understand the feature**: Analyze what "$1" involves
 5. **Explore the codebase** if needed to understand context
-6. **Break down** into discrete, actionable issues:
+
+6. **Discovery phase**: Before proposing issues, walk through the user workflow:
+   - Who is the specific user?
+   - What is their goal?
+   - What is their step-by-step workflow to reach that goal?
+   - What exists today?
+   - Where does the workflow break or have gaps?
+   - What's the MVP that delivers value?
+   
+   Present this as a workflow walkthrough before proposing any issues.
+
+7. **Break down** into discrete, actionable issues:
+   - Derive issues from the workflow gaps identified in discovery
    - Each issue should be independently completable
    - Clear dependencies between issues
    - Appropriate scope (not too big, not too small)
 
-7. **Present the plan** (include vision alignment if vision exists):
+8. **Present the plan** (include vision alignment if vision exists):
    ```
    ## Proposed Issues for: $1
 
@@ -30,12 +42,15 @@ context: fork
    Supports: [Milestone/Goal name]
 
    1. [Title] - Brief description
+      Addresses gap: [which workflow gap this solves]
       Dependencies: none
 
    2. [Title] - Brief description
+      Addresses gap: [which workflow gap this solves]
       Dependencies: #1
 
    3. [Title] - Brief description
+      Addresses gap: [which workflow gap this solves]
       Dependencies: #1, #2
    ```
 
@@ -45,7 +60,7 @@ context: fork
    - This should be added as a non-goal
    - Proceed anyway (with justification)
 
-8. **Ask for approval** before creating issues
-9. **Create issues** in dependency order (blockers first)
-10. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
-11. **Present summary** with links to created issues and dependency graph
+9. **Ask for approval** before creating issues
+10. **Create issues** in dependency order (blockers first)
+11. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
+12. **Present summary** with links to created issues and dependency graph

commands/pr.md

@@ -0,0 +1,147 @@
+---
+description: Create a PR from current branch. Auto-generates title and description from branch name and commits.
+---
+
+# Create Pull Request
+
+@~/.claude/skills/gitea/SKILL.md
+
+Quick PR creation from current branch - lighter than full `/work-issue` flow for when you're already on a branch with commits.
+
+## Prerequisites
+
+- Current branch is NOT main/master
+- Branch has commits ahead of main
+- Changes have been pushed to origin (or will be pushed)
+
+## Process
+
+### 1. Verify Branch State
+
+```bash
+# Check current branch
+git branch --show-current
+
+# Ensure we're not on main
+# If on main, abort with message: "Cannot create PR from main branch"
+
+# Check for commits ahead of main
+git log main..HEAD --oneline
+```
+
+### 2. Push if Needed
+
+```bash
+# Check if branch is tracking remote
+git status -sb
+
+# If not pushed or behind, push with upstream
+git push -u origin <branch-name>
+```
+
+### 3. Generate PR Title
+
+**Option A: Branch contains issue number** (e.g., `issue-42-add-feature`)
+
+Extract issue number and use format: `[Issue #<number>] <issue-title>`
+
+```bash
+tea issues <number>  # Get the actual issue title
+```
+
+**Option B: No issue number**
+
+Generate from branch name or recent commit messages:
+- Convert branch name from kebab-case to title case: `add-user-auth` -> `Add user auth`
+- Or use the most recent commit subject line
+
+### 4. Generate PR Description
+
+Analyze the diff and commits to generate a description:
+
+```bash
+# Get diff against main
+git diff main...HEAD --stat
+
+# Get commit messages
+git log main..HEAD --format="- %s"
+```
+
+Structure the description:
+
+```markdown
+## Summary
+[1-2 sentences describing the overall change]
+
+## Changes
+[Bullet points summarizing commits or key changes]
+
+[If issue linked: "Closes #<number>"]
+```
+
+### 5. Create PR
+
+Use tea CLI to create the PR:
+
+```bash
+tea pulls create --title "<generated-title>" --description "<generated-description>"
+```
+
+Capture the PR number from the output (e.g., "Pull Request #42 created").
+
+### 6. Auto-review
+
+Inform the user that auto-review is starting, then spawn the `code-reviewer` agent in background:
+
+```
+Task tool with:
+  - subagent_type: "code-reviewer"
+  - run_in_background: true
+  - prompt: |
+      Review PR #<PR_NUMBER> in the repository at <REPO_PATH>.
+
+      1. Checkout the PR: tea pulls checkout <PR_NUMBER>
+      2. Get the diff: git diff main...HEAD
+      3. Analyze for code quality, bugs, security, style, test coverage
+      4. Post structured review comment with tea comment
+      5. Merge with rebase if LGTM, otherwise leave for user
+```
+
+### 7. Display Result
+
+Show the user:
+- PR URL/number
+- Generated title and description
+- Status of auto-review (spawned in background)
+
+## Issue Linking
+
+To detect if branch is linked to an issue:
+
+1. Check branch name for patterns:
+   - `issue-<number>-*`
+   - `<number>-*`
+   - `*-#<number>`
+
+2. If issue number found:
+   - Fetch issue title from Gitea
+   - Use `[Issue #N] <issue-title>` format for PR title
+   - Add `Closes #N` to description
+
+## Example Output
+
+```
+Created PR #42: [Issue #15] Add /pr command
+
+## Summary
+Adds /pr command for quick PR creation from current branch.
+
+## Changes
+- Add commands/pr.md with auto-generation logic
+- Support issue linking from branch name
+
+Closes #15
+
+---
+Auto-review started in background. Check status with: tea pulls 42 --comments
+```

commands/roadmap.md

@@ -1,5 +1,9 @@
 ---
 description: View current issues as a roadmap. Shows open issues organized by status and dependencies.
+# Model: haiku is sufficient for fetching and organizing issue data.
+# This command reads issues and dependencies, then displays them in categories.
+# Basic categorization logic doesn't require advanced reasoning.
+model: haiku
 argument-hint:
 ---
 

skills/roadmap-planning/SKILL.md

@@ -15,7 +15,33 @@ How to plan features and create issues for implementation.
 - Who benefits and how?
 - What's the success criteria?
 
-### 2. Break Down the Work
+### 2. Discovery Phase
+
+Before breaking down work into issues, understand the user's workflow:
+
+| Question | Why It Matters |
+|----------|----------------|
+| **Who** is the user? | Specific persona, not "users" |
+| **What's their goal?** | The job they're trying to accomplish |
+| **What's their workflow?** | Step-by-step actions to reach the goal |
+| **What exists today?** | Current state and gaps |
+| **What's the MVP?** | Minimum to deliver value |
+
+**Walk through the workflow step by step:**
+1. User starts at: [starting point]
+2. User does: [action 1]
+3. System responds: [what happens]
+4. User does: [action 2]
+5. ... continue until goal is reached
+
+**Identify the gaps:**
+- Where does the workflow break today?
+- Which steps are missing or painful?
+- What's the smallest change that unblocks value?
+
+**Derive issues from workflow gaps** - not from guessing what might be needed. Each issue should address a specific gap in the user's workflow.
+
+### 3. Break Down the Work
 - Identify distinct components
 - Define boundaries between pieces
 - Aim for issues that are:
@@ -23,12 +49,12 @@ How to plan features and create issues for implementation.
   - Independently testable
   - Clear in scope
 
-### 3. Identify Dependencies
+### 4. Identify Dependencies
 - Which pieces must come first?
 - What can be parallelized?
 - Are there external blockers?
 
-### 4. Create Issues
+### 5. Create Issues
 - Follow issue-writing patterns
 - Reference dependencies explicitly
 - Use consistent labeling