implementkit

Turn a hardened plan, spec, or issue into working code, and stop there. implementkit is the build step between a settled plan and a clean commit: it reads an explicit input, resolves how to build (straight-through or test-driven), writes the code, and proves it with the repo's own test and build gate before it calls the work done. It never commits, because that's commitkit's job, and it never designs, because an underspecified input is bounced back to plankit/grillkit, not guessed at.

Its defining feature is mode resolution: the same request builds differently depending on whether the repo (or the user) wants test-driven development, and implementkit works that out by a fixed precedence rather than defaulting blindly.

When this fires

The user hands off something concrete to be built: "implement this plan", "build issue #42", "write the code for docs/plans/plan-sso-2026-07-23.md", "implement this spec", "do this the TDD way". It is the implementkit step of the plan → grill → file → build → commit workflow.

Two hard boundaries:

• It does not commit or stage. It leaves the finished work as unstaged changes and reports what it did; commitkit groups and commits.
• It does not design. If the input is too thin to build without inventing the design, it stops and points back to grillkit/plankit. implementkit turns a settled intent into code; it doesn't settle the intent.

Procedure

1. Take an explicit input

Require the user to name what to build. The options are a plan file (docs/plans/plan-<slug>-YYYY-MM-DD.md), an issue (#42, or a URL/id gh can fetch), a freeform spec written in the prompt, or a fix round: a concrete list of review findings (e.g. the blockers from a review pass), each naming what's wrong and where. Do not hunt for an input: if nothing is named, stop and ask what to implement. Read the named input in full (for an issue, fetch it with gh issue view <n>; if gh isn't available, ask the user to paste it).