Fix typo: use REPO_PATH instead of REPO_NAME

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

agents/code-reviewer/AGENT.md

@@ -14,21 +14,76 @@ You are a code review specialist that provides immediate, structured feedback on
 
 ## When Invoked
 
-You will receive a PR number to review. Follow this process:
+You will receive a PR number to review. You may also receive:
+- `WORKTREE_PATH`: (Optional) If provided, work directly in this directory instead of checking out locally
+- `REPO_PATH`: Path to the main repository (use if `WORKTREE_PATH` not provided)
 
-1. Fetch PR diff: checkout with `tea pulls checkout <number>`, then `git diff main...HEAD`
-2. Analyze the diff for issues in these categories:
+Follow this process:
+
+1. Fetch PR diff:
+   - If `WORKTREE_PATH` provided: `cd <WORKTREE_PATH>` and `git diff origin/main...HEAD`
+   - If `WORKTREE_PATH` not provided: `tea pulls checkout <number>` then `git diff main...HEAD`
+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 +109,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 +125,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,11 @@
 ---
 name: issue-worker
+model: haiku
 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
 ---
@@ -15,11 +20,19 @@ You will receive:
 - `ISSUE_NUMBER`: The issue number to work on
 - `REPO_PATH`: Absolute path to the main repository
 - `REPO_NAME`: Name of the repository (for worktree naming)
+- `WORKTREE_PATH`: (Optional) Absolute path to pre-created worktree. If provided, agent works directly in this directory. If not provided, agent creates its own worktree as a sibling directory.
 
 ## Process
 
 ### 1. Setup Worktree
 
+If `WORKTREE_PATH` was provided:
+```bash
+# Use the pre-created worktree
+cd <WORKTREE_PATH>
+```
+
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
 ```bash
 # Fetch latest from origin
 cd <REPO_PATH>
@@ -88,8 +101,15 @@ Capture the PR number from the output (e.g., "Pull Request #42 created").
 
 ### 6. Cleanup Worktree
 
-Always clean up, even if earlier steps failed:
+If `WORKTREE_PATH` was provided:
+```bash
+# Orchestrator will handle cleanup - no action needed
+# Just ensure git is clean
+cd <WORKTREE_PATH>
+git status
+```
 
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
 ```bash
 cd <REPO_PATH>
 git worktree remove ../<REPO_NAME>-issue-<ISSUE_NUMBER> --force

agents/pr-fixer/agent.md

@@ -1,6 +1,11 @@
 ---
 name: pr-fixer
+model: haiku
 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
 ---
@@ -15,11 +20,22 @@ You will receive:
 - `PR_NUMBER`: The PR number to fix
 - `REPO_PATH`: Absolute path to the main repository
 - `REPO_NAME`: Name of the repository (for worktree naming)
+- `WORKTREE_PATH`: (Optional) Absolute path to pre-created worktree. If provided, agent works directly in this directory. If not provided, agent creates its own worktree as a sibling directory.
 
 ## Process
 
-### 1. Get PR Details
+### 1. Get PR Details and Setup Worktree
 
+If `WORKTREE_PATH` was provided:
+```bash
+# Use the pre-created worktree
+cd <WORKTREE_PATH>
+
+# Get PR info and review comments
+tea pulls <PR_NUMBER> --comments
+```
+
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
 ```bash
 cd <REPO_PATH>
 git fetch origin
@@ -29,15 +45,7 @@ tea pulls <PR_NUMBER>
 
 # Get review comments
 tea pulls <PR_NUMBER> --comments
-```
 
-Extract:
-- The PR branch name (e.g., `issue-42-add-feature`)
-- All review comments and requested changes
-
-### 2. Setup Worktree
-
-```bash
 # Create worktree from the PR branch
 git worktree add ../<REPO_NAME>-pr-<PR_NUMBER> origin/<branch-name>
 
@@ -48,6 +56,10 @@ cd ../<REPO_NAME>-pr-<PR_NUMBER>
 git checkout <branch-name>
 ```
 
+Extract:
+- The PR branch name (e.g., `issue-42-add-feature`)
+- All review comments and requested changes
+
 ### 3. Analyze Review Feedback
 
 Read all review comments and identify:
@@ -100,8 +112,15 @@ Based on review feedback:
 
 ### 7. Cleanup Worktree
 
-Always clean up, even if earlier steps failed:
+If `WORKTREE_PATH` was provided:
+```bash
+# Orchestrator will handle cleanup - no action needed
+# Just ensure git is clean
+cd <WORKTREE_PATH>
+git status
+```
 
+If `WORKTREE_PATH` was NOT provided (backward compatibility):
 ```bash
 cd <REPO_PATH>
 git worktree remove ../<REPO_NAME>-pr-<PR_NUMBER> --force

commands/arch-refine-issue.md

@@ -1,5 +1,6 @@
 ---
 description: Refine an issue with architectural perspective. Analyzes existing codebase patterns and provides implementation guidance.
+model: opus
 argument-hint: <issue-number>
 ---
 

commands/arch-review-repo.md

@@ -1,5 +1,6 @@
 ---
 description: Perform a full architecture review of the current repository. Analyzes structure, patterns, dependencies, and generates prioritized recommendations.
+model: opus
 argument-hint:
 context: fork
 ---

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,123 @@
+---
+description: Create a new capability (skill, command, agent, or a cohesive set) for the architecture repository.
+argument-hint: <description>
+---
+
+# Create Capability
+
+@~/.claude/skills/capability-writing/SKILL.md
+
+Create new capabilities following established patterns. A capability may be a single component or a cohesive set (skill + command + agent).
+
+## Process
+
+1. **Understand the capability**: Analyze "$1" to understand what the user wants to build
+   - What domain or workflow does this cover?
+   - What user need does it address?
+   - What existing capabilities might overlap?
+
+2. **Determine components needed**: Based on the description, recommend which components:
+
+   | Pattern | When to Use |
+   |---------|-------------|
+   | Skill only | Knowledge to apply automatically (reused across commands) |
+   | Command only | User-invoked workflow using existing skills |
+   | Command + Skill | New knowledge + workflow to use it |
+   | Command + Agent | Workflow with isolated worker for complex subtasks |
+   | Full set | New domain expertise + workflow + isolated work |
+
+   Present recommendation with reasoning:
+   ```
+   ## Recommended Components for: $1
+
+   Based on your description, I recommend:
+   - **Skill**: `name` - [why this knowledge is needed]
+   - **Command**: `/name` - [what user action this enables]
+   - **Agent**: `name` - [why isolation/specialization is needed] (optional)
+
+   Reasoning: [explain why this combination fits the need]
+   ```
+
+3. **Gather information**: For each recommended component, ask:
+
+   **For all components:**
+   - Name (kebab-case, descriptive)
+   - Description (one-line summary)
+
+   **For Skills:**
+   - What domain/knowledge does this cover?
+   - What are the key concepts to teach?
+   - What patterns or templates should it include?
+
+   **For Commands:**
+   - What triggers this workflow?
+   - What are the key steps?
+   - What approval points are needed?
+   - What skills should it reference?
+
+   **For Agents:**
+   - What specialized role does this fill?
+   - What skills does it need?
+   - Should it be read-only (no Edit/Write)?
+
+4. **Select appropriate models**:
+
+   | Model | Use For |
+   |-------|---------|
+   | `haiku` | Simple fetch/display commands, formatting tasks |
+   | `sonnet` | Most commands and agents (default) |
+   | `opus` | Deep reasoning, architectural analysis, complex judgment |
+
+   For each component, recommend a model with reasoning.
+
+5. **Generate files**: Create content using templates from capability-writing skill
+
+   Ensure proper inter-references:
+   - Command references skill via `@~/.claude/skills/name/SKILL.md`
+   - Agent lists skills in `skills:` frontmatter (names only, not paths)
+   - Command spawns agent via Task tool if agent is part of the set
+
+6. **Present for approval**: Show all generated files with their full content:
+   ```
+   ## Generated Files
+
+   ### skills/name/SKILL.md
+   [full content]
+
+   ### commands/name.md
+   [full content]
+
+   ### agents/name/AGENT.md (if applicable)
+   [full content]
+
+   Ready to create these files?
+   ```
+
+7. **Create files** in correct locations after approval:
+   - `skills/<name>/SKILL.md`
+   - `commands/<name>.md`
+   - `agents/<name>/AGENT.md`
+
+8. **Report success**:
+   ```
+   ## Capability Created: name
+
+   Files created:
+   - skills/name/SKILL.md
+   - commands/name.md
+   - agents/name/AGENT.md (if applicable)
+
+   Next steps:
+   1. Run `make install` to symlink to ~/.claude/
+   2. Test with: /name (for commands)
+   3. Skills will auto-activate based on context
+   ```
+
+## Guidelines
+
+- Follow all conventions from capability-writing skill
+- Reference existing skills rather than duplicating knowledge
+- Keep components focused - split if scope is too broad
+- Commands should have approval checkpoints before significant actions
+- Default to `sonnet` model unless there's a clear reason for haiku/opus
+- Skills should have descriptive `description` fields for auto-activation

commands/create-issue.md

@@ -1,5 +1,6 @@
 ---
 description: Create a new Gitea issue. Can create single issues or batch create from a plan.
+model: haiku
 argument-hint: [title] or "batch"
 ---
 

commands/create-repo.md

@@ -1,5 +1,6 @@
 ---
 description: Create a new repository with standard structure. Scaffolds vision.md, CLAUDE.md, and CI configuration.
+model: haiku
 argument-hint: <repo-name>
 context: fork
 ---

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/groom.md

@@ -1,5 +1,6 @@
 ---
 description: Groom and improve issues. Without argument, reviews all open issues. With argument, grooms specific issue.
+model: sonnet
 argument-hint: [issue-number]
 ---
 

commands/improve.md

@@ -1,5 +1,6 @@
 ---
 description: Identify improvement opportunities based on product vision. Analyzes gaps between vision goals and current backlog.
+model: sonnet
 argument-hint:
 context: fork
 ---

commands/manifesto.md

@@ -1,5 +1,6 @@
 ---
 description: View and manage the organization manifesto. Shows identity, personas, beliefs, and principles.
+model: haiku
 argument-hint:
 ---
 

commands/plan-issues.md

@@ -1,5 +1,6 @@
 ---
 description: Plan and create issues for a feature or improvement. Breaks down work into well-structured issues with vision alignment.
+model: sonnet
 argument-hint: <feature-description>
 context: fork
 ---
@@ -16,12 +17,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 +43,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 +61,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/retro.md

@@ -1,5 +1,6 @@
 ---
 description: Run a retrospective on completed work. Captures insights as issues for later encoding into skills/commands/agents.
+model: haiku
 argument-hint: [task-description]
 ---
 

commands/review-pr.md

@@ -1,5 +1,6 @@
 ---
 description: Review a Gitea pull request. Fetches PR details, diff, and comments. Includes both code review and software architecture review.
+model: sonnet
 argument-hint: <pr-number>
 ---
 

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:
 ---
 

commands/spawn-issues.md

@@ -1,5 +1,6 @@
 ---
 allowed-tools: Bash, Task, Read, TaskOutput
+model: haiku
 description: Orchestrate parallel issue implementation with review cycles
 argument-hint: <issue-number> [<issue-number>...]
 ---
@@ -62,13 +63,34 @@ Usage: /spawn-issues <issue-number> [<issue-number>...]
 Example: /spawn-issues 42 43 44
 ```
 
-### Step 2: Get Repository Info
+### Step 2: Get Repository Info and Setup Worktrees
 
 ```bash
 REPO_PATH=$(pwd)
 REPO_NAME=$(basename $REPO_PATH)
+
+# Create parent worktrees directory
+mkdir -p "${REPO_PATH}/../worktrees"
+WORKTREES_DIR="${REPO_PATH}/../worktrees"
 ```
 
+For each issue, create the worktree upfront:
+```bash
+# Fetch latest from origin
+cd "${REPO_PATH}"
+git fetch origin
+
+# Get issue details for branch naming
+ISSUE_TITLE=$(tea issues <ISSUE_NUMBER> | grep "TITLE" | head -1)
+BRANCH_NAME="issue-<ISSUE_NUMBER>-<kebab-title>"
+
+# Create worktree for this issue
+git worktree add "${WORKTREES_DIR}/${REPO_NAME}-issue-<ISSUE_NUMBER>" \
+  -b "${BRANCH_NAME}" origin/main
+```
+
+Track the worktree path for each issue.
+
 ### Step 3: Spawn All Issue Workers
 
 For each issue number, spawn a background issue-worker agent and track its task_id:
@@ -105,12 +127,11 @@ Context:
 - Repository path: <REPO_PATH>
 - Repository name: <REPO_NAME>
 - Issue number: <NUMBER>
+- Worktree path: <WORKTREE_PATH>
 
 Process:
 1. Setup worktree:
-   cd <REPO_PATH> && git fetch origin
-   git worktree add ../<REPO_NAME>-issue-<NUMBER> -b issue-<NUMBER>-<short-title> origin/main
-   cd ../<REPO_NAME>-issue-<NUMBER>
+   cd <WORKTREE_PATH>
 
 2. Get issue: tea issues <NUMBER> --comments
 
@@ -123,7 +144,7 @@ Process:
 6. Create PR: tea pulls create --title "[Issue #<NUMBER>] <title>" --description "Closes #<NUMBER>\n\n..."
    Capture the PR number.
 
-7. Cleanup: cd <REPO_PATH> && git worktree remove ../<REPO_NAME>-issue-<NUMBER> --force
+7. Cleanup: No cleanup needed - orchestrator handles worktree removal
 
 8. Output EXACTLY this format (orchestrator parses it):
    ISSUE_WORKER_RESULT
@@ -181,8 +202,17 @@ implementing → (worker done) → reviewing → (approved) → DONE
 
 ### Step 5: Spawn Reviewers and Fixers
 
-When spawning reviewers, pass the PR number AND branch name from the issue worker result.
-Each reviewer/fixer uses its own worktree for isolation - this prevents parallel agents from interfering with each other.
+When spawning reviewers/fixers, create worktrees for them and pass the path.
+
+For review, create a review worktree from the PR branch:
+```bash
+cd "${REPO_PATH}"
+git fetch origin
+git worktree add "${WORKTREES_DIR}/${REPO_NAME}-review-<PR_NUMBER>" \
+  origin/<BRANCH_NAME>
+```
+
+Pass this worktree path to the reviewer/fixer agents.
 
 **Code Reviewer:**
 ```
@@ -198,15 +228,12 @@ You are a code-reviewer agent. Review PR #<PR_NUMBER> autonomously.
 
 Context:
 - Repository path: <REPO_PATH>
-- Repository name: <REPO_NAME>
 - PR number: <PR_NUMBER>
-- PR branch: <BRANCH_NAME>
+- Worktree path: <WORKTREE_PATH>
 
 Process:
-1. Setup worktree for isolated review:
-   cd <REPO_PATH> && git fetch origin
-   git worktree add ../<REPO_NAME>-review-<PR_NUMBER> origin/<BRANCH_NAME>
-   cd ../<REPO_NAME>-review-<PR_NUMBER>
+1. Move to worktree:
+   cd <WORKTREE_PATH>
 
 2. Get PR details: tea pulls <PR_NUMBER> --comments
 
@@ -220,7 +247,7 @@ Process:
 
 5. Post review comment: tea comment <PR_NUMBER> "<review summary>"
 
-6. Cleanup: cd <REPO_PATH> && git worktree remove ../<REPO_NAME>-review-<PR_NUMBER> --force
+6. Cleanup: No cleanup needed - orchestrator handles worktree removal
 
 7. Output EXACTLY this format:
    REVIEW_RESULT
@@ -266,17 +293,14 @@ You are a pr-fixer agent. Address review feedback on PR #<NUMBER>.
 
 Context:
 - Repository path: <REPO_PATH>
-- Repository name: <REPO_NAME>
 - PR number: <NUMBER>
+- Worktree path: <WORKTREE_PATH>
 
 Process:
-1. Get feedback: tea pulls <NUMBER> --comments
+1. Move to worktree:
+   cd <WORKTREE_PATH>
 
-2. Setup worktree from PR branch:
-   cd <REPO_PATH> && git fetch origin
-   git worktree add ../<REPO_NAME>-pr-<NUMBER> origin/<branch-name>
-   cd ../<REPO_NAME>-pr-<NUMBER>
-   git checkout <branch-name>
+2. Get feedback: tea pulls <NUMBER> --comments
 
 3. Address each piece of feedback
 
@@ -284,7 +308,7 @@ Process:
    git add -A && git commit -m "Address review feedback\n\nCo-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
    git push
 
-5. Cleanup: cd <REPO_PATH> && git worktree remove ../<REPO_NAME>-pr-<NUMBER> --force
+5. Cleanup: No cleanup needed - orchestrator handles worktree removal
 
 6. Output EXACTLY:
    PR_FIXER_RESULT
@@ -295,9 +319,29 @@ Process:
 Work autonomously. If feedback is unclear, make reasonable judgment calls.
 ```
 
+## Worktree Cleanup
+
+After all issues reach terminal state, clean up all worktrees:
+
+```bash
+# Remove all worktrees created for this run
+for worktree in "${WORKTREES_DIR}"/*; do
+  if [ -d "$worktree" ]; then
+    cd "${REPO_PATH}"
+    git worktree remove "$worktree" --force
+  fi
+done
+
+# Remove worktrees directory if empty
+rmdir "${WORKTREES_DIR}" 2>/dev/null || true
+```
+
+**Important:** Always clean up worktrees, even if the orchestration failed partway through.
+
 ## Error Handling
 
 - If an issue-worker fails, continue with others
 - If a review fails, mark as "review-failed" and continue
 - If pr-fixer fails after 3 iterations, mark as "needs-manual-review"
 - Always report final status even if some items failed
+- Always clean up all worktrees before exiting

commands/spawn-pr-fixes.md

@@ -1,5 +1,6 @@
 ---
 allowed-tools: Bash, Task, Read
+model: haiku
 description: Spawn parallel background agents to address PR review feedback
 argument-hint: [pr-number...]
 ---

commands/update-claude-md.md

@@ -1,5 +1,6 @@
 ---
 description: Update or create CLAUDE.md with current project context. Explores the project and ensures organization context is present.
+model: haiku
 argument-hint:
 context: fork
 ---

commands/vision.md

@@ -1,5 +1,6 @@
 ---
 description: View the product vision and goal progress. Manages vision.md and Gitea milestones.
+model: haiku
 argument-hint: [goals]
 ---
 

commands/work-issue.md

@@ -1,5 +1,6 @@
 ---
 description: Work on a Gitea issue. Fetches issue details and sets up branch for implementation.
+model: haiku
 argument-hint: <issue-number>
 ---
 

skills/backlog-grooming/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: backlog-grooming
+model: haiku
 description: Review and improve existing issues for clarity and actionability. Use when grooming the backlog, reviewing issue quality, cleaning up stale issues, or when the user wants to improve existing issues.
 user-invocable: false
 ---

skills/capability-writing/SKILL.md

@@ -133,7 +133,7 @@ Location: `commands/<name>.md`
 ---
 description: What this command does (one-line summary)
 argument-hint: <required> [optional]
-model: sonnet
+model: haiku
 ---
 
 # Command Title
@@ -165,7 +165,7 @@ Location: `agents/<name>/AGENT.md`
 ---
 name: agent-name
 description: What this agent does and when to spawn it
-model: sonnet
+model: haiku
 skills: skill1, skill2
 disallowedTools:
   - Edit

skills/claude-md-writing/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: claude-md-writing
+model: haiku
 description: Write effective CLAUDE.md files that give AI assistants the context they need. Use when creating new repos, improving existing CLAUDE.md files, or setting up projects.
 user-invocable: false
 ---

skills/code-review/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: code-review
+model: haiku
 description: Review code for quality, bugs, security, and style issues. Use when reviewing pull requests, checking code quality, looking for bugs or security vulnerabilities, or when the user asks for a code review.
 user-invocable: false
 ---

skills/gitea/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: gitea
+model: haiku
 description: View, create, and manage Gitea issues and pull requests using tea CLI. Use when working with issues, PRs, viewing issue details, creating pull requests, adding comments, merging PRs, or when the user mentions tea, gitea, issue numbers, or PR numbers.
 user-invocable: false
 ---

skills/issue-writing/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: issue-writing
+model: haiku
 description: Write clear, actionable issues with proper structure and acceptance criteria. Use when creating issues, writing bug reports, feature requests, or when the user needs help structuring an issue.
 user-invocable: false
 ---

skills/repo-conventions/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: repo-conventions
+model: haiku
 description: Standard structure and conventions for Flowmade repositories. Use when creating new repos, reviewing repo structure, or setting up projects.
 user-invocable: false
 ---

skills/roadmap-planning/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: roadmap-planning
+model: haiku
 description: Plan features and break down work into implementable issues. Use when planning a feature, creating a roadmap, breaking down large tasks, or when the user needs help organizing work into issues.
 user-invocable: false
 ---
@@ -15,7 +16,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 +50,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

skills/software-architecture/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: software-architecture
+model: haiku
 description: >
   Architectural patterns for building systems: DDD, Event Sourcing, event-driven communication.
   Use when implementing features, reviewing code, planning issues, refining architecture,

skills/vision-management/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: vision-management
+model: haiku
 description: Create, maintain, and evolve organization manifesto and product visions. Use when working with manifesto.md, vision.md, milestones, or aligning work with organizational direction.
 user-invocable: false
 ---