Cog is the development lifecycle, automated.

Friction

Garbage in, garbage out. An autonomous build phase is only as good as the issue it picks up — and turning a vague idea into a well-scoped issue is exactly where developers leak the most time.

Feature

Shape and capture live as slash commands inside your harness — Claude Code, Codex CLI, Gemini CLI, OpenCode, Pi.dev — and run where you already are. Shape decomposes a complex idea into ordered, implementable issues through an aggressive Socratic conversation. Capture turns a rough note or quick observation into a high-quality GitHub issue grounded in the codebase. Both ship as open-source markdown in the public mechanical-advantage-ai/cog repo, so you can fork them and tune the prompts to your team.

Outcome

Input quality is what makes the rest of the lifecycle work. Better issues; better PRs.

Friction

Review comments arrive in a tab away from your editor. Copying them into a fresh agent session that has lost the original implementation context — and shepherding the back-and-forth through to resolution — is a tax on every PR.

Feature

Cog reads every comment on a PR — inline code comments, summary reviews, conversation threads — categorizes each one (should fix, already addressed, intentional, won't fix), implements the fixes the right way, posts a concise reply on each thread with the commit hash, and resolves the threads on its way out.

Friction

Even with a one-shot responder, you still have to remember to run it. Across a busy week, hours disappear into shepherding review cycles that could be hands-free.

Feature

Revise watches your open PRs for changes-requested reviews. When a reviewer pushes back, Cog picks the PR up automatically: reads the comments, makes the changes, runs the full check suite, pushes, replies, resolves, and requests re-review — all without a developer at the keyboard. The original implementation session is resumed so the harness already knows why the code was written the way it was.

Outcome

Review cycles run themselves until you approve.

Friction

Even a well-shaped issue still needs a developer to start the harness, run the tests, verify the diff, push, and open the PR. That overhead is repeated on every issue.

Feature

Build pulls an unassigned issue, creates a worktree and branch, explores the codebase, plans the implementation, writes the code, runs format / lint / every test suite until green, performs a self-review on its own diff, commits, pushes, opens the PR, and handles the first round of automated code review. You get a notification with a link to a ready-for-review PR.

Outcome

Best on issues sized small enough to be tractable, against a codebase with real test coverage. Garbage in still wins.

Friction

Once a PR is approved, the merge dance begins: pull main, rebase, resolve conflicts, retest, push, wait for CI, merge. On a 10-PR day, that's up to a couple of hours of busywork between approval and main.

Feature

Merge picks up an approved, non-draft PR, merges main into the branch, resolves conflicts, fixes any CI failures the merge produced, handles any automated code review the new push triggers, and squash-merges when everything is green.

Outcome

Roughly a full developer-day per week recovered on a busy team.

Friction

Orchestrating build, revise, and merge across many open issues by hand is its own job. The order matters — finishing existing work always beats starting new — and humans aren't great at sticking to it under pressure.

Feature

Start runs a single sequential loop: merge approved PRs first, then revise PRs with changes requested, then pull a new unassigned issue and build it. Restart from the top after every unit of work; sleep with backoff when there's nothing to do. Multiple Cog instances on the same repo coordinate through a three-layer claims system (local lock, remote API, GitHub state) so you can scale throughput without races.

Outcome

24/7 hands-free SDLC. Approve PRs in the morning; new work shipped overnight.

Friction

Even cog start blocks on human approval. For nitpick fixes and trusted, low-stakes work, that block is what breaks an overnight pipeline.

Feature

Rubber-stamp is an opt-in step that auto-approves PRs awaiting review so they continue through the loop unattended. It runs ahead of merge in the priority order and is disabled by default — the deliberate naming is a reminder that this is a tool for trusted work, not the default.

Outcome

Use it where the cost of a missed bug is low and the cost of a stalled pipeline is high. Use it carefully.

Friction

Harnesses and models change every few weeks. Public benchmarks are gamed and don't reflect how a model performs on your codebase. Picking a single combination for a high-stakes issue is a guess.

Feature

Arena routes a single issue to multiple harness × model combinations in parallel. Each combination implements the issue independently against its own worktree. A judge model then evaluates every attempt, takes the strongest pieces, and synthesizes a single high-quality PR — with attribution data so you can see which combinations contributed what.

Outcome

Best-of-N on the issues that matter most. Real-world intuition for which combos win on your codebase, not someone else's benchmark.

Friction

A single Cog process is light — about 12 MB of RAM. RAM is the practical limit; GitHub API rate limits are the practical ceiling (around 35 cogs per repo per machine in current experience). Scale beyond that and you need more machines, which means coordination.

Feature

Run cogs across multiple machines — a $600 Mac mini, a mini PC on Linux, another on Windows — coordinating through the remote claims API. Each machine pulls its share of work and stays out of the others' way.

Outcome

Dev capacity is bounded by your ability to articulate work, not by your headcount.