Announcing beast-mode: follow-through for high-fan-out development

Here's the failure mode nobody warns you about when you start working with coding agents in parallel: the changes are fine. You kick off ten small, well-scoped work streams before lunch — a copy fix, a flaky test, a schema tweak, a refactor — and each one, individually, goes great. Then you come back after dinner and find seven merged and three orphaned: a branch pushed with no PR, a PR waiting on review feedback nobody applied, a green build nobody merged. The risk was never the changes. The risk is forgetting to finish them.

Today we're shipping the fix as a thing you can install: beast-mode, a portable Claude Code skill that encodes follow-through itself.

shnpx skills add VibesDIY/beast-mode

(or as a plugin: /plugin marketplace add VibesDIY/beast-mode, then /plugin install beast-mode@beast-mode.)

What it actually does

Most workflow skills optimize the quality of one change — test-driven development, systematic debugging. beast-mode optimizes the completion rate of many. Its contract: every work stream ends in one of exactly two durable states — merged, or an explicit, actionable hand-off. Never a dangling branch, never a silent stall.

The core is the autonomous PR loop, extracted from the working culture we described in 270 PRs in 17 days and hardened since:

• Every session that produces commits ends in an open PR — proactively, without asking. Agent sessions run on ephemeral cloud containers; a branch without a PR is work one container-reclaim away from vanishing.
• Review gets absorbed autonomously. Ping the reviewer bot the way it actually triggers, apply the feedback, escalate only genuine product decisions — and don't let a bot reviewer talk the PR out of existing without checking its objection against how the codebase really behaves.
• Merge-on-green is armed, not watched. Once review is resolved on a garden-variety change, the agent arms native auto-merge and moves to the next thread — with a guard: if no verified required check gates the default branch, it refuses to arm and merges directly on green instead. Risky classes (schema, infra topology, live flag flips, anything that isn't a clean git revert) always hold for a human.
• The loose ends get closed. Fixed issues verified actually closed (GitHub's auto-close is flakier than you think), and every PR drops a capture note — this post started as five of them.

And it's ambient, not invoked: a SessionStart hook injects a ~20-line digest of the loop into every session in the repo. A working style you have to remember to ask for isn't a working style.

The config seam is the whole trick

Workflow docs usually die with the repo they're written in, because the project constants — the reviewer bot's handle, the label names, the pre-commit command — are baked into the prose. beast-mode splits them out: the skill ships the transferable discipline, and each repo supplies one small beast-mode.config.md with its own values. Degradation is graceful by contract: no reviewer bot configured → the ping step skips cleanly; no capture directory → no capture note; no config at all → sensible defaults plus an offer to run /beast-mode setup, the bootstrap audit that checks (and fixes, or hands off) the repo infrastructure the loop depends on — auto-merge enabled, required checks present, labels created.

The piece we're proudest of is capability routing. Agents run in environments with different powers — a cloud session can't flip branch protection; a desktop session shouldn't babysit CI all night. When a task spans a capability the current environment lacks, beast-mode splits the work at the capability boundary, not the task boundary: finish everything the current environment can do (usually all of the code, the docs, the PR), then file one runbook issue a privileged agent or human can execute top-to-bottom — paste-ready commands, expected outputs, SHA-anchored against staleness. Fittingly, the skill was built by its own pattern: an unprivileged cloud session wrote the whole thing and filed the runbook for the steps it couldn't take.

Built in the open, dogfooded the hard way

The extraction itself was a beast-mode work stream, reviewed by Charlie on PR #3205 — and the process kept generating its own case studies. Mid-extraction, our documented reviewer-bot hazard fired for real and spawned a parallel, bot-authored PR for the very pilot we were writing; the disposal discipline (diff the parallel take, salvage the genuinely additive bits, then close it as superseded) is now part of the story. When we cut the old docs over to stubs pointing into the skill, we grew a dangling-anchor linter because markdown has no compiler. And the standalone repo is a CI-stamped mirror, not a fork: by convention no human commits there — CI re-exports it from the monorepo on every merge with the upstream SHA stamped in, so fixes land in the exporter, never the mirror.

If your failure mode is bad changes, keep your TDD skills close. If your failure mode is dropped threads, this one's for you.