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. Generate a structured review comment
-4. Post the review using `tea comment <number> "<review body>"`
+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 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
+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
+#### Lint Issues
-- [Finding or "Consistent with codebase"]
+- [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/create-capability.md

@@ -0,0 +1,256 @@
+---
+description: Create new capabilities (skills, commands, agents) with validation and guided design decisions.
+argument-hint: <description>
+model: sonnet
+---
+
+# Create Capability
+
+@~/.claude/skills/capability-writing/SKILL.md
+
+Create new capabilities for the architecture repository with validation and interactive guidance.
+
+## Process
+
+### Phase 1: Understand Intent
+
+1. **Parse the description** from `$1` or ask for one:
+   - "What capability do you want to add? Describe what it should do."
+
+2. **Ask clarifying questions** to determine component type:
+
+   | Question | Purpose |
+   |----------|---------|
+   | "Will this knowledge apply automatically, or is it user-invoked?" | Skill vs Command |
+   | "Does this need isolated context for complex work?" | Agent needed? |
+   | "Is this read-only analysis or does it modify files?" | Tool restrictions |
+   | "Will this be used repeatedly, or is it one-time?" | Worth encoding? |
+
+3. **Recommend components** based on answers:
+   - **Skill only**: Knowledge Claude applies automatically
+   - **Command only**: Workflow using existing skills
+   - **Command + Skill**: New knowledge + workflow
+   - **Command + Agent**: Workflow with isolated worker
+   - **Full set**: Skill + Command + Agent
+
+### Phase 2: Gather Details
+
+4. **Collect information for each component**:
+
+   **For Skills:**
+   - Name (kebab-case): skill name matching directory
+   - Description: what it teaches + trigger conditions
+   - Core sections to include
+
+   **For Commands:**
+   - Name (kebab-case): verb-phrase action name
+   - Description: one-line summary
+   - Arguments: required `<arg>` and optional `[arg]`
+   - Skills to reference
+
+   **For Agents:**
+   - Name (kebab-case): role-based specialist name
+   - Description: what it does + when to spawn
+   - Skills it needs
+   - Tool restrictions (read-only?)
+
+### Phase 3: Model Selection
+
+5. **Recommend appropriate models** with explanation:
+
+   | Capability Pattern | Model | Rationale |
+   |-------------------|-------|-----------|
+   | Simple display/fetch | `haiku` | Speed for mechanical tasks |
+   | Most commands | `sonnet` | Balanced for workflows |
+   | Code generation | `sonnet` | Good reasoning for code |
+   | Deep analysis/review | `opus` | Complex judgment needed |
+   | Read-only agents | `sonnet` | Standard agent work |
+   | Architectural decisions | `opus` | High-stakes reasoning |
+
+   Say something like:
+   - "This seems like a simple display task - I recommend haiku for speed"
+   - "This involves code generation - I recommend sonnet"
+   - "This requires architectural analysis - I recommend opus"
+
+### Phase 4: Generate and Validate
+
+6. **Generate file content** using templates from capability-writing skill
+
+7. **Run validation checks** before showing preview:
+
+   #### Frontmatter Validation
+
+   | Check | Component | Rule |
+   |-------|-----------|------|
+   | Required fields | All | `name` for skills/agents, `description` for all |
+   | Model value | All | Must be `haiku`, `sonnet`, or `opus` (or absent) |
+   | Tools list | Agents | Only valid tool names: `Bash`, `Read`, `Write`, `Edit`, `Glob`, `Grep`, `Task`, `TodoWrite` |
+   | Skills reference | Agents | Each skill in list must exist in `skills/*/SKILL.md` |
+
+   #### Content Validation
+
+   | Check | Component | Rule |
+   |-------|-----------|------|
+   | Trigger conditions | Skills | Description must explain when to use (not just what) |
+   | Step instructions | Commands | Must have numbered steps with `**Step**:` format |
+   | Behavior sections | Agents | Must have "When Invoked" or process section |
+   | Skill references | Commands | `@~/.claude/skills/name/SKILL.md` paths must be valid |
+
+   #### Convention Checks
+
+   | Check | Rule |
+   |-------|------|
+   | Skill file name | Must be `SKILL.md` (uppercase) |
+   | Command file name | Must be lowercase kebab-case |
+   | Agent file name | Must be `AGENT.md` (uppercase) |
+   | Directory structure | `skills/<name>/`, `commands/`, `agents/<name>/` |
+   | No duplicates | Name must not match existing capability |
+
+8. **Check for anti-patterns** and warn:
+
+   | Anti-pattern | Detection | Warning |
+   |--------------|-----------|---------|
+   | Trigger in body | Skill body contains "when to use" | "Move trigger conditions to description frontmatter" |
+   | No tool restrictions | Read-only agent without `disallowedTools` | "Consider adding `disallowedTools: [Edit, Write]` for read-only agents" |
+   | Missing skill refs | Command mentions domain without `@` reference | "Add explicit skill reference: `@~/.claude/skills/name/SKILL.md`" |
+   | Overly broad tools | Agent allows all tools but does specific task | "Consider restricting tools to what's actually needed" |
+   | Generic naming | Name like `utils`, `helper`, `misc` | "Use specific domain-focused naming" |
+   | God capability | Single component handling multiple unrelated concerns | "Consider splitting into focused components" |
+
+### Phase 5: Present and Confirm
+
+9. **Show validation results**:
+
+   ```
+   ## Validation Results
+
+   [PASS] Frontmatter: All required fields present
+   [PASS] Model: sonnet is valid
+   [WARN] Anti-pattern: Agent allows all tools but only reads files
+         Recommendation: Add disallowedTools: [Edit, Write]
+   [PASS] Conventions: File names follow patterns
+   [PASS] No duplicates: Name is unique
+
+   Proceed with warnings? (y/n)
+   ```
+
+10. **Show file preview** with full content:
+
+    ```
+    ## Files to Create
+
+    ### skills/migration-review/SKILL.md
+
+    ```yaml
+    ---
+    name: migration-review
+    description: >
+      Knowledge for reviewing database migrations...
+    ---
+    ```
+
+    ### commands/review-migration.md
+
+    ```yaml
+    ---
+    description: Review database migrations for safety and best practices
+    ---
+    ```
+    ```
+
+11. **Ask for approval** (gate before file creation):
+    - "Create these files? (y/n)"
+    - If warnings exist: "There are warnings. Proceed anyway? (y/n)"
+    - **If user declines**: Stop here. Offer to adjust the generated content or cancel.
+    - **If user approves**: Proceed to Phase 6.
+
+### Phase 6: Create Files
+
+**Only execute this phase after user approval in step 11.**
+
+12. **Create directories** if needed:
+    ```bash
+    mkdir -p skills/<name>
+    mkdir -p agents/<name>
+    ```
+
+    If directory creation fails, report the error and stop.
+
+13. **Write files** to correct locations:
+    - `skills/<name>/SKILL.md`
+    - `commands/<name>.md`
+    - `agents/<name>/AGENT.md`
+
+    If any file write fails, report which files were created and which failed.
+
+14. **Report success**:
+    ```
+    ## Capability Created
+
+    Files created:
+    - skills/migration-review/SKILL.md
+    - commands/review-migration.md
+
+    Next steps:
+    1. Run `make install` to symlink to ~/.claude/
+    2. Test with: /review-migration
+    3. Refine based on usage
+    ```
+
+## Validation Error Messages
+
+Provide clear, actionable error messages:
+
+| Error | Message |
+|-------|---------|
+| Missing name | "Skill requires `name` field in frontmatter" |
+| Invalid model | "Model must be `haiku`, `sonnet`, or `opus`. Got: `gpt-4`" |
+| Unknown tool | "Unknown tool `Search` in disallowedTools. Valid tools: Bash, Read, Write, Edit, Glob, Grep, Task, TodoWrite" |
+| Missing skill | "Agent references skill `foo` but `skills/foo/SKILL.md` does not exist" |
+| Invalid path | "Skill reference `@~/.claude/skills/bar/SKILL.md` invalid - directory `skills/bar/` not found" |
+| Duplicate name | "Capability `gitea` already exists at `skills/gitea/SKILL.md`" |
+| Wrong file name | "Skill file must be named `SKILL.md`, not `skill.md`" |
+
+## Example Session
+
+```
+User: /create-capability I want to add support for reviewing database migrations
+
+Claude: I'll help you create a migration review capability. Let me ask a few questions:
+
+1. Will this knowledge apply automatically when Claude sees migrations,
+   or should users explicitly invoke it?
+
+User: Users should invoke it explicitly
+
+Claude: 2. Does this need isolated context for deep analysis, or can it work
+   in the main conversation?
+
+User: Isolated would be good for complex migrations
+
+Claude: 3. Is this read-only analysis, or will it modify migration files?
+
+User: Just analysis, read-only
+
+Claude: Based on your answers, I recommend:
+
+- **Command**: `/review-migration` - Entry point for users
+- **Skill**: `migration-review` - Knowledge about safe migrations
+- **Agent**: `migration-reviewer` - Isolated analysis (read-only)
+
+For model selection:
+- Command: `sonnet` (standard workflow)
+- Agent: `sonnet` with `opus` upgrade path for complex cases
+
+Let me gather details for each component...
+
+[Continues with file generation, validation, and creation]
+```
+
+## Guidelines
+
+- Always run full validation before showing preview
+- Show warnings but allow override with explicit confirmation
+- Validate skill references exist before creating dependent components
+- Suggest related existing skills that could be referenced
+- Keep generated content minimal - users can expand after testing

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:
+Fetch and display the following sections:
-1. All open issues
-2. All open PRs
 
-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. **Ask for approval** before creating issues
-9. **Create issues** in dependency order (blockers first)
+10. **Create issues** in dependency order (blockers first)
-10. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
+11. **Link dependencies** using `tea issues deps add <issue> <blocker>` for each dependency
-11. **Present summary** with links to created issues and dependency graph
+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