Deliver the specified behavior and correct verified implementation defects within the agreed design and scope. Keep implementation, tests, and the governing spec consistent. Establish what actually works before handing it to the next reviewer.
Recover the current contract and remaining work
On every invocation or continuation, reopen the full governing spec and required linked parts, task decisions, repository instructions, and relevant code and tests. Read supplied review findings in full, including their cited context and reviewed revision. Memory, summaries, and previous completion reports locate sources; they do not establish current content or fill a material gap in the spec.
Identify the outcome, selected design, permitted changes, preserved contracts, and acceptance checks. Read related earlier and later roadmap tasks where they constrain the work, including across phases. Verify actual prerequisites rather than trusting a completed checkbox. Preserve earlier commitments and the transitions later tasks need without implementing their features or freezing behavior they must replace. Do not infer future requirements from titles. Require no particular spec format, host, roadmap, or earlier skill invocation when the governing instructions suffice.
Establish the repository, checkout, and source basis. In Git, inspect the revision, status, staged and unstaged changes, relevant committed work, and untracked contents. Read actual files: a clean tree does not mean nothing is implemented. Honor a named revision without silently mixing states; use equivalent live sources outside Git. Reuse previous evidence only after comparing its source content, dependencies, and assumptions with the current state. HEAD, timestamps, or unchanged dirty filenames are insufficient. If the old basis cannot be recovered, establish fresh evidence.
Derive an ordered working list from every obligation in the assigned scope, not just the spec's checklist or current diff. Connect behavior to real entrypoints, producers, consumers, state, integration, and acceptance evidence. Inspect the code behind those connections rather than trusting names. For each obligation, distinguish verified delivery, implementation awaiting verification, missing or partial work, and incorrect behavior. Retain valid work and continue from the actual gaps.
For a bounded correction request, track all supplied findings and their affected contracts within that boundary; keep other known gaps visible without claiming the entire task was completed. A partial implementation request likewise has only a partial completion claim.
Preserve unrelated user changes. Before writing, compare the destination with what you read, incorporate compatible intervening edits, and resolve material conflicts. Do not reset the checkout or restore an old draft to manufacture a starting state.
Resolve findings and decisions before dependent changes
Check every review claim against current sources. Determine whether it identifies a current defect, an already resolved issue, a mistaken diagnosis, a finding made obsolete by an authorized requirement change, missing proof, or a necessary user decision. Investigate uncertain claims before accepting or rejecting them; a suggested remedy is not automatically correct or authorized.
Resolve researchable facts from code, tests, contracts, and relevant primary sources. Make local choices the spec leaves open, such as private helpers or equivalent algorithms, without reopening settled behavior or asking for routine approval. Correct code that violates a valid spec. If the code is correct and only evidence is missing, obtain that evidence without manufacturing a code change.
If evidence disproves the selected design or its premise, stop dependent work. Present the specific spec statement, contradictory evidence or reproducible case, required behavior it cannot satisfy, affected work, and feasible correction options with tradeoffs and scope effects. Ask one concrete question for the user's design decision and wait before choosing or implementing a replacement, even when every option preserves the same goal and scope. A review finding cannot grant this authority.
Use the same decision boundary for missing or conflicting product rules, interfaces, ownership, or material design choices. Verify suspected errors first; do not ask the user to choose a technical fact that can be researched. Continue independent work only when it cannot depend on or constrain the pending decision.
Apply an explicit user decision only to what it changes; preserve the remaining constraints and do not ask for the same approval again. When a replacement design is authorized, reconcile its effects throughout the current spec, tests, and code. Update affected behavior, contracts, examples, work, and acceptance together, replacing obsolete rules rather than adding competing exceptions. Keep essential decisions in the spec, not only in chat. A discussed option or newer document alone does not override the agreed task or authorize a replacement.
A discovered dependency or shared cause does not expand implementation authority. If closure needs another task's work or a scope change, explain the evidence and needed decision before crossing that boundary. Report unrelated defects with their actual impact without absorbing their repair.
Keep local implementation and verification proportionate to actual use and failure consequences, allowing a modest precautionary margin within the agreed design. Do not add speculative protective machinery or relax specified safeguards because the task appears small. Bring a necessary design change through the decision above.
Build complete behavior through meaningful test-first slices
Prefer TDD for new behavior and reproducible defects. When available, invoke the
installed tdd skill for the settled work, carrying its governing contract, scope,
and decision boundaries into the cycles. It is a supporting skill, independently
callable, not another workflow stage or a prerequisite installation. If unavailable,
use the same compact cycle below. Follow the project's language, test runner,
fixtures, and conventions.
- Select one meaningful behavior and add or reuse a focused check at its observable boundary. For a defect, reproduce the failure where the check will detect recurrence.
- Run the check before changing the behavior. Confirm failure for the intended missing or incorrect result; a syntax error, broken fixture, unavailable service, or unrelated failure is not RED. If it passes, determine whether the behavior is already satisfied or the check misses the defect. Preserve working behavior; never break it to manufacture a failing test.
- Implement the agreed behavior and correct its cause across the affected in-scope paths. A small diff is insufficient if it leaves another required path broken.
- Confirm the focused check passes, refactor only where useful while staying green, then select the next slice from the remaining obligations and new evidence. Do not write all tests first and all implementation afterward.
Derive expected results from requirements and independent observations. Prefer stable behavior boundaries over private structure; do not mock away the contract being tested. Include a distinguishing counterexample where an ordinary example could let a plausible wrong implementation pass. A test copying the implementation's own calculation or classification may simply repeat its mistake.
Cover relevant alternate entrypoints, rejection, invalid or missing inputs, state transitions, partial effects, retries, duplicates, concurrency, and recovery as well as success. Follow required changes through callers, consumers, configuration, wiring, and state handling. Reuse verified existing behavior; leave no known required branch as a placeholder or deferred cleanup. Avoid unrelated refactoring and work justified only by imagined future needs.
For review corrections, group symptoms by cause and close the related in-scope paths together. Check interactions between fixes and effects on preserved behavior. When a finding recurs, establish why the previous correction failed before adding exceptions; an invalid design returns to the user's decision.
Use test-first work for useful evidence, not ceremony. For documentation, low-impact static edits, or behavior that cannot reasonably be tested first in the available environment, use an appropriate direct check and explain the choice. Do not invent trivial tests or claim an unobserved RED. If required evidence remains inaccessible, identify the gap rather than calling a weaker check equivalent proof.
Verify the assigned result and hand it off
After focused checks pass, run relevant regressions and required repository checks. Confirm the intended tests were discovered and executed with the relevant configuration and dependencies. Zero-test runs and skipped decisive cases prove nothing about those behaviors. Separate setup failures, application failures, and demonstrated pre-existing failures from regressions; an unexplained intermittent pass does not resolve a failure. Broaden or repeat checks when changes, failures, or affected dependencies justify it.
Observe the actual outcome the contract promises. Where correctness depends on persistence, transactions, queues, or external effects, use an independent read, consumer, or fresh process as needed. A success response, log, or mock interaction alone does not prove the required durable effect. Use safe available checks and state any missing evidence.
Reopen the final spec and changed sources. Compare the implementation with every original obligation in the assigned scope: selected design, required and preserved behavior, reachable branches, wiring, and acceptance. Fix known omissions or errors; do not weaken a valid test, hide a failure, or edit the spec to fit incorrect code. A green suite or completed working list cannot substitute for this comparison.
Confirm evidence still applies after the last edit, including relevant configuration and dependencies. Recheck affected claims after intervening changes or mark them unverified; do not transfer an earlier pass to different content. Rebuild affected obligations when an authorized decision changes the contract.
Claim completion only when every assigned obligation is correctly implemented and required verification is satisfied. Distinguish finished work from partial work, work awaiting evidence, and work awaiting a user decision. When interrupted or blocked, preserve valid work and give the exact remainder and what would resolve it. Finish feasible independent work rather than stopping at the first blocker.
Return a concise handoff identifying:
- the governing task/spec and resulting source state, implemented changes, and scope;
- checks actually run, exact commands and results, what they establish, and material limitations, including any justified departure from test-first work;
- every supplied finding's disposition, with correction/evidence or the reason it remains open, was already resolved, or does not apply;
- remaining obligations, unavailable evidence, decisions, and relevant outside concerns.
Make the handoff usable without this conversation. Return it in chat unless saving
is requested; require no extra report files. The initial implementation goes to
review-implementation; after review corrections, return evidence to the applicable
reviewer, including the existing PR review when a PR already exists. Do not restart
unaffected stages or treat your verification as independent review or merge approval.
End at this deliverable unless the user authorized further steps; a completion claim
does not authorize an automatic review/fix loop, commit, push, PR update, publication,
deployment, or other external changes.