Vibrator

Self-Driving SDLC Factory

Turn a GitHub issue queue into a self-driving vibe-coding factory. Vibrator is the conductor modern coding agents are missing: it decides what starts next, respects dependencies, gates on CI, reviews its own work twice, fixes what it finds, writes the permanent record, and merges. You write issues. The factory runs.

This page reads the way the factory does: as a shift log.

The line

issues → Claude implementation → draft PR → self-review → fixes → squash merge — every step synchronous, every step recorded. The planner shepherds existing PRs before starting new issues, so the repo never fills with half-finished work. Bugs jump the queue, milestones order it (never gate it), blocked by #12 in plain English is a real dependency, and GitHub sub-issues block their parents automatically.

One real-time dashboard covers every configured project: a shared pool of engine cylinders on the left, two-halved lifecycle pills in the middle — issue on the left half, its PR materializing on the right, from dotted outline to draft to merged — and a broadcast feed narrating every event on the right. 23 event types, one WebSocket, zero mystery about what your factory is doing.

The rules of the factory

• Two consecutive clean self-reviews, or no merge. One clean pass isn’t sufficient — Claude might fix something superficial and miss a structural problem visible only after the fix lands. Two clean passes, with CI gating any code-changing pass, gives the agent a chance to catch its own regressions.
• Bounded autonomy. MAX_CONCURRENCY caps parallel work; a planning mutex prevents engines from double-booking; parked PRs awaiting humans don’t starve the queue.
• GitHub stays the authority. Issues, PRs, reviews, checks, and merge state remain the coordination surface. No custom workflow language, no central server — a local process you can stop and restart.
• The human escape hatch is a label. Tag any issue or PR manual and the factory won’t touch it. Set GITHUB_PROJECT_NUMBER and the whole loop shifts to human-in-the-loop: one clean self-review, then it requests your review and parks — resuming only when you convert to draft, comment, or move the card back to Ready.
• Every merge is a historical artifact. Before merging, Claude reads the branch’s commits and diff and writes the final PR body — which becomes the squash commit message. No placeholder text in the permanent record.

The gauges

The Transformation Lab case names the three numbers that decide whether an agentic line is real: how much of it merges without a human, how many human touch-points each change still costs, and how fast the factory turns a red build green. The studio’s rule is measurable or it does not count, so these gauges read off this repo’s own operation — and until each number is trustworthy, the gauge says measuring, never a placeholder.

Why we built it

We’re hackers, and the studio runs small on purpose — small teams, sharp edges. A solo developer’s scarcest resource is creative attention, and agent babysitting burns it: copying prompts between tabs, nudging rebases, rereading CI logs. Vibrator makes the conductor programmable so the human stays in the two roles that matter — expressing intent and reviewing outcomes. It’s early infrastructure for running software projects as agentic systems, published at v0.1 with its design documents in the open. Willing to fail publicly; uninterested in consensus for its own sake.

It isn’t a toy claim, either: this studio’s other software ships through it, and it appears in the Transformation Lab portfolio as a measured delivery-operations case, currently scaling.

The backlog behind all of this is written the way the factory reads work: the studio’s own business plan — the BUSINESS.md program — tracks its moves as GitHub issues with plain-English Blocked by #N lines, the exact convention Vibrator already parses. The factory builds its own storefront — this very section shipped from one of those issues.

Run your factory

Proof: github.com/outrightmental/vibrator · design spec · agent loop & PR lifecycle · v0.1 — May 2026