Pawper/bitblitzin-bootstrap

A Claude Code plugin for projects where many coding agents work at once.
Without it, thirty agents behave like thirty new hires with no manager: they write notes in the same file, run the slowest test, merge over each other, and nobody knows the state of the project. The plugin gives the project house rules and the machinery that enforces them, so the rules hold when nobody is watching. It decides one home for each kind of thing, refuses the commands that make agents collide, keeps the board honest, merges in batches, and opens every session with the live state of the project. Every rule came from something that went wrong on a real project, one lesson per pull request.
It is the enforcement layer between an agent orchestrator and the repository: not a cockpit for launching agents, not a spec-writing tool, not a hosted merge queue. It sits alongside those. Where it fits among them is on the site.
**Install**, from a shell:
In a terminal session the same two lines work as /plugin marketplace add ... and /plugin install .... In the desktop app /plugin opens a panel and ignores what follows it; use the panel's "add marketplace" with Pawper/bitblitzin-bootstrap, then install from it, or use the shell lines above.
Then, in a new or struggling repository: /project-bootstrap set this project up for many agents.
**What you get**
- **Ten hooks.** Deletes, forced pushes, full test sweeps, hand edits to generated pages, issues without a State, agents dispatched on a heavier model than the task needs, merges that go around the queue, pull requests closed without a reason, detached worktrees, build daemons stopped on a machine that hosts a runner, commands too big for the task window or with no title: all refused before they run, each with one sentence saying what to do instead. A stop hook that will not let a task end with files stranded in its worktree. A session brief that prints today's date in the owner's time zone, main, the open pull requests, who has the ball on every issue, the queue, the leftovers and the proposed next round, in two seconds and one network call.
- **Templates for everything the skill creates.** Issue template, CLAUDE.md and AGENTS.md, the status page that builds itself from stubs, a CI skeleton that runs only what a change touches and reports once, a merge queue that batches by default and says in plain words why a run is stuck, board and label scripts, a nightly audit that speaks only when something is wrong, a worktree script that gives every branch an ending.
- **Two more skills.** /project-status has light subagents read bodies and comments, only for items that changed, so you keep one line per item. /project-drive proposes the next round from the board and the checks and pursues only what you approve.
- **Deploys that keep the host's bill down.** Build CPU was nearly all of one owner's Vercel bill, because every push to every branch was a build. One script sets the cheapest path the project can take: build on its own runner and deploy the output on a schedule, or a scheduled deploy the host builds, or Git deploys from main only that skip changes which do not ship, with an optional throttle. On one project's last forty commits to main that is ten builds instead of twenty-nine, or none on the host at all.
- **An owner console.** One page, from one config file: what the project talks to, the state of each system, how to do the routine things.
It was built for GitHub, Actions, gh and Claude Code. When a project uses something else, the skill says so once and adapts. The full story is below; the user flow is ten short steps.
Why
Rules written for one agent become pathologies when thirty follow them at once. One agent appending a line to a status page is tidy; thirty doing it is a merge conflict on every PR. One agent running the full test suite before it pushes is careful; thirty doing it is a merge queue that waits an hour per change. The codebase is the one surface every agent must write to, so anything that lives there is something they all collide on.
The fix is to decide two things before the first feature agent runs:
- **Homes.** One place for each kind of thing. Work lives in issues, status on the board, orientation on one generated page, data in the database, research outside the repo. Nothing goes anywhere else.
- **Enforcement.** An instruction decays under load. For every rule there is a hook that blocks the dangerous command, a CI check that fails on drift, a required field at filing, or an audit that speaks only when something is wrong. A rule with none of those will not hold.