implement

What this skill does

## Pre-loaded Context

Active scopes:
!`find scopes -maxdepth 3 -name scope.md 2>/dev/null`

Checkpoints:
!`find scopes -name checkpoint.yaml -maxdepth 3 2>/dev/null`

Git status:
!`git status --short 2>/dev/null`

Current branch:
!`git branch --show-current 2>/dev/null`

# Implementation & Scope Execution

Executes scopes and tasks via three-phase TDD pipeline (tester → implementer → reviewer).

**INVARIANT: The orchestrator NEVER writes code or tests.** All code authoring — including test code — MUST be delegated to fresh subagents. This applies to ALL routes: scope execution, single tasks, file paths, and task descriptions. No exceptions.

---

## Auto-Detect Rules

**Pre-parse:** Extract these directives from `$ARGUMENTS` before pattern matching:
- `--reviewers <aliases>` — comma-separated list from `{opus, sonnet, gpt, gemini, gemini-pro, gemini-flash}`. Resolution and alias table: `/review` SKILL.md "Reviewer Selection". Resolved list is passed to Phase A.5 + Phase C dispatch. If absent and `validation.yaml.review_config` is also absent, fall back to the interactive AskUserQuestion prompt (same as `/review`).
- `--worktree` (or bare `worktree`) — checkout the determined branch as a `git worktree add ...` instead of in-place `git switch`. See "Git Workflow" → "Procedure" step 4.
- `--base <branch>` — base branch for new-branch creation. If absent and the branch doesn't exist, AskUserQuestion. See "Git Workflow" → "Procedure" step 3.
- `--state <draft|open>` — PR state when auto-creating a pull request at the end of execution (default: `draft`). Only used when `$ARGUMENTS` contains an issue reference.
- `gh:<n>`, `#<n>`, or a GitHub issue URL — flags GitHub-issue branch naming AND enables auto-PR creation after final review. See "Git Workflow" → "Branch Determination" and `operations/execute.md` Step 10.

Apply these rules to remaining `$ARGUMENTS` in order:

| Pattern | Route | Action |
|---|---|---|
| "verify" or "done" | Verify | Read and follow `operations/verify.md` |
| "debug" or "trace" | Debug | Read and follow `operations/debug.md` |
| Matches `./scopes/*/*/` path | Execute | Read and follow `operations/execute.md` |
| Exactly one active scope | Execute | Read and follow `operations/execute.md` |
| File path or task description | Direct | Use methodology below |
| No argument | Menu | See fallback |

---

## Menu Fallback

When no argument or ambiguous, use **AskUserQuestion**:

```
Header: Implement
Question: What would you like to do?
multiSelect: false
Options:
- Scope execution: Execute active scope with TDD pipeline (tester → implementer → reviewer)
- Verify: Evidence-based verification before claiming done
- Debug: Root cause tracing for a bug or failure
- Implement: Single implementation task with methodology below
```

**Routing by selection:**

| Selection | Action |
|---|---|
| Scope execution | Read and follow `operations/execute.md` |
| Verify | Read and follow `operations/verify.md` |
| Debug | Read and follow `operations/debug.md` |
| Implement | Use methodology below |

---

## When to Use

- Executing a scope's tasks via three-phase pipeline
- Building features from requirements
- Writing code or creating artifacts
- Deciding on structure, patterns, or approach
- Designing domain models or data structures
- Verifying completion or debugging failures

---

## Git Workflow

**MANDATORY:** The dispatcher MUST ensure a dedicated branch is checked out before dispatching any phase. Never run implementation phases on `main`/`master` or on an unrelated branch.

### Branch Determination

Detect the branch source from `$ARGUMENTS` and apply the matching naming convention:

| Source | Detection | Branch Name | Example |
|---|---|---|---|
| GitHub issue | `gh:<n>`, `#<n>`, or `github.com/<owner>/<repo>/issues/<n>` | `<issue#>-<issue-title-in-kebab-case>` | `142-add-user-auth` |
| Scope | `./scopes/<state>/<name>/` path or active scope | `feat/<scope-name>` | `feat/user-auth` |
| Direct task | File path or task description, no scope/issue | **AskUserQuestion** (see below) | — |

**For GitHub issues:** Fetch the title with `gh issue view <n> --json title -q .title`, kebab-case it (lowercase, spaces/punctuation → `-`, collapse repeats, trim), then prefix with the issue number. Do NOT add a `feat/` prefix — match GitHub's own branch convention.

### Procedure

1. **Determine branch name** per the table above.
2. **If source is unclear or ambiguous** (no scope, no issue ref, multiple candidates) → **AskUserQuestion**:
   ```
   Header: Branch
   Question: No branch detected for this work. How should I proceed?
   multiSelect: false
   Options:
   - Use current branch: <current-branch>
   - Create new branch: provide name
   - GitHub issue: provide issue number
   ```
3. **Resolve base branch** (only needed when creating a new branch):
   - Skip if branch already exists locally or on remote.
   - If `--base <branch>` was passed in `$ARGUMENTS` → use it.
   - Else → **AskUserQuestion**:
     ```
     Header: Base branch
     Question: New branch <name> needs a base. Which branch should it fork from?
     multiSelect: false
     Options:
     - main (default trunk)
     - <current-branch> (current — pick if cascading)
     - Other: provide branch name
     ```
   - Verify the base exists (`git rev-parse --verify <base>`) before proceeding.
4. **Checkout mode** — pre-parse `--worktree` (or `worktree`) from `$ARGUMENTS`:
   - **Worktree directive present** → follow `skills/git/reference/worktree.md` end-to-end with `BRANCH_NAME=<branch>` from step 1 and the resolved base from step 3. All subsequent phases run from the reported worktree path.
   - **No worktree directive** → in-place checkout:
     - Branch exists locally → `git switch <name>` and pull latest
     - Branch exists on remote → `git switch <name>` (tracks remote)
     - Otherwise → `git switch -c <name> <base>` using the resolved base from step 3
5. **Verify** current working tree is on the determined branch before dispatching Phase A.

**Never** dispatch testers/implementers/reviewers while still on `main`, `master`, or a stale unrelated branch.

---

## Process (Single-Task Pipeline)

**The orchestrator NEVER writes code or tests.** All code authoring is delegated to subagents.

Even for a single task, the four-phase pipeline applies:

### Phase A: Dispatch Tester Subagent

Dispatch a **fresh tester subagent** (`subagent_type: "general"`) to write failing tests.

- Tester reads task requirements and discovers expected behavior independently
- Tester writes tests and verifies RED state
- Orchestrator verifies RED (see Quality Gates in `operations/execute.md`)

**Why a separate subagent?** The orchestrator's understanding of the task leaks into hand-written tests, causing oracle mirroring (tests that mirror implementation logic) and mock tautologies (mocks that assume the answer). A fresh subagent discovers behavior from code and specs independently.

### Phase A.5: Test Review Gate

Dispatch **all configured reviewers in parallel** (Claude `Task` + Pi `Bash` × N per `/review` config) on the test files from Phase A. Same cartesian dispatch pattern as Phase C — Pi shell-outs are mandatory whenever Pi is installed.

- Reviewers check for oracle mirroring, mock tautologies, framework tests, trivial assertions
- Synthesize findings: a test is flagged if any harness reports `issues_found`
- If issues found → re-dispatch tester with specific feedback; repeat until clean
- **Gate:** Implementer NEVER receives tests that failed this review

See dispatch template in `reference/subagent-workflow.md` — Test Review Dispatch Template.

### Phase B: Dispatch Implementer Subagent

Dispatch a **fresh implementer subagent** (`subagent_type: "general"`) with the test-review-cleared tester report.

- Implementer makes tests pass (GREEN)
- Implementer refactors while staying green

### Phase C: Review

For single tasks, review can be done inline or via reviewer subagent(s) depending on scope.

###