bkit-claude-code: a Claude Code plugin that measures generated code against its own design spec

The gap bkit is built around: plausible code that no longer matches the spec

The README frames the problem in one line: AI produces plausible code, and the person who asked for it has no way to tell whether the result matches what was requested. bkit's answer is a measurement step. The gap-detector computes a match rate between the design spec and the generated code, and when that rate falls below 90 percent the plugin runs an auto-repair loop of up to five cycles. That is the core claim, and it shapes everything else in the kit.

The intended audience is broad and the README says so explicitly. First-time vibe coders get the safety net. Solo developers get what the README calls a team-in-a-box, with `/pdca team` spawning four to six specialist agents in parallel under an AI tech lead. Team leads get sprint planning. Non-English speakers get auto-detection across eight languages, with examples in Korean and Japanese. The unifying idea is that the workflow replaces a senior engineer's intuition about when code has drifted.

That framing is worth taking seriously, because it also defines the cost. bkit does not make the AI smarter. It adds a measurement layer and a process layer on top of whatever Claude Code already produces. If your spec is vague, the match rate is measuring agreement with a vague document.

How the PDCA loop, gap-detector and quality gates fit together

The unit of work is the sprint. `/sprint master-plan my-release --features auth, billing, reports` hands the feature list to a sprint-master-planner agent, which the README describes as investigating carefully rather than quickly, reading the existing code base or researching the web. The planner then splits features into sprints sized so a single Claude Code session can finish one without overflowing the context window. The default budget is 75K tokens per sprint, and the README names the allocation method: Kahn topological sort for dependencies plus greedy bin-packing for sizing.

Each sprint runs an 8-phase lifecycle: prd, plan, design, do, iterate, qa, report, archived. Inside the do phase, the full PDCA loop runs once per feature. PRD and plan are handled by pm-lead orchestrating four PM agents with 43 frameworks. Design is handled by cto-lead, which the README says proposes three architecture options. Iteration targets 100 percent match and is gated. QA is gated separately.

Eleven quality gates sit across the workflow. The README lists the dimensions it checks: match rate, critical issues, convention, test coverage, security, dataFlow integrity, and others it does not enumerate in the excerpt. When a gate fails, pdca-iterator attempts self-repair, up to five cycles. The README's own diagram shows the loop returning to the gate check after each repair pass.

The architecture is a plugin, not a fork. bkit installs into Claude Code and layers skills, agents and commands on top of it. Memory and a Task Management system persist sprint state, which is what lets a new session resume after the previous one was cleared. The README attributes the resumability to that stored state rather than to any model-side change.

Installing bkit and the version wall you hit first

The install path is the standard Claude Code plugin flow, and the README gives the prerequisite in bold: Claude Code v2.1.143 or later. The reason is specific. The strict plugin-manifest path only recognises the official displayName field from v2.1.143 onward, so on older builds `claude plugin install` fails with `Validation errors: Unrecognized key: "displayName"`. The README offers the fix directly: `npm install -g @anthropic-ai/claude-code@latest`, and points to `docs/06-guide/cc-compatibility.guide.md` for the compatibility details.

Once installed, the entry points are slash commands. `/sprint master-plan <name> --features <list>` produces the plan. `/sprint start sprint-1` executes one sprint. `/pdca pm`, `/pdca team` and `/pdca qa` call specialist agent groups directly when you want more depth than the default flow. `/control level 0..4` sets how much of the workflow runs unattended, and the README's diagram shows that setting applying to both the planning step and the execution step.

The control level is the one configuration surface the README describes in behavioural terms rather than naming individual keys. It is a single dial from 0 to 4. The excerpt does not list what each level permits, so treat the mapping as something to read in the repository before you rely on unattended runs. There is no separate config file documented in the material provided.

Where the design strains: context budgets, repair loops and gate opacity

The 75K-token sprint budget is the most interesting decision in the kit and also the most fragile. Greedy bin-packing against a token estimate is a heuristic. If the planner underestimates a feature, the sprint overflows mid-execution and the failure arrives late, after the PRD, plan and design phases have already consumed context. The README does not describe what happens when a sprint exceeds its budget, only that sprints are sized so a session can finish one.

The auto-repair loop has a similar shape. Five cycles is a fixed ceiling, and the README does not say what happens when the fifth cycle still leaves the match rate below 90 percent. Either the workflow halts or it proceeds with a known gap. That distinction matters a great deal for anyone treating the gates as a release condition, and the supplied material does not resolve it.

Gate thresholds are the third soft spot. The README names the gate dimensions but does not give the numeric threshold for most of them, and it does not state whether they are configurable per project. A security gate that fires on a fixed rule set will produce different results on a library and on a web service. If the thresholds are hard-coded, teams will end up either ignoring gate output or restructuring work to avoid it.

There is also a scope mismatch worth naming. bkit's value comes from the spec it measures against. For a one-file bug fix or a throwaway script, generating a PRD, a plan, a design and a completion report is more work than the change. The Docs = Code philosophy is a genuine audit trail for a release-sized project and pure overhead for a patch.

bkit against plain Claude Code with a written spec

The honest alternative is not another plugin. It is Claude Code used directly, with a design document checked into the repository and a human reading the diff. That approach has no install step, no version floor, and no token budget to manage. It also has no automated match-rate measurement: the reviewer is the measurement, and the reviewer is the thing that gets skipped when a deadline moves.

The difference in approach is where the check happens. bkit moves the check into the generation loop, running gap-detector before a human sees the code and attempting repair automatically. The manual approach moves the check to review, which the README itself calls out as the expensive place to find drift. Neither is strictly better. bkit's loop costs context on every feature and depends on a spec detailed enough to measure against. The manual approach costs reviewer attention and fails silently when attention is short.

A second alternative is a CI pipeline with its own linting, coverage and security tooling. That is more mature than a plugin-level gate for the checks it covers, and it runs on every commit rather than inside a Claude Code session. What it cannot do is compare generated code to the design document that produced it, because it has no notion of that document. bkit's match rate is the part that is hard to replicate with existing CI tools. The convention, coverage and security gates are the parts that are not.

Maintenance cost, licensing and what the release cadence tells you

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. It also includes an explicit patent grant, which matters if you are embedding the plugin in a product. That is a description of the licence terms, not legal advice; read the LICENSE file and the NOTICE file if one exists before shipping anything derived from it.

The release history is dense. v2.1.36, v2.1.37 and v2.1.38 landed inside roughly five weeks, with titles like Guardrail Precision, Permission-Mode Awareness and QA measurement. The last push to main is dated 2026-09-06. For an adopter, a fast cadence on a plugin that hooks into another tool's internals cuts both ways: fixes arrive quickly, and the surface you depend on moves. The v2.1.143 version floor is a concrete example of the plugin tracking Claude Code changes closely enough to require a recent host.

Upgrade cost is mostly the version check. Because the manifest validation is strict, a Claude Code downgrade or a pinned older version breaks installation outright rather than degrading. Teams that pin Claude Code versions for reproducibility should confirm the pin is at or above v2.1.143 before standardising on bkit. The README's compatibility guide at `docs/06-guide/cc-compatibility.guide.md` is the file to read for the current matrix.

Who should install bkit, and what to check in the first hour

The fit is a developer or small team already using Claude Code on releases that span several features, where the cost of drift shows up late and the cost of writing a spec up front is acceptable. The sprint planner and the memory layer are the parts that answer a real problem: long projects outliving a session window. The gap-detector answers a different real problem: no automated check that code still matches the document it came from.

The misfit is anyone working below release scale. A solo developer fixing one endpoint, a team prototyping to throw the result away, or anyone on a Claude Code version below v2.1.143. In those cases the install fails or the process costs more than the task.

Three things to verify before committing. First, run `claude plugin install` and confirm it completes without the displayName validation error, which tells you the host version is new enough. Second, read the gate definitions in the repository and find out whether the match-rate threshold, the 90 percent figure and the five-cycle repair ceiling are adjustable, because a fixed 90 percent will be wrong for some codebases. Third, check what happens when the repair loop exhausts its five cycles, since the README does not state whether the sprint halts or proceeds with a recorded gap. That last point decides whether the gates are a release condition or a report.

Editorial conclusion

Adopt bkit if you already drive Claude Code on multi-feature releases and want a documented trail plus an automated match-rate check between spec and code. Skip it if you are working on a single script or a one-file fix: the sprint planner, the 8-phase lifecycle and the quality gates cost more context than the change itself. Before installing, confirm your Claude Code version is v2.1.143 or later, because older builds reject the plugin manifest with 'Unrecognized key: "displayName"', and read the gate definitions to see which thresholds you can actually adjust.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ww-w-ai/bkit-claude-code on GitHub