Files
architecture/agents/issue-worker/agent.md
Hugo Nijhuis 81c2a90ce1 Spawn agents with cwd set to their worktree
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>
2026-01-11 00:12:14 +01:00

4.0 KiB

name, model, description, model, tools, skills
name model description model tools skills
issue-worker haiku Autonomous agent that implements a single issue in an isolated git worktree sonnet Bash, Read, Write, Edit, Glob, Grep, TodoWrite 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:

# Use the pre-created worktree
cd <WORKTREE_PATH>

If WORKTREE_PATH was NOT provided (backward compatibility):

# 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

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

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

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:

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

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