Claude CodeGitHubSDDv0.18.0 · MIT
House rules for thirty agents.
Bitblitzin Bootstrap is a Claude Code plugin for projects where many AI coding agents work at once. It gives the project house rules and the machinery that enforces them, so the rules hold when nobody is watching.
Without it: thirty new hires, no manager.
Agents are fast and eager, and each one starts with no memory of the project. Left alone, they do what any crowd of newcomers does.
With it: rules that hold.
Every rule came from something that went wrong on a real project. The plugin writes the rules down, and then it enforces them with hooks, checks and a queue that do not get tired or forget.
Built for GitHub, GitHub Actions, the gh CLI and Claude Code. When a project uses something else, the skill says so once and adapts. The rules are about kinds of places, not products.
Ten pieces. Each one closes a gap that a real project fell into.
Tasks live in the issue tracker, one per task. Status lives on a board the tracker feeds automatically. Orientation for a newcomer lives on one generated page built from small per-feature stubs. Design lives in a spec written before building; a pull request names its spec in its body rather than editing a shared spec file. Tasks live in issues, not a tasks file. A dependency bump needs no manual entry. Decisions are kept one file each, numbered so two agents never take the same number. Nothing is appended to a shared page just to pass a check, and a move on main in docs, specs or status never costs a green pull request a re-run.
Dangerous commands are refused before they run, each with one sentence saying what to do instead. Some hooks carry more than one refusal. A stop hook refuses to let a task end with uncommitted files, stray images, or a server still running. The full list is below.
Finished, green pull requests are combined in the queue's own worktree, tested together, and merged as one. What conflicts or breaks is dropped, not everything. The steps are below.
When an agent starts, it sees where the project stands in one network call, about two seconds. It opens with today's date in the owner's time zone, the zone every date in the repository is written in. No reading twenty files to find out who has the ball.
Stand a project up, find out where everything stands, and propose the next round. Each one reads the project rather than asking you to describe it. The bootstrap survey opens by asking whether a sibling repository can supply the stack. Branch protection and the database are one script each: the rules the queue needs on main, and the project's Supabase database with the password written only to the env file. Only the board's built-in workflows stay manual, because GitHub has no API for them. One script files an issue through REST with its State label in the same call, and another prints the API budget on demand. The board script prints the board's address when it finishes and the agent hands that link to the owner, since the board is the status report and nobody finds it by hand.
A pull request runs in three runner jobs: one runs every cheap rule check after a single checkout, one installs once and runs the type-check, tests and build, and a summary check reports the result. A newer push cancels a pull request's older run, and every check diffs the pull request from current main. The rule checks: change classification, a spec check, a setup-manual check, a shared-code check, a numbering check so parallel pull requests never take the same migration number, a line-endings check, and a nightly audit that speaks only when something is wrong. A project chooses which source folders the spec check covers. The spec check reports a diff it could not read, or pull request text it was never given, as exactly that, never as a missing spec. Every app change also gets a production build, and a check fails when code hands process.env to the browser whole. After each deploy, a smoke workflow loads the live site in a real browser and raises the alarm on any console error. A red main opens an issue only for the newest commit on main and closes it when the next run passes. A cancelled job is re-run once rather than counted as a failure, and a job that fails once and passes on re-run is recorded as a flake, the same way a test is. Self-hosted Windows runners are first-class: the templates say where jobs run and which shell they get, PowerShell steps name their own execution policy, so a locked-down machine still runs them, the installer refuses to run unelevated, installs one folder per repository, and reads the repository from the git remote rather than the API so a spent API budget cannot stop an install, a doctor script checks the machine before any run, and an hourly watch reports a runner gone quiet.
One page from one config file: what the project talks to, the state of each system, and how to do the routine things. A live picture of the merge queue labels every machine's work, whether a pull request, the batch, or main's test, deploy and build runs, and explains each step on hover. Neither the console nor the queue fails silently: when something stops, they say what and where. It also shows what agents do after a rule stops them: follow the guidance, ask the person, retry, move on, or reach the same result another way, which it flags in red. Each rule gets a follow rate. Only the rule's name and the session are recorded, never the command, and the record can be turned off.
Keeps each project's copies of the scripts current with the plugin, feature by feature: it can apply one feature on its own, never adds a set of tools the project already has its own version of, keeps any local edits rather than overwriting them, and says what it left alone. A project can take over a plugin file outright, and the sync never writes it again. It can also stage its changes without committing, for a person to review first. It never rewrites a project's own CI file; a project on an older CI layout gets a step-by-step migration guide instead. Applied on a feature branch, it commits there rather than creating a dated one. A workflow it adds takes its runner and shell from the project's own CI file when that already says, filled in literally, and it refuses to commit a workflow holding a stray control byte; and the report names the secrets and variables each added workflow reads.
With a host's defaults, every push to every branch is a build, and build time is most of the bill. One setup script picks the cheapest path the project can take. First choice: build on the project's own Linux or macOS runner and deploy the finished output on a schedule, so the host builds nothing. Second: a scheduled deploy the host builds. Third: deploys from main only, skipping changes that cannot affect the app, at most one an interval. Release builds, such as app store uploads and test distributions, pass the same deploy gate first, so a busy day of merges makes one release, not dozens. A project can choose to start them only when a person asks, and the queue never starts a release workflow that is turned off. A deploy that falls back to a host build says so, and the session brief and nightly audit say when deploys fall behind. The owner console lists the two settings with no API: the cheapest build machine and a spend cap.
A project with a web app and a phone app starts with one design source: colors, type styles, spacing and icons in one file, generated into every platform's code, so a change is one line and the two apps never drift apart. A check stops any screen from using a hard-coded color, size or font, flags a screen whose two platforms use different type styles, and tracks when each screen was last compared across platforms by eye. It prints one line per step and ends after 90 seconds naming the step it was on.
Eleven hooks, thirteen refusals. Each one comes with one sentence saying what to do instead, so the agent keeps moving.
It gathers finished work, tests it together, and merges in batches, so nobody merges over anybody.
It also knows the ways a queue goes wrong:
When an agent starts, it gets a brief. One network call, and it knows the state of the project before it touches a file.
/project-bootstrap
Stands a project up for many agents, or rescues one that is struggling.
/project-status
Light subagents read bodies and comments and report one line per item, only for items that changed.
/project-drive
Proposes the next round from the board and the test results, and pursues only what a person approved.
Bitblitzin Bootstrap is the enforcement layer between an agent orchestrator and the repository. It is not a cockpit for launching agents, not a spec-writing tool, and not a hosted merge queue. It is the house rules for the repository those agents drive on, with machinery that makes each rule hold when nobody is watching. It sits alongside most of the tools below.
Conductor, Vibe Kanban, Agor, Claude Squad, Composio's Agent Orchestrator, Vyuha.
They do: run many agents in parallel worktrees behind a dashboard. They are where you launch and watch agents. Composio's is the closest in scope, giving each agent its own workspace, branch and pull request.
The plugin: works underneath any of them. It does not care which cockpit started the agent, only what the agent does to the repository.
claude-code-safety-net and similar.
They do: block commands that destroy files, such as rm, force push and reset, using the same hook mechanism the plugin uses.
The plugin: blocks those too, and also what is safe for files but ruinous for a team: running the whole test suite instead of one file, appending to a generated page, filing an issue with no state, merging around the queue, closing a pull request without a reason, dispatching an agent on a heavier model than the task needs, stopping a shared build daemon on a machine that hosts a CI runner, running a shell command with no title or one carrying more code than fits the task window, running a command that would hang waiting for input, and spending GitHub's GraphQL budget when the hour is nearly out.
Spec Kit, Kiro, OpenSpec, Tessl. Martin Fowler's site compares three of them.
They do: define how to write a spec.
The plugin: assumes one of them or none, and enforces only that every change belongs to a spec, named in the pull request. One deliberate departure from Spec Kit: a tasks file is written once at planning, turned into issues, and frozen, because a tasks file every pull request appends to is the shared page that breaks batching.
GitHub's merge queue, Mergify.
They do: serialize or batch merges with CI on the combined result. They are the standard answer to agents merging over each other.
The plugin: runs only the tests each change touched before the one full run, explains stuck runs in plain words including when GitHub itself is down, keeps its own API budget on REST calls only and runs one copy at a time, and checks the base is healthy before blaming any pull request. A project happy with GitHub's queue can use it and keep the rest of the plugin.
Built into Claude Code.
They do: give agents in one session a shared task list, messaging and file locks. That coordinates the agents one person is running right now.
The plugin: coordinates agents across sessions, people and days, through the issue tracker and git.
Combine all of it: one home for every kind of thing, hooks, CI checks that run per change class, a batching queue, a session brief that reads the project's live state in one call, a board that feeds itself, and a sync that keeps every project's copy current. Each piece came from a failure on a running project with multiple agents at once.
Parallel agents
pass alone, fail together.
Agents have no protocol to see each other's branches or claim files.
From a shell, which also works in a setup script. The plugin's name inside Claude Code is bitblitzin-bootstrap.
claude plugin marketplace add Pawper/bitblitzin-bootstrap claude plugin install bitblitzin-bootstrap@bitblitzin-bootstrap
Or inside a Claude Code session:
/plugin marketplace add Pawper/bitblitzin-bootstrap /plugin install bitblitzin-bootstrap@bitblitzin-bootstrap
Then, in a repository:
/project-bootstrap set this project up for many agents
Tests run with sh tests/run.sh and need only sh and awk. MIT license. Source on GitHub.
Built from failures.
Every rule here came from running a real project with many agents at once and watching something go wrong: checks that accidentally rewarded appending to shared files, a queue that exhausted its API budget, a test runner that could not find a package in a subfolder. Each failure became a rule. That is the whole method.