J03Fr0st Implement
Turn an authorized change into the smallest coherent, verified repository update. A plan can help, but it is not an entry requirement.
Operating contract
Accept a direct request, issue, specification, or implementation plan. Treat the user's latest instruction and applicable repository rules as authoritative; use linked artifacts to resolve detail, not to expand scope silently.
An instruction such as "implement," "build," "change," "fix it," or "do it" authorizes the repository edits needed for that request. It does not automatically authorize commits, pushes, releases, issue updates, deployments, destructive data operations, or unrelated cleanup.
If the user asks only how to implement, requests an approach comparison, or says not to change anything yet, stay read-only. Use codebase-design when the requested comparison is a consequential architecture or seam decision; otherwise provide the bounded analysis directly.
Preserve work already present. Never discard, overwrite, reset, clean, or hide a dirty worktree to simplify implementation. Keep task-owned changes distinguishable from pre-existing changes. For major work in a dirty primary checkout, show the exact state and ask before creating or switching to an isolated worktree.
1. Frame the change
Read the repository instructions, relevant source, nearby tests, and supplied intent. State the observable outcome, acceptance conditions, explicit exclusions, and any constraint that changes the implementation approach.
Inspect the current branch, HEAD, staged and unstaged changes, and untracked files before editing. Ask only when a missing decision would materially change behavior, architecture, external state, cost, or risk. Otherwise make the smallest reasonable assumption and record it.
Complete when: the intended outcome, working-tree baseline, governing rules, and material decision gates are known.
2. Choose the execution route
Use the narrowest workflow that fits the evidence:
| Situation | Route |
|---|---|
| Cause of a reported failure is unknown | Run diagnosing-bugs, then resume with its confirmed cause or honest uncertainty |
| Observable behavior is changing and an executable harness is practical | Run tdd for each coherent behavior slice |
| Working code needs a requested behavior-preserving cleanup | Use simplify for the scoped pass, then resume final verification |
| Documentation, metadata, generated output, or a mechanical change has no useful behavioral test | Edit directly and define artifact-specific checks |
| A module boundary or ownership decision blocks safe progress | Use codebase-design for that decision, then resume |
| A large clear outcome lacks verifiable slices or a dependency order | Use planning-and-task-breakdown, then execute its ready frontier within the existing authorization |
| An external API or version-dependent claim is uncertain | Use research for the needed evidence, then resume |
| A design choice needs an observable experiment | Use prototype for the question when building the experiment is within scope, then resume |
| Security or privacy risk requires a dedicated audit or repository gate | Use security-review alongside any required repository checks and preserve its independent evidence |
| User requested review without changes | Stop and use code-review |
Parallel work is an explicit optimization, not the default. Use it only for genuinely independent seams, when agent delegation is available and authorized, and when integration ownership is clear. Do not place parallel workers on overlapping files, shared schemas, or an unresolved design decision.
Give each delegated unit one accountable owner, acceptance checks, and a required return artifact. Await and inspect that artifact before marking the unit complete; a status promise or re-delegation is pending work. Integrate compact evidence receipts instead of entire worker transcripts.
Use a worktree only when isolation is useful and the user or repository workflow permits it. Before work begins, verify its base commit and whether ignored fixtures, local databases, credentials, generated assets, or other local-only material are required. A worktree that cannot run the decisive check is not a valid execution environment.
Complete when: the implementation method and its verification path fit this change rather than a generic ceremony.
3. Implement in coherent slices
For each slice:
- Inspect the current owner, callers, contracts, and tests at the affected seam.
- Make the minimum complete change that delivers one observable outcome.
- Update tests, documentation, configuration, migrations, and generated artifacts that are part of the same contract.
- Run the smallest useful check while the slice is still easy to reason about.
- Re-read the diff for accidental scope growth before starting another slice.
Do not mix opportunistic cleanup into the change. If new evidence invalidates the requested approach, reaches outside the authorized scope, or exposes a consequential product or architecture decision, stop at that gate and present the evidence and options.
When a check exposes an unrelated pre-existing failure, separate it from change-caused failures. Do not repair it unless the user expands scope.
Complete when: every accepted behavior is represented by a coherent change and no known task-owned inconsistency remains between code, tests, docs, and configuration.
4. Reconcile the repository state
Inspect the complete task diff, including new files. Confirm that:
- pre-existing work remains intact;
- every changed path belongs to the requested outcome;
- temporary instrumentation and scratch artifacts are gone;
- generated files correspond to their source inputs;
- delegated work, if any, was reviewed and integrated against the actual current branch.
Do not stage or commit unless requested. A clean targeted check does not make unrelated dirty paths part of the task.
Complete when: the final change set is intentional, integrated, and attributable.
5. Verify before claiming completion
Run verification-before-completion against the acceptance conditions after the final relevant edit. Fresh evidence must cover the actual changed behavior and required artifacts. A previously green command, an implementer's report, or an exit code without evidence that the intended test ran is not enough.
If verification fails, return to the smallest responsible slice. If verification is unavailable, partial, destructive, costly, or needs new authority, preserve that boundary and report the corresponding honest terminal state instead of saying the work is done.
When review finds a defect within the authorized scope, fix it and rerun the affected checks. If the same concern survives two correction attempts, switch to diagnosis with the failed attempts as evidence. Continue when new evidence changes the approach; report the concrete blocker when the remaining step needs unavailable input or authority. Do not rerun an unchanged review loop or end authorized work merely because the retry bound was reached.
For long or resumable work, update the existing issue, plan, cycle record, or repository artifact with the base commit, pre-existing dirty paths, completed slices, evidence, and material decisions. Use a task-scoped scratch ledger only when no canonical artifact exists, and do not publish it without authorization.
At a pause, pickup, or transfer to another session, harness, directory, or person, use handoff for the continuation record. Ordinary final delivery uses the summary below.
Handoff
Report:
- Outcome: what observable behavior or artifact changed.
- Scope: task-owned files changed, plus any pre-existing dirty state left untouched.
- Evidence: fresh commands or inspections and their results.
- Decisions: assumptions made and human decisions still required.
- Residuals: unverified behavior, known failures, or explicitly deferred work.
Do not claim "done," "fixed," "passing," or "ready" unless the verification verdict supports that exact claim.