implement

name

implement

description

Implement authorized Full-tier work from the bundle's SPEC.md, red-first at pre-agreed seams. Requires an explicit user request to implement or fix production code, and a SPEC whose red-test list covers this exact scope — post-ship review findings and follow-ups go through spec first. Never invoke on your own initiative. Do NOT trigger when the target is a throwaway prototype, research spike, or baseline (explore's scope), or when the fix is a tier-Light quickfix (proceed directly, no skill).

implement

Implement exactly the scope the user authorized, driven by SPEC.md.

Tier first, recon second: decide Light vs Full from the request alone, before reading WORKFLOW.md, bundle files, or the rest of this file. A fix hitting no Full-tier trigger is tier-Light — stop here and do it directly with inline verification; no bundle recon, no bundle, none of the machinery below.

Preconditions: an explicit request to implement or fix, and a SPEC.md whose Testing Decisions name the seams for this exact scope. Missing either — a SPEC that predates the requested scope (post-ship review findings, hardening follow-ups) counts as missing → run spec first. A throwaway prototype not yet approved to port is explore's scope, not this skill's — fix it there without opening the production workflow.

Before writing code, read any language-convention notes the user's setup provides for the language being edited, when they exist. Repository conventions override them.

The loop

For each behavior in scope, in dependency order:

1. Red. Write one failing test at the agreed seam. Run it; watch it fail for the expected reason.
2. Green. Implement the minimum that passes. Run the test.
3. Typecheck and run the touched test files regularly; run the full suite once at the end.

Refresh NOTES.md (Current State, Decisions So Far, Next Action, expected-red tests, dirty-path boundary) after each coherent slice and before ending any turn with work remaining.

Hard rules

• No tests beyond the SPEC's red list. After-the-fact confirmatory tests are bloat — add none.
• Test quality follows references/testing-anti-patterns.md: assert promised behavior at the seam; no weak assertions, no mock-heavy or implementation-coupled tests.
• Never delete, skip, or weaken a failing test to make the suite pass. A failing test is information: fix the code or surface the conflict.
• Functionality not in SPEC scope, or a fork the SPEC never settled: pause the current slice, ask the user exactly one question, record the answer in the SPEC's Implementation Decisions, then continue. A fork needing more than one question is a scout grill pass, not a mid-implement detour.
• Scope the user cuts mid-loop leaves in the same turn: drop it from the SPEC's red list and from VERIFY.md, remove the tests and dead code written for it, and record the cut in NOTES' Decisions So Far.
• When the failure's cause is unknown, diagnosis is the first phase of this authorized fix — do it here, not as a separate engagement.
• A missing external fact (API behavior, library semantics, version differences) is not scope expansion: look it up against primary sources, record the finding and its link in NOTES.md, and continue. If the answer contradicts a SPEC decision, stop and settle it in SPEC.md first.
• A behavior-preserving change (dependency upgrade, refactor): red is the baseline captured via explore before the change; green is the baseline reproducing after. Add no new tests for behavior that isn't changing. A request to change baselined behavior is new scope: re-capture that baseline and record which lines changed and why — editing it silently to match is weakening a test.

Red flags

The thought	The reality
"The test is basically right — I'll adjust the assertion to match the output"	That documents the current bug as expected behavior. Assert from the SPEC's promise and fix the code.
"This one is hard to write red-first; I'll add the test after"	A never-red test proves nothing. Find the seam, or renegotiate it in the SPEC.
"While I'm here, this nearby code could use a cleanup"	Not on the red list means not in scope. Mention it; don't touch it.
"Skipping this failing test unblocks the suite"	A failing test is information. Fix the code or surface the conflict.
"I'll batch all five open forks into one message"	One question per unsettled fork mid-loop; more than one is a scout grill pass.

When the scope is done and the suite is green, run verify.