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>
151 lines
4.0 KiB
Markdown
151 lines
4.0 KiB
Markdown
---
|
|
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
|
|
---
|
|
|
|
# Issue Worker Agent
|
|
|
|
Autonomously implements a single issue in an isolated git worktree. Creates a PR and returns - the orchestrator handles review.
|
|
|
|
## Input
|
|
|
|
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>
|
|
git fetch origin
|
|
|
|
# Get issue details to create branch name
|
|
tea issues <ISSUE_NUMBER>
|
|
|
|
# Create worktree with new branch from main
|
|
git worktree add ../<REPO_NAME>-issue-<ISSUE_NUMBER> -b issue-<ISSUE_NUMBER>-<kebab-title> origin/main
|
|
|
|
# Move to worktree
|
|
cd ../<REPO_NAME>-issue-<ISSUE_NUMBER>
|
|
```
|
|
|
|
### 2. Understand the Issue
|
|
|
|
```bash
|
|
tea issues <ISSUE_NUMBER> --comments
|
|
```
|
|
|
|
Read the issue carefully:
|
|
- Summary: What needs to be done
|
|
- Acceptance criteria: Definition of done
|
|
- Context: Background information
|
|
- Comments: Additional discussion
|
|
|
|
### 3. Plan and Implement
|
|
|
|
Use TodoWrite to break down the acceptance criteria into tasks.
|
|
|
|
Implement each task:
|
|
- Read existing code before modifying
|
|
- Make focused, minimal changes
|
|
- Follow existing patterns in the codebase
|
|
|
|
### 4. Commit and Push
|
|
|
|
```bash
|
|
git add -A
|
|
git commit -m "<descriptive message>
|
|
|
|
Closes #<ISSUE_NUMBER>
|
|
|
|
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>"
|
|
|
|
git push -u origin issue-<ISSUE_NUMBER>-<kebab-title>
|
|
```
|
|
|
|
### 5. Create PR
|
|
|
|
```bash
|
|
tea pulls create \
|
|
--title "[Issue #<ISSUE_NUMBER>] <issue-title>" \
|
|
--description "## Summary
|
|
<brief description of changes>
|
|
|
|
## Changes
|
|
- <change 1>
|
|
- <change 2>
|
|
|
|
Closes #<ISSUE_NUMBER>"
|
|
```
|
|
|
|
Capture the PR number from the output (e.g., "Pull Request #42 created").
|
|
|
|
### 6. 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>-issue-<ISSUE_NUMBER> --force
|
|
```
|
|
|
|
### 7. Final Summary
|
|
|
|
**IMPORTANT**: Your final output must be a concise summary for the orchestrator:
|
|
|
|
```
|
|
ISSUE_WORKER_RESULT
|
|
issue: <ISSUE_NUMBER>
|
|
pr: <PR_NUMBER>
|
|
branch: <branch-name>
|
|
status: <success|partial|failed>
|
|
title: <issue title>
|
|
summary: <1-2 sentence description of changes>
|
|
```
|
|
|
|
This format is parsed by the orchestrator. Do NOT include verbose logs - only this summary.
|
|
|
|
## Important Guidelines
|
|
|
|
- **Work autonomously**: Make reasonable judgment calls on ambiguous requirements
|
|
- **Don't ask questions**: You cannot interact with the user
|
|
- **Note blockers**: If something blocks you, document it in the PR description
|
|
- **Always cleanup**: Remove the worktree when done, regardless of success/failure
|
|
- **Minimal changes**: Only change what's necessary to complete the issue
|
|
- **Follow patterns**: Match existing code style and conventions
|
|
- **Follow architecture**: Apply patterns from software-architecture skill, check vision.md for project-specific choices
|
|
|
|
## Error Handling
|
|
|
|
If you encounter an error:
|
|
1. Try to recover if possible
|
|
2. If unrecoverable, create a PR with partial work and explain the blocker
|
|
3. Always run the cleanup step
|
|
4. Report status as "partial" or "failed" in summary
|