implement-feature

Implement Feature

Make the frozen behavior contract true. Implementation may choose the design inside that boundary; it may not silently change the boundary.

Preflight

1. Bind the active issue first: loopbreaker link ISSUE. The admission hook is keyed to that binding — without it the gate is inert and pre-admission edits are silently allowed. This is the single easiest way to appear gated while being ungated.
2. Call delivery_readiness. Stop unless discovery is satisfied, shape is ready, planning is ready, and planning_review.approved plus implementation.admitted are true.
3. Call review_substrate for the issue and return the exact active gate when held.
4. Confirm the requested work maps to named behavior IDs and planning work units.
5. Read repository instructions and the production construction path.
6. Inspect current status and preserve unrelated worktree changes.

If the issue is held at discovery, stop and use $discovery-interview; the premise is not yours to author. If there is no imported contract or planning profile, stop and use $plan-feature. If planning is structurally ready but not independently approved, use $review-planning; never self-approve from this skill. If the requested change would add acceptance requirements, report the scope change instead of coding it as an incidental improvement.

Execution: harness first, then code

Evidence is executed, never asserted. You cannot record a verdict; you can only run a registered harness and let its exit code decide. review_record_evidence still exists for supporting observations, but evidence recorded that way is marked not-executed and will not verify an enforced behavior.

For each behavior, in this order:

1. Write its harness before the implementation. Drive the behavior at the tier its contract names — a real CLI/HTTP/subprocess boundary for wired, a real deployed target for live. The repository may have no test tooling at all; if so, standing that tooling up is part of the work, not a reason to skip it.
2. Register it in harnesses.json with id, tier, runner, target, and a proves list naming this behavior. runner: "script" executes the target directly, so any toolchain works — bun, pytest, a shell script. The registry is a reviewed file; that is what keeps prove from being arbitrary execution.
3. Bind it: loopbreaker bind BEHAVIOR --harness ID. Both directions must agree — the behavior names the harness and the entry names the behavior back.
4. Prove it RED through the gate: loopbreaker prove BEHAVIOR. It must fail before the code exists. A harness that is green before the work proves nothing.