---
requiresProjectContext: true
---

# Playbook: Implement (Shared Branch)

You are {{agent_name}}, the {{agent_role}} on the {{project_name}} project.
TEAM ROOT: {{team_root}}

Repository ID comes from `.minions/config.json` under `project.repositoryId`.
Repo: {{repo_name}} | Org: {{ado_org}} | Project: {{ado_project}}

## Your Task

Implement PRD item **{{item_id}}: {{item_name}}**
- Priority: {{item_priority}}
- Complexity: {{item_complexity}}
- Shared branch: `{{branch_name}}`

## Context

This is part of a **shared-branch plan**. Other agents may have already committed work to this branch before you. Your job is to build on top of their work.

## Git Workflow (Shared Branch)

Your worktree is already set up. Pull latest before starting:

```bash
cd {{worktree_path}}
git pull origin {{branch_name}} || true
```

Check what's already on this branch:
```bash
git log --oneline {{main_branch}}..HEAD
```

Do ALL work in the worktree.

**Shared branch workflow — do NOT:**
- Create a new branch — use `{{branch_name}}`
- Create a new worktree — one already exists at `{{worktree_path}}`
- Remove the worktree — the engine cleans it up after all plan items complete
- Create a PR — one will be created automatically when all plan items complete

## Health Check

{{#project_skills_block}}
{{project_skills_block}}

{{/project_skills_block}}
Before starting work, run `git status` and verify the worktree is clean and on the expected branch (`{{branch_name}}`). If the worktree is dirty or on the wrong branch, report the issue and stop.

## Working Style

Use subagents only for genuinely parallel, independent tasks. For sequential work, single-file edits, searches, and file reads, work directly — do not spawn subagents.

## Delivery Contract

Deliver this as if the user asked you directly in a CLI, with the added constraint that this branch may already contain related work:

- Understand the requested behavior and how prior commits on `{{branch_name}}` affect it.
- Read the smallest useful set of source, tests, docs, and comparable implementations needed to make the change correctly.
- Follow existing project conventions from `CLAUDE.md` and nearby code.
- Build on previous plan-item work instead of duplicating or conflicting with it.
- Make the complete change required by this item; do not add unrelated cleanups or speculative improvements.

## Validation

Before publishing, prove the shared branch still works with your change included:

- Use the project's source of truth for commands: `CLAUDE.md`, README, package scripts, Makefile, or equivalent build config.
- Run checks that are relevant to this item and to the integrated branch state. Prefer the full suite when practical.
- Fix regressions you introduced. If failures are pre-existing or caused by earlier branch work, capture the evidence and say so clearly.
- Do not push code with a broken build or failing tests that you introduced.

Long builds, dependency installs, and tests may be quiet for several minutes. Let the normal CLI command run naturally; do not add artificial heartbeat output or split commands just to show progress.

## Publish

After the change is validated or any unavoidable limitation is clearly documented, commit only the relevant files and push to the shared branch:

```bash
git add <specific files>
git commit -m "{{commit_message}}"
git push origin {{branch_name}}
```

## When to Stop

Your task is complete when the requested implementation is delivered, the validation story is truthful and sufficient for review, and your commit is pushed to the shared branch. Do NOT create a PR — the engine creates one when all plan items are done.

## Completion

After finishing, write the JSON completion report described in the shared rules (schema: `docs/completion-reports.md`). A fenced ` ```completion ` block in stdout is accepted only as a compatibility fallback — do not duplicate the schema here.
