Every popular Claude Code workflow is the same five steps

There’s a GitHub repo, shanraisshan/claude-code-best-practice, that has quietly become a map of the entire Claude Code ecosystem. As of this writing it has ~56,000 stars and trends regularly. Most of it is a catalog: concepts, hot features, skill collections, and — the interesting part — a comparison table of the dozen most popular Claude Code workflow toolkits.

Those twelve repos carry more than a million GitHub stars between them. They are built by different people, named differently, and ship wildly different command syntaxes. And the catalog’s author makes one observation in a single line that’s easy to miss:

All major workflows converge on the same architectural pattern: Research → Plan → Execute → Review → Ship.

That’s the whole story, and it’s worth sitting with. A dozen teams, working independently, optimizing hard for the same tool, all reinvented the same five-step pipeline. When that happens in biology we call it convergent evolution — unrelated species arriving at the same eye, the same wing, because the physics only allows so many good answers. The same thing has happened to Claude Code workflows.

The pattern, with the names stripped off

Here’s the same pipeline under four of the most-starred toolkits. The star counts are from GitHub, June 2026.

Canonical step	Superpowers (215k★)	Everything Claude Code (203k★)	HumanLayer (11k★)	Spec Kit (108k★)
Research	brainstorming	—	/research_codebase	/speckit.specify + /clarify
Plan	writing-plans	/ecc:plan	/create_plan → /validate_plan	/speckit.plan → /tasks
Execute	subagent-driven-development	/tdd	/implement_plan	/speckit.implement
Review	requesting/receiving-code-review, verification	/code-review → /security-scan → /e2e	/local_review	/speckit.analyze → /checklist
Ship	finishing-a-development-branch	merge	/commit → /describe_pr	/taskstoissues

Add the rest of the catalog — Matt Pocock’s skills (114k★), gstack (106k★), GSD, OpenSpec (52k★), BMAD (48k★), Compound Engineering, the RPI workflow — and the shape never changes. Some compress Research and Plan into one “spec” step. Some split Review into three (code-review, security, e2e). But nobody skips a stage, and nobody reorders them.

Why they all landed here

Convergence isn’t a coincidence; it’s a tell. It means the constraints are doing the designing, not the designers. Three constraints, specifically:

The model is the same. Everyone is steering the same Claude. So everyone hits the same failure modes, and the workflow is scaffolding built precisely against those failure modes — not against some abstract idea of “good process.”

Left alone, the agent skips straight to Execute. Ask for a feature and Claude will start editing files in the first response. That’s usually the wrong move on anything non-trivial, because it commits to an approach before anyone — human or model — has looked at the codebase or weighed alternatives. Every workflow front-loads Research and Plan for exactly one reason: to put a gate between the request and the first line of code. RPI (Research → Plan → Implement) makes this literal, with a GO / NO-GO verdict at the end of Research before any planning happens.

Left alone, the agent declares victory early. The model will tell you it’s done the moment the code looks plausible. Untested, unverified, “it should work.” So every workflow bolts a Review stage on the end — and the serious ones make it a loop, not a checkbox. In the catalog’s own comparison table, the review and test steps are the ones marked as sub-loops that repeat until a condition passes.

That second failure mode — shipping unverified — is the one the creator of Claude Code himself flags as the single biggest lever. In a March 2026 thread of his most-used tips, Boris Cherny’s most emphatic advice is to “give Claude a way to verify its output.” His analogy: asking someone to build a website without letting them open a browser. Give the agent a way to check its work — a browser, a test suite, a review pass — and it will iterate until the result is actually good. The whole Review stage exists to operationalize that one sentence.

What this means if you’re building your own setup

The temptation, looking at a 300-skill mega-repo with 200k stars, is to install the whole thing. Don’t start there. The convergence is telling you something cheaper and more useful: you don’t need their 300 skills, you need their five steps. The value isn’t in the command names or the badge count — it’s in the gates between the steps.

A minimal, honest version of every workflow above:

1. Research — before planning, Claude reads the relevant code and states what it found and whether the ask is even feasible. One gate: is this a GO?
2. Plan — a written plan you approve before any edits. Use plan mode (shift+tab) if you want it enforced. One gate: do I agree with this approach?
3. Execute — now it writes code, against the approved plan.
4. Review — tests run, a second pass (or a subagent, or another model) checks the work. One gate: did it actually verify, or just claim success?
5. Ship — commit, PR, describe the change.

You can run that with three slash commands and a habit, no framework required. The framework repos are worth mining for specific skills once you know which step is failing you — but the pipeline is the part that matters, and it fits on an index card.

Where this touches your CLAUDE.md

The five-step pipeline is the control flow. Your CLAUDE.md is where the standards for each gate live — what “researched enough” means in your codebase, what counts as a passing Review, which test command is the source of truth, what Claude is never allowed to ship without. Most setups encode this ad hoc, scattered across command files and tribal memory, which is exactly why two engineers running “the same” workflow get different results.

Getting the pipeline standards out of people’s heads and into the file is most of what we do in the CLAUDE.md audit on this site — 90 minutes, a written diagnosis, one rewritten root file, five reusable templates. $299 solo, $799 for a team of 2–10. If your team has adopted a workflow but it still behaves inconsistently, the gap is almost always undocumented gate standards, not the workflow itself.

Companion reading

• How to write a great CLAUDE.md — where the standards for each gate belong.
• How big can your CLAUDE.md get before it hurts performance — keeping those standards tight enough to actually be read every turn.
• Claude Code hooks in 2026 — how to make a Review gate deterministic instead of hoping the model remembers it.

Sources: shanraisshan/claude-code-best-practice (catalog and convergence observation); GitHub star counts as of June 2026; Boris Cherny’s “15 tips” thread, March 30, 2026.