AI coding agents are fast, but on their own they skip what makes software safe to ship: a design someone challenged, a plan someone checked, a second pair of eyes on every change, tests that actually ran. Vibe coding gets you a demo. Production takes a process.

bkit is that process, ready-made. Describe a feature in a GitHub, Linear or Jira issue and type one command:

/bkit-design ISSUE-123

AI agents design it, plan it, build it, have it reviewed by agents that didn't write it, fix what breaks and ship it, keeping project docs and memory current along the way. You read the design and the plan and make the call.

• For solo founders and makers who've outgrown vibe coding: a senior engineering team's habits, without hiring one. You need to read a plan and make a call, not write the code.
• For engineers who want a proven agentic process instead of building their own: rules, prompts, workflows, guardrails, audits and a CI pipeline that already work together.

It ships what other frameworks leave to you: a full CI pipeline for your project (none of the frameworks in our comparison has one), and 35 audits that find the bugs passing tests miss.

Researched and battle-tested, not a weekend prompt pack. bkit is built with bkit: months of research into how agentic engineering works best, refined over 1,700+ commits, 300+ issues and 100+ merged pull requests run through its own pipeline. Along the way it recorded 300+ lessons and 600+ decisions. They shaped the rules and prompts you install, and your own repo starts its own record from the first feature.

What's inside: 200+ files of best practice

Everything a senior team would otherwise write down over years, in files you can read:

| What | How many | What it does for you | | --- | --- | --- | | Agents | 40+ | Single-job specialists, each with its own model, thinking depth and tool list. A reviewer can read code but can't change it. | | Workflows | 6 | The five phases plus a cloud router. Every step ends in a checklist and a mechanical check before the next one starts. | | Agent rules | 70+ | One rulebook every agent follows: read before editing, never defer silently, report honestly, never rewrite history. | | Guardrails | 10+ hook files | Block dangerous commands and secret reads, and make agents investigate before they edit, on all five AI tools. | | Audits | 35 | Security, privacy, accessibility, performance, reliability, database, LLM usage, cost and more. Findings feed straight into a plan. | | Project docs | 10 + index | Architecture, data schema, deployments, testing, security, monitoring, design system, tech stack, setup, and an index telling each agent what to read at each step. | | Templates | 60+ | A full CI pipeline, cloud agents, git hooks, linters, dependency updates, secrets sync, code search, and 10+ ready-made connectors for your platforms. |

These are the files your agents read, so they're written for agents: short, dense, tables over prose. For day-to-day use, start with .bkit/README.md; for every agent in the order it runs, see the pipeline reference.

How it works

One command per job. Each runs a team of specialised agents, so there are no prompts to write and no steps to remember.

| Job | Command | What happens | | --- | --- | --- | | Work out how to build it | /bkit-design | Reads related issues and past decisions. Three agents propose different approaches, two critique them, and throwaway code tests any risky unknown the reviewers flag. You approve one design. | | Plan the work | /bkit-plan | A step-by-step plan, stress-tested by five reviewers who also see past bugs and postponed work. Too big for one build? It's split into pieces. You approve it. | | Build it | /bkit-build | Checks the plan still matches the code, writes each task's tests before its code, verifies every task, hunts for bugs and security holes, adds edge-case tests and opens a pull request. | | Fix what broke | /bkit-debug | Pulls evidence from CI and your platforms, fixes the root cause, re-tests and records the lesson. Hard runtime bugs get their own mode; if it can't fix something, it stops and writes you a clear handover. | | Ship it | /bkit-ship | Checks nothing planned was quietly dropped, waits for every test lane to pass, merges into dev and updates the docs. | | Small, clearly safe change | *:lite | One prompt to paste per phase (design:lite to ship:lite). The agent keeps only the steps and reviewers the change needs and works on the current branch: no separate repo copy, pull request, CI or sign-off stops. Never for schema changes, public APIs, dependencies, secrets, auth or large refactors. | | Health check | 35 audits | One specialist checklist per area. Findings feed straight into /bkit-plan. | | Housekeeping | 7 utility agents | Keep docs, decisions, lessons and known bugs current, and rank what to work on next. |

Every agent in each phase, in the order it runs and what it checks: pipeline reference. Every step, verdict and contract: .bkit/workflows.md.

Which model does each job

Claude sets the bar, and every other tool gets the model that comes closest to it. On every other tool, each agent runs on the model that does the same job about as well as Claude, for the least money. You don't pick: install sets each agent's model.

How the picks are made. Each kind of job has a bar: Claude's score on LiveBench Agentic Coding, a public test where models fix real code in JavaScript, TypeScript and Python. For each tool, bkit takes the cheapest model that reaches the bar. Where nothing reaches it, the tool's best model gets the job. One model can fill two columns: on opencode, DeepSeek V4.1 Flash clears the bar for the hardest jobs, so it does the everyday jobs too, for a fraction of Claude's cost. Claude is never used on opencode, because opencode is where work goes when your Claude allowance runs out.

| Tool | Hardest jobs: design, plans, reviews, security, audits | Everyday jobs: writing code and docs, the second model in each review pair | Summaries | | --- | --- | --- | --- | | Claude Code | claude-opus-5-5 · bar 65.2 | claude-sonnet-5-5 · bar 59.4 | claude-haiku-5-5 · bar ~51 | | Cursor | cursor-grok-4.5-high · 56.5 | composer-2.5 · not measured | composer-2.5 · not measured | | opencode + OpenRouter | deepseek/deepseek-v4.1-flash · 77.3; moonshotai/kimi-k3 · 62.2 for risk, security and root-cause agents | deepseek/deepseek-v4.1-flash · 77.3 | z-ai/glm-5.3-flash · 56.8 | | opencode + Ollama | deepseek-v4.1-flash · 77.3; kimi-k3 · 62.2 for risk, security and root-cause agents | deepseek-v4.1-flash · 77.3 | deepseek-v4.1-flash · 77.3 | | opencode + OpenCode Zen | deepseek-v4.1-flash · 77.3; kimi-k3 · 62.2 for risk, security and root-cause agents | deepseek-v4.1-flash · 77.3 | glm-5.3-flash · 56.8 | | opencode + OpenCode Go | deepseek-v4.1-flash · 77.3; kimi-k3 · 62.2 for risk, security and root-cause agents | deepseek-v4.1-flash · 77.3 | deepseek-v4.1-flash · 77.3 | | Codex | gpt-6-astra · not measured | gpt-5.6-terra · not measured | gpt-6-luna · 51.2 | | Google Antigravity | gemini-3.8-pro · not measured | gemini-3.8-pro · not measured | gemini-3.8-flash · not measured |

Reading the table:

• The bars are Claude Opus 5 and Sonnet 5 scores. bkit runs the 5.5 versions. Opus 5.5 scores level with Opus 5. Sonnet 5.5 scores below Sonnet 5 on LiveBench, but one of its runs stopped early and other benchmarks put it above, so the bar stays at Sonnet 5. Every score and why: the score board.
• Risk, security and root-cause agents get a second model that reasons differently from the main one, so they don't share its blind spots. On every opencode provider that second model is Kimi K3, which scores a little under the bar for the hardest jobs.
• Cursor's own models don't reach the bar. Claude models in Cursor spend paid API credits, so they're opt-in: paste the ready-made Opus block from Model Overrides.
• "Not measured" means LiveBench hasn't scored that model. Those Codex, Antigravity and Cursor picks follow each vendor's own description of the model. Check them before you rely on them.
• Ollama needs a paid plan for every column. The free models are far below the bar or not scored.
• Want a different model for one agent? On Cursor and opencode, add a row to Model Overrides and run bkit install again. Every agent with its model and thinking depth: .bkit/prompts.md § Models.

On Claude Code, each agent also sets its own effort, so the effort you leave your session on never changes theirs. Start each /bkit-* command on the model the picture above shows and leave effort at the default. Session setup in full: .bkit/prompts.md § Orchestrators.

Why it's different

Most AI development frameworks are prompts: they describe good work and trust the agent to deliver it. But an agent can be talked into calling something done, and a prompt can't stop it. bkit builds fences instead. Reviewer agents that didn't write the work fence in the design and the plan. They never see each other's verdicts, and several review groups mix models on purpose, so one model's blind spot is less likely to get past all of them. From the first line of code, automated checks join them, and those can't be argued with.

Agents and CI, built to work together

The strongest fence is CI (continuous integration): the robot that runs every check on every change, on GitHub's servers, before anything merges. Where other frameworks stop at a pull request and leave CI to you, bkit's workflows are built around it and around the checks that run before it. Every change passes the same fences, nearest and lightest first:

• Every agent looks code up before changing it, is nudged by the agent hooks on each edit, can't finish a step until the step gates (scripts, not prompts) find its verdict and files, and has its code formatted on each commit.
• /bkit-plan decides which tests each feature needs and where each one runs: unit, integration or end-to-end.
• /bkit-build writes each test before its code and runs it to prove it fails, so a test that can't fail is never added. The pre-push hook sends back anything that fails on your machine; then build opens a pull request, which starts CI.
• /bkit-debug works from what came back: the logs of the failed lanes, the diff since the last green run, end-to-end reports. It fixes the root cause and pushes, and CI runs again.
• /bkit-ship checks nothing planned was quietly dropped, then merges into dev only when CI's final check is green on the exact commit being merged.
• On autopilot, for issues labelled bkit:auto, CI's result starts ship (green) or debug (red) in a cloud session, with no laptop open (cloud setup).

What that gets you:

• The fences grow with every feature. Each build adds tests every later change has to pass. A prompt-only framework is as strict on your fiftieth feature as on your first; bkit gets stricter.
• What's sent back is evidence, not a verdict. A red lane hands debug the failing logs and what changed since the last green run, so the fix starts from the actual error, not a guess.
• Agents look before they change anything. Code search (Serena) shows every definition and caller of the code about to change, not just lines with matching words, and graphify's code map shows what already exists. Fewer bad changes reach the fences at all.
• Problems are caught at the nearest fence. Agent hooks nudge on every edit: read a file before changing it, fix the code rather than loosen a check. The pre-commit hook formats in seconds. The pre-push hook runs type checks, unit tests, integration tests (once you declare that gate), the prose checker and the junk-code scanner before anything leaves your laptop. CI keeps only what can't run there: end-to-end and live-site tests. Hooks, agents and CI's quick-checks lane all run the same bkit:gate:* scripts, so most failures show up on your machine first.

The agent hooks come with install. Serena, graphify and the git hooks are templates you adopt. Compared with other frameworks: agents and CI.

The CI pipeline

None of the AI development frameworks in our comparison ships a full test pipeline for your project. bkit ships one ready to adopt:

• Ready on day one. Two lanes run side by side: unit tests, and quick checks (type checking, formatting, a prose checker, a scanner for junk code AI tends to write, a workflow-file checker and bkit check).
• A green tick means every test ran. One final check joins all lanes and is the only one branch protection needs. It fails if any lane failed, was skipped or cancelled, or ran zero tests, so a half-finished run can't pass as tested. The gates audit flags any check that can never fail.
• Grows with your project. 20+ ready-to-enable building blocks: integration tests; end-to-end tests for web, iOS and Android; database migrations (locked once merged, with security-policy checks); coverage reports; waiting for preview deploys; live, smoke and health checks against the deployed site; and a planner that runs only what a change affects. bkit check reminds you of each one until you enable or delete it.
• Safe by default. Every third-party action is pinned to an exact commit, the downloaded prose checker is checksum-verified, and pull-request titles never reach a script unescaped.
• Doesn't waste minutes. A commit that already passed isn't re-tested, and a newer push cancels the older run, except on your production branch, where a deploy must never be cut off halfway.

How the lanes join into the one final check, and what happens on green or red: CI test scaffold.

Right context at the right step

A chat forgets everything when it ends; bkit doesn't. It keeps what it knows in plain files in your repo and on your tracker issues. Each step reads what it needs and writes back what it learned:

• Docs that keep themselves current. Install sets up the docs a professional project keeps: architecture, data schema, deployments, testing, security, monitoring, design system, tech stack and local setup. Agents fill them in as they work, /bkit-ship updates them after every feature, and an index tells each agent which docs to read at each step. They stay current because the agents depend on them.
• Project memory agents actually read. Four ledgers record lessons from every fix (docs/knowledge.jsonl), decisions and their reasons (docs/decisions.jsonl), work consciously postponed (docs/deferrals.jsonl) and known bugs (docs/failures.jsonl). Plan reviewers see the past bugs and postponed work closest to the new feature, debug reads the lessons first, and /bkit-ship checks nothing postponed was quietly dropped. Four utility agents keep them honest: they correct lessons and decisions the code has since contradicted, and close postponed work and known bugs that have already been fixed.
• Tracker issues are memory too. Every step reads the whole tracker issue (e.g. GitHub, Linear, Jira), comments included, and adds what it did as a new comment without editing earlier ones, so the issue becomes the feature's running record. bkit skips its own comments when it reads, so agents act on what people wrote. Design, plan and debug also search your other tracker issues, closed ones included, for earlier designs, duplicate work and past incidents.
• Outside evidence, when it's needed. Design searches the web for feasibility. Debug pulls failed CI logs, the diff since the last green run, end-to-end reports and runtime errors. 10+ ready-made connectors cover GitHub, Sentry, Vercel, Supabase, Stripe, Expo, Playwright, Maestro, Inngest, Resend, Cloud Run, Tavily web search and Serena, each easy to customise, extend or leave out. A connector that isn't set up is reported as such, never read as "all clear".
• Progress lives in your repo, not a chat window. Run state is saved after every step, so a crashed run resumes where it stopped, on any tool.

Audits find what green tests miss

A green tick proves the tests passed, not that they test the right things. Every finding on this map sat in an app whose tests were passing, and just two of bkit's audit templates found them all.

Each template is a specialist's checklist for one area: what to check, how, and what counts as a problem. Ten to start with:

| Audit | What it checks | For example | | --- | --- | --- | | Testing | Whether tests can fail, actually run, and cover what the product must and must never do | Tests that read the code as text instead of running it | | Duplication | Rules and logic built more than once | A billing rule in eight copies that have drifted apart | | Security | Sign-in, permissions, secrets, input checks, and protections the docs promise | A sign-in link that can send people to another website | | Red team | Real attacks on a test copy of your app, never production, one request at a time | One signed-in user reading another user's data | | Reliability | What happens when a service is slow, down or answers twice | A payment retried with no guard against charging twice | | Privacy | Where personal data goes, how long it stays, and whether deletion works | A deleted account still sitting in the logs | | Dead code | Code, settings and routes that look live but never run | A fix made in a file nothing calls | | LLM | Every AI model call, and what stops it when the input is hostile | A pasted document that talks the model into calling a tool | | Accessibility | What automated accessibility checks miss, against WCAG 2.2 AA | A form a screen reader can't get through | | Cost | Vendor plans against what you actually use | A plan two tiers above your usage |

All 35, grouped by area, with what each one finds: the full audit list.

• Run one whenever you want. Name a template to @bkit-audit-generate and it writes a report to docs/audits/{YYYYMM}/. It reads your code and, where you've connected them, your live platforms, and lists anything it couldn't check rather than calling it clean.
• Findings turn into work. Hand the report to /bkit-plan and the fixes are planned, built, tested and shipped like any other feature.

Templates ready to adopt

bkit installs only what its workflows run. Everything you or another tool runs ships as a template: install puts the latest set in your .bkit/templates/, and every upgrade lists which ones changed. Copy in what you want and own it; bkit never writes over your copy. The install prompt asks your AI to adopt what fits, and each workflow ends with a tip on the next one worth adding. Audit templates fall under the first rule: bkit's own audit agent runs them, so install puts them straight into docs/templates/ and there's nothing to copy.

The ones that matter most, in the order to adopt them:

| Template | What it's for | | --- | --- | | Serena | Agents look up code the way your editor does ("where is this defined, and what uses it?") instead of searching for words and reading whole files. Fewer accidental changes, and lower running costs because agents read less. Read-only. | | CI pipeline | Runs every check on GitHub on every change, and /bkit-ship waits for it before merging. Without it, "shipped" only means merged, not checked. Two lanes ready to go and 20+ building blocks for the rest (above). | | Quality checks | Catches problems on your own machine in seconds, before they reach GitHub: type checking, formatting, a prose checker, a scanner for junk code AI tends to write and a test linter that fails tests which cannot fail, wired into git hooks and CI. Your bkit:gate:* scripts in package.json define what "the checks" are. | | Cloud agents | When CI finishes, a cloud agent picks up: ship on green, debug on red. No laptop needed. | | Context connectors | /bkit-debug reads the real errors instead of guessing from the code: 10+ ready-made connectors for CI, error trackers, hosting, databases, payments, email, queues and the web. | | Secrets sync | Keeps every password and key the same everywhere: one local file, one command to push it to Vercel, GitHub Actions, Google Cloud, Supabase, Expo and Cursor's cloud agents, another to prove every copy matches without printing a value. Prevents "works for me, broken in production". | | graphify | Keeps a map of how your code fits together (docs/capabilities.md), so agents check what already exists before building it again. | | Dependency updates | Small, grouped update pull requests from Renovate or Dependabot instead of one big risky upgrade later. GitHub Actions stay pinned, and security fixes skip the queue. | | Security scan | Trivy fails the check when a change adds a known-vulnerable library in any language, a risky container or cluster setting, or a committed password. A daily run catches problems that have no fix yet, which an updater never shows. | | Audits | 35 specialist checklists, one per area: testing, security, privacy, reliability, cost and more. Already installed in docs/templates/, so there's nothing to copy: name one to @bkit-audit-generate and hand its report to /bkit-plan (above). |

All templates, what each is for, and how to install them: .bkit/templates.md.

What else you get

Engineering know-how, built in

• Best model for each job, on every tool. Each agent has its own model and thinking depth, per tool and provider: deep reasoning models for architecture and security review, quick ones for summaries. Starting a session on a cheaper model never quietly downgrades the reviewers. Which model does each job.
• It tests ideas before you commit to them. When reviewers flag an unknown a design depends on, design writes throwaway probe code to settle it before you approve. A design reviewer also checks failure modes and monitoring, not just whether it can be built.
• Big features are split up. A plan too big for one build becomes a sequence of smaller plans, each re-checked against the current code right before it's built.
• Numbers on your own work. Every run records its time, size of change and retries in .bkit/stats.jsonl, and posts them to the issue next to the median of your last five runs.

It fits how you work

• Never blocked by usage limits. Out of Claude for the week? Carry on in Cursor, Codex or Antigravity, or point opencode at your own key: OpenRouter, Ollama or the opencode gateways. Same feature, same checks, nothing to set up again. Tool differences.
• Start on your laptop, check in from your phone. A feature started at your desk can continue in a cloud session (Claude Code on the web or the Claude app, Cursor cloud agents, or opencode on GitHub Actions), or start by itself when CI finishes: ship on green, debug on red. The cloud setup ships ready to adopt: .bkit/cloud.md.
• Run several features at once. Each works in its own copy of the repo (a git worktree), so they never trip over each other.
• The right expertise for each feature. When a plan needs, say, Stripe or Supabase, bkit installs a matching skill for the build and removes it when the feature ships.

Your tracker is the control panel

• Every run lives on the tracker issue. bkit reads the tracker issue (e.g. GitHub, Linear, Jira), posts progress as it goes, moves the issue along and links the pull request.
• Issues that start the right step. Optional issue forms for a new idea, a well-defined change or a bug ask for what the agents read first, and each names the command to run next. A well-defined change can be the plan itself: what done looks like, the tests and the tasks.
• It tells you what to work on next. @bkit-utility-update-roadmap reads your board and the open known bugs and postponed work from the ledgers, then writes a ranked shortlist into docs/roadmap.md.
• It keeps the tracker tidy. @bkit-utility-update-tracker brings open issues in line with the tracker rules: short titles, the right labels, board status, priority, size, milestone, parent and blocked-by links. It takes priorities from the latest issue prioritisation audit and suggests new milestones and parent issues, but never creates or closes an issue.
• See it live: bkit's own board, and the shortlist bkit ranked from it in docs/roadmap.md.

You stay in control

• Decide in plain English, not code. Before any code is written you approve two short documents: a design ("three ways to build this; we recommend this one, because…") and a plan ("these twelve steps, and how we'll know each is done").
• Three sign-offs, and production stays yours. The full workflows stop after the design, after the plan and before merging. bkit merges into your dev branch and never touches main: promoting to production is always your call. Cloud mode ships on green without you only for issues you've labelled bkit:auto; removing the label stops it. Lite workflows skip the stops, and only run when you choose them for a small change.
• Guardrails on the AI itself. Dangerous commands like force-pushing or rewriting history are blocked, private keys can't be read, and each agent only gets the tools its job needs. What each guard does and what it tells agents.

Spending fewer tokens

Most of what a session costs is the model re-reading, not writing code. On every request, Claude Code sends the system prompt, rules, tool list and the whole conversation so far, and the model reads all of it again. Across 456 real Claude Code transcripts from a repo that uses bkit, re-reading was 69% of the bill. The model's own writing was 4%.

Why bkit doesn't use compression tools. They shorten the output of commands and file reads before the model sees it. That output was 27% of the bill, and most of it is code the agent needs word for word, so there's little a tool can safely cut. We measured three: none saved more than 3% of the bill, and the ones that saved most did it by changing what the agent reads. One made an agent answer a question wrongly; another rewrote code.

| Tool | How it works | Share of the bill saved | What went wrong | | --- | --- | --- | --- | | caveman | Sits between Claude Code and the model and shortens tool output | 1.3% | An agent answered a question wrongly from a compressed log | | Headroom | Same idea, plus an optional text model that rewrites output | 2.8% with the text model, 0.8% without | The text model rewrote code: (preset) => void came back as (preset) void | | RTK | A hook that swaps shell commands for versions that print less | 0.7–2.1% | Its grep strips indentation and cuts lines at 80 characters |

How we measured. The cost split above comes from all 456 transcripts. The table compares the three tools on the 314 of them still on disk when RTK was tested, so all three are measured on the same data. We ran each tool over the large tool results, with no model calls. Each result counts by how often the model re-read it later, because that's what it cost. RTK acts before a command runs, so we re-ran the read-only commands with and without it. Full method, every result with its 95% range, and the scripts: the comparison. Your sessions may differ: run the scripts on your own transcripts before you choose.

Why the risks outweigh the saving, for now. The saving is real but small, and the tools that save most get there by changing what the agent reads. An agent reading a shortened log can answer wrongly. An edit quoting a rewritten or cut-off line won't match the file. Either way the agent goes round again, and every extra round re-reads the whole conversation, so it doesn't take many to wipe out a 1–3% saving. On top of that, a proxy sees all your model traffic, and when one of these tools breaks, it tends to switch itself off without telling you. That could change if a tool learns to leave code alone and fail loudly.

What bkit does instead: read less. Cutting what gets read loses nothing, and a line an agent never reads is a line it never re-reads on every later request.

• Find the definition first, then read only those lines. Reading files through the shell (sed, grep, cat) was about 60% of what shell output cost in our transcripts. A whole file can be thousands of lines when the change needs ten.
• List matching files first, then search inside them. A broad search can return hundreds of lines the agent never needed, and they stay in the conversation.
• Ask commands, APIs and databases for short, structured output. An unfiltered log or API response can run to thousands of lines, re-read on every later request.
• Flag re-reads of a file that hasn't changed, with a hook on all five supported tools. 41% of file reads in our transcripts were repeats, each adding a second copy to the conversation.
• Prefer command-line tools to MCP servers for logs, errors and database data. Every connected MCP server's tool list is re-sent with every request, used or not.
• Each step reads only the project docs it needs. Whatever a step reads at the start is re-read on every request in that step.
• A utility agent shortens markdown files without changing what they say. Rules and prompts go out with every request of every agent, so a line cut there is saved many thousands of times.

Or run fewer steps. For a change that's clearly small, the lite workflows keep only the steps and reviewers it needs, so fewer requests re-read the conversation. You give up the safety checks, so the full workflow stays the default.

What bkit tips suggests for your repo:

• Set up Serena, so agents ask where code is defined and what uses it, like your editor does. That's cheaper than reading whole files, and it doesn't miss callers that text search would.
• Switch off claude.ai connectors (MCP servers from your claude.ai account) in Claude Code for this project: "disableClaudeAiConnectors": true in .claude/settings.json. Otherwise their tool lists are re-sent with every request, used or not.
• Lock MCP servers to this project. A server that can see your whole account makes agents look up account and project IDs before every task; locked, those extra calls disappear.
• Summarise long sessions earlier: "autoCompactWindow": 300000 in .claude/settings.json, or model_auto_compact_token_limit in .codex/config.toml. By default a session grows close to the model's full size before it summarises, and every request re-reads all of it. Summaries lose some detail, so bkit suggests this rather than setting it.

FAQ

Do I need to know how to code? No, but you need to read a design and a plan and decide whether they're right. Setup is a few terminal commands, or one pasted prompt.

Who is it not for? bkit is heavier than a single prompt. For a one-off script or a quick experiment, just ask your AI. bkit pays off on a project you'll keep changing and want to trust.

Does it work on an existing project? Yes. Install needs a git repo with a package.json, because bkit installs as an npm package. It adds its own files and writes into shared ones such as CLAUDE.md, .gitignore and docs/*.md only between bkit:start and bkit:end markers, leaving the rest alone. The project docs fill in as agents work on your code.

What does install change, and can I remove it? Every file it writes is listed in what install writes. bkit uninstall removes bkit's files and blocks, and keeps your own edits and every template you copied (uninstall).

What does it cost? bkit is free and open source under the MIT licence, commercial use included (License). It runs on AI subscriptions you already have (Claude, Cursor, ChatGPT for Codex, Google Antigravity), on Antigravity's free tier, or with your own key on pay-as-you-go providers through opencode (OpenRouter, Ollama or the opencode gateways). Several agents reviewing in parallel use more of your quota than a single chat; that's the price of the second opinions.

How long does a feature take? No full run, from design to merge, has taken longer than a day. Each run posts its own time to the issue, next to the median of your last five runs, so you can see how yours compare.

Can it break my live site? Not without your sign-off. In the full workflows, work happens in a separate copy of the repo, goes through a pull request, must pass every test, and merges into dev, never main. Lite workflows skip the pull request and CI, which is why they're only for small, clearly safe changes.

Which issue tracker, and which code host? GitHub Issues, Linear or Jira for the tracker. The code has to live on GitHub: pull requests, CI and cloud mode run there.

Is this the bkit Vibecoding Kit? No. bkit Vibecoding Kit is a separate project that shares the name. This bkit is @cbartens/bkit on npm, at github.com/cbartens/bkit.

How does it compare with other tools? Feature by feature against the main AI development frameworks, from spec toolkits to autonomous agents: .bkit/comparison.md.

Why doesn't bkit use a compression tool like caveman, Headroom or RTK? On real bkit sessions they saved 1–3% of the bill, and each changes what the agent reads in ways that can lead to wrong answers or broken edits. bkit cuts reading instead, which loses nothing. Numbers, risks and what bkit does instead: Spending fewer tokens.

• Isolation. Every run gets its own git worktree; a per-feature lock blocks duplicate runs of the same feature. Bookkeeping reaches dev from a throwaway checkout of origin/dev, so it never touches your checkout; when another run moved dev first, it rebuilds and pushes again. No repo-wide lock.
• Resume from state, not session. Run state lives in status.jsonl and docs/plans/. A crashed or interrupted run resumes from its last completed step, on any host.
• Mechanical step gates. bkit steps finish checks each step's verdict and artifacts before the workflow moves on; build ticks a task only on a confirmed artifact; ship's deferred sweep fails the merge on an unplanned gap.
• Engine. The bkit CLI is TypeScript in .bkit/core/engine/, built to dist/, covered by 5,800+ tests. commands/ holds what you type; install/, render/, checks/, ledgers/ and shared/ hold the code underneath; audits/ holds the tests that read shipped text.
• One source, every host. .bkit/ renders .claude/, .cursor/, .codex/, .agents/ (Antigravity) and .opencode/. bkit check is the CI drift gate.
• Reviewer independence. Parallel reviewers can't read sibling output. Design brainstorm, design review and plan scope-check groups also cross models (Opus + Sonnet on Claude; Grok + Composer on Cursor); depth-sensitive lenses (plan review, build challenge) stay on the top tier.
• Per-agent pins. Model and effort per agent, per provider (.bkit/prompts.md § Models), immune to the session default.
• Against the literature. bkit fully implements 13 of the 22 patterns in Antonio Gulli's Agentic Design Patterns, partly implements 7 (scoped to shipping code), leaves 2 out by design, and goes beyond the book in 8 places. Full mapping: patterns comparison, with where bkit goes beyond the book and its known gaps. Every agent in execution order: pipeline reference.

Documentation

| Read | For | | --- | --- | | .bkit/install.md | Install, upgrade, CI auth, uninstall, recovery | | .bkit/README.md | Day-to-day use: running workflows, environment, tracker setup, CLI | | .bkit/workflows.md | Every workflow step, verdict and contract | | .bkit/providers.md | Tool and provider differences, guardrails, model pins | | .bkit/cloud.md | Cloud agents: Claude Code on the web, Cursor, opencode | | .bkit/templates.md | Templates ready to adopt | | .bkit/lite.md | Lite workflows: shorter prompts for small changes | | .bkit/pipeline.md | Every agent in the order it runs, the CI scaffold, every audit template | | .bkit/comparison.md | Comparison with other AI development frameworks and with Agentic Design Patterns | | CHANGELOG.md | What changed in each release |

Quick start

You need a GitHub repo with a package.json, Node 24+, pnpm, and at least one of Claude Code, Cursor, Codex, Google Antigravity or opencode.

Easiest: copy the install prompt into your AI coding tool and let it do the setup.

By hand: bkit is public on npm and installs like any other package, with no token or registry setup.

pnpm add -D @cbartens/bkit
pnpm bkit install --claude    # pick your tools: --claude --cursor --codex --antigravity --opencode=<provider>
# opencode provider: openrouter | ollama | opencode-zen | opencode-go

Check it worked: pnpm bkit check confirms every installed file matches the version you pinned (CI runs the same check), and pnpm bkit tips lists what isn't set up yet, most useful first.

Adopt the templates you want from .bkit/templates/, open an issue, and run the first step from your AI tool:

/bkit-design ISSUE-123

Already know exactly what to build? Start at /bkit-plan. Something broken? /bkit-debug; add [repro] if nothing fails yet, and it writes the failing test first.

Full install, upgrade and CI setup: .bkit/install.md. Tracker labels and environment variables: .bkit/README.md.

Credits

bkit's process was worked out over months of building real products with it. These projects sharpened specific ideas along the way:

| Project | Idea bkit took | | --- | --- | | everything-claude-code (affaan-m) | GateGuard, the hook that makes an agent investigate before it edits, name included; the warning when an agent edits lint or type-check settings; confidence and scope on recorded lessons; the untrusted-input notice on agents that read outside content. | | gstack (Garry Tan) | Writing the setup once and generating every AI tool's copy from it, with a check that the copies match; the completeness and search-before-building principles in the shared rules; resuming a run from saved state. | | Agentic Design Patterns (Antonio Gulli) | A "done when" line on every plan task, and testing hypotheses before fixing in debug. The book is also the yardstick in the patterns comparison. | | skills (Matt Pocock) | The interview that opens /bkit-design, adapted from grill-me: open questions are settled with you before any design work starts. |

Built on. The templates set up these tools; thanks to their maintainers: Serena, graphify, slop-scan, Vale with write-good, Renovate, Dependabot, Trivy, Husky, lint-staged, Prettier, actionlint and direnv.

License

bkit is MIT: use it, change it and share it for any purpose, commercial included, as long as the copyright and licence notice stay with it.

The code bkit's agents write for you is yours. The licence covers bkit itself, not what its agents produce in your repo.

The full text travels in your repo at .bkit/LICENSE.md after install.