Every case study on this site runs through the same loop: classify the request, write the spec, build to the spec, measure the result, promote what repeats, forget what doesn't. That loop had a working name — ShipLoop — a one-page protocol in CLAUDE.md, five skills in .claude/skills/, and a scorecard that reads commits, DEVLOG headings, and session logs to measure how often each project actually followed the loop.
Today the whole thing is open source. One line to install into any Claude Code project you work in:
curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash
Repo: github.com/ruslan4427/claude-shiploop. MIT, no sign-up, no telemetry. Writing clean code with Claude isn't the hard part anymore — the models are strong enough to carry a feature if you point them well. The hard part is the surrounding discipline: catching the request that should be a quick question before it turns into a four-file refactor, keeping a spec/plan/tasks triple so the model can't drift, measuring whether the output actually shipped or just felt like it shipped.
Every project where I eventually built that discipline looked the same at month three: a CLAUDE.md, a DEVLOG, a classifier for inbound requests, a loop that promoted learnings into durable rules. Every project where I didn't build it looked the same at month three too — more tokens burned, more rework, cases where the model wrote a feature I'd already decided to cut.
The point of claude-shiploop is to skip the slow burn. Clone the discipline, measure yourself, delete whatever doesn't fit.
Three things, each independently usable:
The protocol — a nine-lane request classifier (Q, B, S, L, R, T, D, M, O, E) plus a spec-plan-tasks gate for anything above small-feature size. Lives in CLAUDE.md. Takes about two minutes to read. If you only steal one piece, steal this one.
The skills — five entry-point slash commands (/shiploop-start, /shiploop-router, /shiploop-brainstorm, /shiploop-tester, /shiploop-observer) that live in .claude/skills/. Each one is a markdown file; nothing is compiled. You can edit them in place without rebuilding anything.
The scorecard — a Node parser that reads your project's commits, DEVLOG entries, session logs, and git history, and emits five metrics per project: discipline (how many features went through spec-plan-tasks), rework ratio (reverted or amended lines ÷ merged lines), time-to-ship, cost per shipped feature, and tokens-per-ship. All five are explicitly nullable. If the data isn't there, the metric is null, not estimated.
The one rule that holds the whole scorecard together: if a project pre-dates per-project session isolation, or doesn't have the DEVLOG discipline yet, the metric comes back as —, not a number pulled from thin air.
Three of my own seven projects have — in the tokens column. That's visible on /tools right now. The scorecard refuses to fabricate numbers that would make the methodology look stronger than it is, because the first time a null gets softened to "estimated 15k tokens" is the first time the whole table loses its credibility.
The three-tier assignment (naked / self-spec / shiploop) is a human call, documented per project in /tools. It's not auto-detected and it's not pretending to be — that's a judgement about what methodology was actually in play, not a count.
Three rows have numbers. Three rows have an em-dash. The dash is doing more work than the numbers — it's the promise that the table hasn't been padded.
Across the seven projects I've shipped from this site, two patterns held up:
The discipline column is a floor for everything else. Projects that ran through spec-plan-tasks had rework ratios between 0.2 and 0.6; projects that didn't ranged from 2.0 to 4.5. The ratio of ratios — about ten times less rework when the discipline is in place — survived across different project sizes, languages, and client types.
The time-to-ship column moved the opposite way from what I expected. Projects that spent longer at the spec stage shipped sooner than projects that started coding on day one. The spec time was never visible in the "I'm working" sense, which made it feel slow in the moment. The scorecard made it visible.
Full tables, methodology aside, and the three-tier call for each project: /tools.
Supports --dry-run (prints the file-list without touching anything) and --target <dir> (install into a scratch directory for inspection). Reads your existing CLAUDE.md and merges the ShipLoop block in — doesn't overwrite your rules. The install script is 178 lines of bash, no dependencies beyond curl and git, and it's the first file worth reading before you let it run.
Repo: github.com/ruslan4427/claude-shiploop. Issues and PRs welcome.