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, tests-after, 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 tests, and when, 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/0007-plan-sso-2026-07-23.md", "implement this spec", "do this the TDD way", "build it and add tests for it", "make this failing test pass". Tests for code that already runs and was never tested are a retrofit, which belongs to testkit when it is installed. 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/NNNN-plan-<slug>-YYYY-MM-DD.md, or an older one without the NNNN- serial), an issue (#42, or a URL/id gh can fetch), a freeform spec written in the prompt, or a fix round. A fix round takes one of two forms: a concrete list of review findings (e.g. the blockers from a review pass), each naming what's wrong and where, or a failing reproduction test (e.g. from debugkit) with the cause it proves. Do not hunt for an input: if nothing is named, stop and ask what to implement. The one exception is an issue branch. When the prompt names nothing and the current branch matches issue-<n>-<slug> (the shape gitkit gives a worktree started from an issue), take issue #<n> as the named input and say the branch supplied it. Any other branch shape still stops and asks. 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). The step is done when the whole input has been read, or the run has stopped to ask for it.