Implement

Implement workflow

Implement one bounded unit in the current worktree. Prefer the smallest complete change that satisfies the requested behavior. The current agent researches and implements the unit directly, so do not write the implementation twice as a code-bearing plan.

Presets increase required evidence, not architecture, abstractions, tests, or documentation.

Arguments

Arguments are $ARGUMENTS.

Parse these flags before starting:

• --preset light|standard|design|strict: default standard
• --parent-plan <path>: authoritative scope or phase brief
• --reviewer <selector>: consult-llm reviewer selector, repeatable
• --reviewers <selector,selector>: comma-separated reviewer selectors
• --validation <command>: expected validation command

Everything else is the implementation request.

Presets:

• light: an established local pattern, focused validation, no external review
• standard: the default, acceptance evidence and runtime exercise where applicable, no routine external review
• design: a meaningful API, ownership, or architecture choice, with one source-grounded technical-shape review before edits
• strict: authentication, secrets, untrusted input, protocols, migrations, persistence, destructive behavior, concurrency, or FFI, with boundary-focused evidence and one final diff review

Treat a component with a strict boundary as strict even when the selected preset is lighter. Strictness adds relevant proof. It does not justify speculative hardening.

Do not ask the user during the workflow unless continuing safely requires a material product choice, public or irreversible contract, dependency, durable-state change, trust-model change, unsafe overwrite, or major scope expansion.

Working record

Keep at most one evolving implementation brief under history/ with today's date prefix. A brief is required only when:

• the preset is design or strict
• the caller explicitly requests one
• discoveries are complex enough that a durable execution record prevents mistakes

A sufficient parent plan replaces the brief. Add a local note only for material facts or deviations absent from the parent plan.

Use this compact shape when a brief is needed:

# Implement: <topic>

**Goal:** <one observable outcome>
**Preset:** <preset>
**Parent plan:** <path or n/a>
**Validation:** <commands>

## Scope

- In:
- Out:

## Source facts

- `<path>:<symbol>`: <ownership, contract, or convention>

## Technical shape

- Existing mechanisms to reuse:
- Smallest complete slice:
- Acceptance evidence:
- Real trust or compatibility boundaries:
- Stop conditions:

## Accepted review findings

- <only independently reproduced findings>

## Result

- Acceptance evidence:
- Validation:
- Commit:
- Blockers:

Do not pre-write source or test code in the brief. Do not create separate plans, proposal captures, feedback ledgers, or review transcripts. Update the brief only when scope, technical ownership, accepted evidence, or the result changes. Briefs are workflow records. Do not stage or commit them.

A result sentinel is a separate artifact only when a parent plan or caller requires one.

1. Establish facts

1. Read active repository instructions and relevant architecture documentation.
2. Record git rev-parse HEAD and inspect git status --short.
3. Stop before overwriting or unsafely entangling unrelated user changes.
4. Read a supplied parent plan and treat its scope and acceptance criteria as authoritative.
5. Find the nearest existing implementation, callers, tests, configuration, and runtime path. Prefer repository mechanisms over new ones.
6. Define the observable outcome, explicit non-goals, smallest complete slice, actual trust or compatibility boundaries, and acceptance evidence.
7. Select the narrowest useful focused checks plus every repository-required check. Use --validation unless it is plainly wrong.

Do not invent future consumers, extension points, defensive layers, or tests for unchanged framework behavior.

2. Review the technical shape when required

Skip this section unless the preset is design. A run receives at most one external review. Do not run a second review to approve corrections.

Before calling consult-llm, load the consult-llm skill and follow its invocation contract. Attach the brief or parent plan and focused source files. Use --task review, supplied reviewer selectors when present, the quoted heredoc terminator __CONSULT_LLM_END__, and Bash timeout 600000.

Ask whether the technical shape demonstrably conflicts with source-established ownership, behavior, contracts, or trust boundaries. Do not ask for a replacement plan or general hardening advice.

Every reported finding must include:

• Claim: the specific incorrect behavior, contradiction, or execution blocker
• Trigger: the concrete input, state, caller, or plan step that exposes it
• Expected: the acceptance criterion, existing contract, repository convention, or real boundary requirement
• Actual: the behavior the proposed shape would produce
• Evidence: exact files and symbols plus a manual procedure, command, or complete reachable source trace
• Smallest correction: the minimum change that fixes the issue
• Verification: the check that proves the correction

Tell the reviewer to return no findings when no issue meets this standard. General hardening, hypothetical edge cases, style preferences, alternative valid designs, and speculative callers are not findings.

Independently confirm each finding before accepting it. For a pre-implementation finding, compare the named plan step with the complete current source path and identify the exact contract or acceptance criterion that would fail. Reviewer assertions alone are not evidence.

Ignore findings that cannot be reproduced, have no reachable trigger, protect no accepted behavior or real boundary, duplicate lower-layer guarantees, or ask for more hardening than the demonstrated issue requires. Record only accepted findings and their smallest corrections in the brief. Do not preserve rejected feedback in a ledger.