bkit — AI Native Development OS

The only Claude Code plugin that verifies AI-generated code against its own design specs.

Three commands. Anyone — even someone vibe-coding for the first time — can ship robust, production-quality software. bkit turns Claude Code into a Context Engineering system: 44 skills, 34 specialist agents, 11 quality gates, and a memory that survives across sessions deliver the right context to the AI at the right moment, so you don't have to know prompts, commands, or PDCA to get high-quality results.

Requirement: bkit requires Claude Code v2.1.143 or later (the strict plugin-manifest path recognizes the official displayName field only from v2.1.143). On older Claude Code you will see Validation errors: Unrecognized key: "displayName" during claude plugin install. Run npm install -g @anthropic-ai/claude-code@latest to upgrade, or see docs/06-guide/cc-compatibility.guide.md.

Who bkit is for

| You are… | bkit gives you | |---|---| | 🌱 First-time vibe coder — you describe what you want and AI codes for you, but you don't yet know how to tell if the result is correct | A safety net. AI proposes, bkit measures the result against its own design spec, and auto-repairs the gap when it drifts. You can ship without becoming a senior engineer first. | | 👤 Solo developer / indie builder | A team-in-a-box. /pdca team spawns 4–6 specialist agents in parallel — frontend, backend, QA, security — orchestrated by an AI tech lead. | | 👥 Team lead planning a release | Sprint Management. /sprint master-plan splits your release into context-budgeted sprints so a single Claude Code session can finish each one without running out of memory, and resumes after any session interruption. | | 🌐 Non-English speaker | 8-language auto-detection. Type "로그인 기능 만들어줘" or "作成新功能" and bkit picks the right command for you. |

What you'll achieve with bkit

The promise: anyone — including non-developers — can build robust, production-quality software by using bkit. bkit replaces the senior engineer's intuition with a workflow.

| Without bkit | With bkit | |---|---| | AI gives you plausible code; you have no way to know if it really matches what you asked for | gap-detector measures match rate between your design spec and the generated code. Below 90 % → bkit auto-repairs (up to 5 cycles). | | You only spot drift at PR review — by then the cleanup is expensive | 11 Quality Gates halt the workflow before drift compounds (match rate, critical issues, convention, test coverage, security, dataFlow integrity, …) | | Long projects exceed Claude Code's session window and you lose context | bkit splits the project into context-budgeted Sprints (≤ 75 K tokens each); memory + Task Management lets any session resume where the last one stopped | | You don't know which command, agent, or skill to use | 8-language auto-trigger + intent-router pick the right skill / agent automatically. You just describe what you want. | | AI ships code, you ship hope; nobody documents what changed | Docs = Code philosophy: every feature produces a PRD + plan + design + analysis + completion report. The history is the audit trail. |

The 4-step experience

This is the canonical workflow when you use bkit. You describe a release; bkit handles the rest.

flowchart TB
    You(["You: describe the release"])
    You --> S1["Step 1<br/>/sprint master-plan my-release<br/>--features auth, billing, reports"]
    S1 --> Auto1["bkit auto-action<br/>• sprint-master-planner agent investigates code + web in depth<br/>• Splits features into context-budgeted Sprints (&le; 75K tokens each)<br/>• Writes the master plan with Context Anchor"]
    Auto1 --> S2["Step 2<br/>You approve the plan"]
    S2 --> Auto2["bkit auto-action<br/>• Every sprint registered in Task Management<br/>• Memory saved — survives session clear"]
    Auto2 --> S3["Step 3<br/>/sprint start sprint-1"]
    S3 --> Auto3["bkit auto-action — full PDCA per feature:<br/>PRD/Plan → Design → Do → Iterate (target 100%, gated) →<br/>QA (gated) → Report. /pdca pm, /pdca team, /pdca qa as needed."]
    Auto3 --> Gate{"All quality<br/>gates pass?"}
    Gate -- "no, auto-fix" --> Repair["pdca-iterator self-repair<br/>(max 5 cycles)"]
    Repair --> Gate
    Gate -- "yes" --> Done(["Release-ready code + docs"])
    Ctrl["Step 4<br/>/control level 0..4"] -.->|"set how much<br/>runs unattended"| Auto1
    Ctrl -.->|"applies"| Auto3

    style You fill:#e3f2fd
    style S1 fill:#fff3e0
    style S2 fill:#fff8e1
    style S3 fill:#fff3e0
    style Auto3 fill:#fce4ec
    style Repair fill:#ffe0b2
    style Done fill:#c8e6c9
    style Ctrl fill:#f3e5f5

Step 1 — Plan the release in depth

You type: /sprint master-plan my-release --features auth, billing, reports.

bkit's sprint-master-planner agent investigates carefully — not quickly. Depending on what you're building, it reads your existing code base in depth or researches the web, then writes a master plan. Critically, it splits your features into context-budgeted Sprints: each sprint is sized so a single Claude Code session can finish it without overflowing the context window (the default is ≤ 75 K tokens per sprint, dependency-aware via Kahn topological sort + greedy bin-packing).

You can also call specialist agents directly when you want more depth: /pdca pm runs 4 product-management agents in parallel with 43 frameworks; /pdca team spawns a multi-specialist implementation team; /pdca qa runs a 5-agent QA team.

Step 2 — Approve, register, remember

You read the master plan. When you approve, bkit registers every sprint in its Task Management System with the right dependency order (Kahn-topologically sorted). It also writes to memory.

This means: if your laptop crashes, your session clears, or you start a new Claude Code session next week — bkit picks up exactly where you stopped. The plan and progress are durable.

Step 3 — Auto-run each sprint through PDCA

You type: /sprint start sprint-1.

bkit runs the 8-phase Sprint lifecycle (prd → plan → design → do → iterate → qa → report → archived). Inside the do phase, bkit runs the full PDCA loop once per feature:

| Phase | What runs | Output | |---|---|---| | PRD / Plan | pm-lead orchestrates 4 PM agents (discovery, strategy, research, prd) with 43 frameworks | Comprehensive PRD + plan with Context Anchor | | Design | cto-lead proposes 3 architecture options; you pick one (the only required user input) | Detailed design doc | | Do | /pdca team spawns 4–6 specialist agents in parallel (developer, qa, frontend, backend, security, architect) | Working code | | Iterate | Target 100 % match between design and code. gap-detector measures; pdca-iterator self-repairs until quality gate M1 (matchRate ≥ 90 %) passes. Max 5 cycles. | Repaired code + iteration report | | QA | qa-lead runs 4 QA agents through L1–L5 tests + dataFlow integrity (S1 gate, 7-layer hop check) | QA report | | Report | report-generator writes the completion report | Final report with KPI + lessons learned |

Every phase is gated by quality thresholds. If anything fails — match rate too low, critical issue found, dataFlow broken — bkit pauses and tells you why. You don't have to remember to verify; verification is automatic.

Step 4 — Govern with one dial

/control level N is the single autonomy knob. It decides how far the orchestrator runs before stopping. The same dial controls both Sprint and PDCA — no second knob to manage.

| Level | What it means | |---|---| | L0 Manual | Ask me at every phase. Best for your first sprint — inspect each output. | | L2 Semi-Auto (default) | Plan/Design/Do auto; ask me on QA and Report. | | L4 Full-Auto | Wake me when the sprint is done. Pauses only on a quality gate failure or one of 4 auto-pause triggers. |

L1 (Guided) and L3 (Auto) sit between. bkit also computes a Trust Score (0–100) from your track record and can recommend a level — but you stay in charge.

How the bkit author actually uses bkit

The 4-step experience above is the canonical flow. Here's the concrete recipe the person who built bkit uses every day — two steps — so you can copy it without needing to understand the full machinery underneath.

Step A — Use Claude Code as a thinking amplifier before the master plan

The master plan is the single most important artifact in a sprint. Garbage in, garbage out. So don't write it alone, and don't let bkit write it cold either.

1. Open a fresh Claude Code session.
2. Talk through the release in plain language — what's the goal, who is it for, what could go wrong, what depends on what, what's still unknown? Let Claude Code push back.
3. Have it investigate — read your repo, search the web, surface edge cases you hadn't considered.
4. Then run /sprint master-plan my-release --features .... By the time you do, your context is already saturated; the master plan reflects what you really meant, not a generic template.

This is what Context Engineering looks like in practice: you don't tune the perfect prompt — you saturate the context first, then let bkit synthesise.

Step B — Hand the rest to Trust Level 4

Once you approve the master plan, the keyboard goes quiet until the final report lands. The bkit author picks one of two patterns based on release size:

| Release size | What you type | What h