OSS · cc-autoship

Turn AI's development work into a traceable asset

An open-source Claude Code harness that records every AI action as GitHub Issues, PRs, and reviews. Delegate the work — keep the accountability.

You can hand implementation to AI now. But the more sessions run in parallel, the higher the cost of following what they actually did — until you can no longer stand behind the result. cc-autoship is a set of Claude Code harnesses (open source) that records every AI action as a GitHub Issue, PR, diff, and review. Delegate the work, and you can still trace it — and take it back over if anything goes wrong. Less a standalone plugin than a way to wire AI's work onto the same GitHub flow real teams already use, with no metered billing on top.

GitHubMIT License · maee-co/cc-autoship

Getting started

Requires: gh (authenticated), git, Node.js (v20+)

/plugin marketplace add maee-co/cc-autoship
/plugin install cc-autoship@cc-autoship-marketplace
/reload-plugins

Run these inside a Claude Code session. See the README for the full guide.

The problem — parallel AI work is hard to follow, and the context is worth keeping

Delegating development to AI is no longer the hard part. You can line up several sessions and run them at once. But staying in pure vibe-coding mode tends to stall at the POC stage.

What I found hardest was that the results are not intuitive to follow afterwards. The raw logs stay on my machine (.sessions), so it is not that you cannot trace them. But reading the situation out of them takes time, and the more sessions run in parallel, the more there is to read. If you cannot retrace what happened when something breaks, you cannot really take responsibility for it.

A dark sea seen from directly above. A dozen small orange ships drift in scattered directions, their wakes crossing one another and fading out towards the edges. There is no harbour and no shoreline.

When the history is kept in a form that is easy to handle, you can ask the AI about it later, look back, and fix things.

There was one more reason. Now that a single person can build several things at once, I wanted to accumulate the context of that process — for the day I feel like writing about it. That thought is where this mechanism started.

Design principles — three pillars

The starting point was simple: rather than invent something new, reuse the machinery real teams already develop with — Issues, PRs, reviews. Traceable, compounding, sustainable. These are not three separate features but three faces of one idea: leave a reusable record without waste.

Traceable

The more you run in parallel, the harder it gets to see what was actually done. cc-autoship leaves every change on GitHub as an Issue, a PR, a diff, and review comments. Once the record builds up you can connect to it over MCP and follow the flow directly — or ask the AI later why it made a particular call.

Compounding

Left at the commit level, changes scatter into fragments that are hard to manage as meaningful units. cc-autoship groups implementation into right-sized PRs and lets only gate-cleared work into main. Consistently sized PRs stack up, and they become an asset you can review and look back on as they are.

Sustainable

Recording AI reviews as PRs and reviews the way a real team does usually means wiring up GitHub Actions, which is metered. cc-autoship was designed as its own harness instead of leaning on that. Review → comment → fix runs inside a flat-rate subscription (Claude Max 5x or higher recommended) and GitHub’s free tier, so you keep a real development pace at a fixed cost.

How it works — deterministic gates and hooks

From a single “I want to build this,” it runs Issue → implementation → PR → review → quality gates → merge as one continuous flow.

The cc-autoship loop: Ask (one line about what you want) leads to an Issue, a build inside an isolated worktree, a PR, an AI review, a gate on five axes (size, scope, review, CI, public paths), and finally a squash merge into main that closes the Issue.

Deterministic gates

Whether a PR can merge is decided by tested pure TypeScript functions. Size, scope, review findings, and CI (plus e2e for UI) are checked mechanically, and green means it merges itself. When a required tool is missing, the gates stop loudly instead of skipping silently. The call is never left to the mood of an LLM.

Hooks that protect main

Direct pushes to main are blocked. The only way in is a PR that cleared the gates, and paths you mark as public content are never merged autonomously. On repositories with branch protection, cc-autoship defers to GitHub’s own enforcement; everywhere else the hooks keep guarding.

The shape of good development, built in

Issue-driven work, iteration, review, and tests run to form without you having to think about it. You move forward without relying on willpower or on how much you happen to know.

Results — how far a flat-rate subscription goes

cc-autoship itself is developed this way. Across the 13 weeks from late March to late June 2026, 440 pull requests were merged in total, and the busiest week merged 102. All of it with no metered API billing, inside a flat-rate subscription (Claude Max 5x) and GitHub’s free tier.

Bar chart of pull requests merged per week. Across the 13 weeks from 30 March to 28 June 2026 the peak was 102 and the total was 440.
Source: GitHub Search API, retrieved 2026-08-03. Covers only the stretch run on Claude Max 5x.

Because it runs on GitHub’s free tier, there were stretches where merges piled up, hit the limit, and had to be covered by hand. So it is not full automation — it is automatic work with a human as the final gate.

Open source — reaching people who feel the same way

This is the mechanism I built so that I could run exactly the same flow as a real development team, as one person plus an AI team — and it is also a record of that.

I am releasing it as MIT-licensed open source, hoping it reaches people who, like me, can now delegate a great deal to AI but have run into the ceiling of their own cognitive load — or who feel uneasy about not being able to trace what was built and how. It runs on GitHub alone and requires no external service, so you can try it in your own repository as it is.