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,9 +14,15 @@ 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`
+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

agents/issue-worker/agent.md

@@ -1,5 +1,6 @@
 ---
 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
@@ -19,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>
@@ -92,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,5 +1,6 @@
 ---
 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
@@ -19,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
@@ -33,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>
 
@@ -52,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:
@@ -104,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/create-capability.md

@@ -1,256 +1,123 @@
 ---
-description: Create new capabilities (skills, commands, agents) with validation and guided design decisions.
+description: Create a new capability (skill, command, agent, or a cohesive set) for the architecture repository.
 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.
+Create new capabilities following established patterns. A capability may be a single component or a cohesive set (skill + command + agent).
 
 ## Process
 
-### Phase 1: Understand Intent
+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?
 
-1. **Parse the description** from `$1` or ask for one:
-   - "What capability do you want to add? Describe what it should do."
+2. **Determine components needed**: Based on the description, recommend which components:
 
-2. **Ask clarifying questions** to determine component type:
+   | 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 |
 
-   | 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? |
+   Present recommendation with reasoning:
+   ```
+   ## Recommended Components for: $1
 
-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
+   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)
 
-### Phase 2: Gather Details
+   Reasoning: [explain why this combination fits the need]
+   ```
 
-4. **Collect information for each component**:
+3. **Gather information**: For each recommended component, ask:
+
+   **For all components:**
+   - Name (kebab-case, descriptive)
+   - Description (one-line summary)
 
    **For Skills:**
-   - Name (kebab-case): skill name matching directory
-   - Description: what it teaches + trigger conditions
-   - Core sections to include
+   - What domain/knowledge does this cover?
+   - What are the key concepts to teach?
+   - What patterns or templates should it include?
 
    **For Commands:**
-   - Name (kebab-case): verb-phrase action name
-   - Description: one-line summary
-   - Arguments: required `<arg>` and optional `[arg]`
-   - Skills to reference
+   - What triggers this workflow?
+   - What are the key steps?
+   - What approval points are needed?
+   - What skills should it reference?
 
    **For Agents:**
-   - Name (kebab-case): role-based specialist name
-   - Description: what it does + when to spawn
-   - Skills it needs
-   - Tool restrictions (read-only?)
+   - What specialized role does this fill?
+   - What skills does it need?
+   - Should it be read-only (no Edit/Write)?
 
-### Phase 3: Model Selection
+4. **Select appropriate models**:
 
-5. **Recommend appropriate models** with explanation:
+   | Model | Use For |
+   |-------|---------|
+   | `haiku` | Simple fetch/display commands, formatting tasks |
+   | `sonnet` | Most commands and agents (default) |
+   | `opus` | Deep reasoning, architectural analysis, complex judgment |
 
-   | 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 |
+   For each component, recommend a model with 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"
+5. **Generate files**: Create content using templates from capability-writing skill
 
-### 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**:
+   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:
    ```
-   ## Validation Results
+   ## Generated Files
 
-   [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
+   ### skills/name/SKILL.md
+   [full content]
 
-   Proceed with warnings? (y/n)
+   ### commands/name.md
+   [full content]
+
+   ### agents/name/AGENT.md (if applicable)
+   [full content]
+
+   Ready to create these files?
    ```
 
-10. **Show file preview** with full content:
+7. **Create files** in correct locations after approval:
+   - `skills/<name>/SKILL.md`
+   - `commands/<name>.md`
+   - `agents/<name>/AGENT.md`
 
-    ```
-    ## Files to Create
+8. **Report success**:
+   ```
+   ## Capability Created: name
 
-    ### skills/migration-review/SKILL.md
+   Files created:
+   - skills/name/SKILL.md
+   - commands/name.md
+   - agents/name/AGENT.md (if applicable)
 
-    ```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]
-```
+   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
 
-- 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
+- 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/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
 ---

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

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