Hugo Nijhuis
81c2a90ce1
Resolves issue #86 by having the spawn-issues orchestrator create worktrees upfront and pass the worktree paths to agents, instead of having agents create their own worktrees in sibling directories outside the sandbox. Changes: - spawn-issues orchestrator creates all worktrees before spawning agents - issue-worker, pr-fixer, code-reviewer accept optional WORKTREE_PATH - When WORKTREE_PATH is provided, agents work directly in that directory - Backward compatible: agents still support creating their own worktrees if WORKTREE_PATH is not provided - Orchestrator handles all worktree cleanup after agents complete - Eliminates permission denied errors from agents trying to access sibling worktree directories This ensures agents operate within their sandbox while still being able to work with isolated git worktrees for parallel implementation. Closes #86 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
159 lines
4.1 KiB
Markdown
159 lines
4.1 KiB
Markdown
---
|
|
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
|
|
---
|
|
|
|
# PR Fixer Agent
|
|
|
|
Autonomously addresses review feedback on a pull request in an isolated git worktree.
|
|
|
|
## Input
|
|
|
|
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 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
|
|
|
|
# Get PR info including branch name
|
|
tea pulls <PR_NUMBER>
|
|
|
|
# Get review comments
|
|
tea pulls <PR_NUMBER> --comments
|
|
|
|
# Create worktree from the PR branch
|
|
git worktree add ../<REPO_NAME>-pr-<PR_NUMBER> origin/<branch-name>
|
|
|
|
# Move to worktree
|
|
cd ../<REPO_NAME>-pr-<PR_NUMBER>
|
|
|
|
# Checkout the branch (to track it)
|
|
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:
|
|
- Specific code changes requested
|
|
- General feedback to address
|
|
- Questions to answer in code or comments
|
|
|
|
Use TodoWrite to create a task for each piece of feedback.
|
|
|
|
### 4. Address Feedback
|
|
|
|
For each review item:
|
|
- Read the relevant code
|
|
- Make the requested changes
|
|
- Follow existing patterns in the codebase
|
|
- Mark todo as complete
|
|
|
|
### 5. Commit and Push
|
|
|
|
```bash
|
|
git add -A
|
|
git commit -m "Address review feedback
|
|
|
|
- <summary of change 1>
|
|
- <summary of change 2>
|
|
|
|
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
|
|
|
|
git push
|
|
```
|
|
|
|
### 6. Review Loop
|
|
|
|
Spawn the `code-reviewer` agent **synchronously** to re-review:
|
|
|
|
```
|
|
Task tool with:
|
|
- subagent_type: "code-reviewer"
|
|
- run_in_background: false
|
|
- prompt: "Review PR #<PR_NUMBER>. Working directory: <WORKTREE_PATH>"
|
|
```
|
|
|
|
Based on review feedback:
|
|
- **If approved**: Proceed to cleanup
|
|
- **If needs work**:
|
|
1. Address the new feedback
|
|
2. Commit and push the fixes
|
|
3. Trigger another review
|
|
4. Repeat until approved (max 3 iterations to avoid infinite loops)
|
|
|
|
### 7. Cleanup Worktree
|
|
|
|
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
|
|
```
|
|
|
|
### 8. Final Summary
|
|
|
|
**IMPORTANT**: Your final output must be a concise summary (5-10 lines max) for the spawning process:
|
|
|
|
```
|
|
PR #<NUMBER>: <title>
|
|
Status: <fixed|partial|blocked>
|
|
Feedback addressed: <count> items
|
|
Review: <approved|needs-work|skipped>
|
|
Commits: <number of commits pushed>
|
|
Notes: <any blockers or important details>
|
|
```
|
|
|
|
Do NOT include verbose logs or intermediate output - only this final summary.
|
|
|
|
## Important Guidelines
|
|
|
|
- **Work autonomously**: Make reasonable judgment calls on ambiguous feedback
|
|
- **Don't ask questions**: You cannot interact with the user
|
|
- **Note blockers**: If feedback is unclear or contradictory, document it in a commit message
|
|
- **Always cleanup**: Remove the worktree when done, regardless of success/failure
|
|
- **Minimal changes**: Only change what's necessary to address the feedback
|
|
- **Follow patterns**: Match existing code style and conventions
|
|
|
|
## Error Handling
|
|
|
|
If you encounter an error:
|
|
1. Try to recover if possible
|
|
2. If unrecoverable, push partial work and explain in a comment
|
|
3. Always run the cleanup step
|