Recommended Workflow

The previous sections were about installing and configuring tools. This one is about what to do with them: the workflow that takes a project from start to finish — where the scope lives, how a work item starts, what changes with its size, how it ends, and how you close the session.

A process exists to raise the odds of reaching the result you want, consistently. It takes an activity that depends on talent and improvisation and turns it into something repeatable, predictable, and open to improvement.

This is the flow I use, and it has a stated target: small to medium websites and web applications, MVPs, built entirely by AI agents, by a founder working alone. If the target were a large enterprise system, with a sizable team and a mix of agents and human programmers, the recommendation would be different, or would at least need adjusting.

#Why Claude Code doesn't ship a process

You have to build the flow yourself. Claude Code ships mechanism and doesn't ship method, and that's a design choice, not a gap:

1. It's a primitive, not a framework. It's a low-level, composable tool. Baking in a process would limit what you can build on top of it.
2. No single process fits everyone. Legacy and greenfield, a script and a distributed system, a solo developer and a team under compliance. Picking one would be wrong for most people.
3. The ground is still moving. Best practices for developing with AI are being discovered right now. The community iterates in days; a product iterates in months.
4. Mechanism, not policy. Anthropic ships hooks, subagents, skills, plugins, MCP, and CLAUDE.md; the policy — the process — is left to you. That's exactly why Superpowers and Spec Kit can exist.
5. A built-in process ages badly. The ceremony that's necessary today becomes waste once the model improves. In an external layer, it can be dropped at no cost.

One caveat: it isn't a process vacuum. Claude Code has micro-processes — planning mode, the todo list, exploring before editing, CLAUDE.md. What's missing is the full lifecycle: requirement, spec, design, implementation, and verification, with an artifact and a stopping point between phases. That's the gap community frameworks fill.

The cost of not filling it is direct: without the cycle, the result depends on the skill of whoever is driving — which is the opposite of repeatable, predictable, and improvable.

#Why Superpowers, and why it isn't enough on its own

Among the community frameworks, Superpowers is the one that best fits that target. It's also the most starred in its category on GitHub today, by a wide margin over the runner-up.

Three traits explain the choice, and all three are about low coupling:

• It's a set of skills, not a system. No CLI of its own, no state, no required config file, and no imposed directory structure beyond where it writes the spec and the plan. Each skill stands alone: you can use only brainstorming on one item and only systematic-debugging on another, without adopting the rest. The one thing it installs beyond the skills is a session-start hook that injects its usage instructions on every launch, /clear, or /compact — and it writes nothing into your project.
• Installation follows the agent's own convention. In Claude Code it arrives as a plugin, through the marketplace mechanism that already exists. There's no parallel runtime to maintain.
• Leaving costs what joining did. With no state and nothing wired in, uninstalling returns the project to what it was. On ground that shifts fast that matters: the less locked into a rigid flow you are, the faster you adapt yours when the tooling changes.

But it covers one implementation, not the whole project. Picture a web app that needs several features: the public pages, user sign-up, service listings. Superpowers can build one of them — user sign-up, say — from brainstorming through verification. What it doesn't do is manage the relationship between all of them: the order, what's already delivered, what's still open, what changed scope along the way.

If the app is quite small, you can treat the steps as one and build the whole thing in a single pass. But that isn't the case for most projects.

Other frameworks do cover that upper layer. GitHub's Spec Kit is the best-known example. The price is bureaucracy: more documents, more phases, and more planning before the first line gets written. For the target of this section, that costs more than it delivers.

So the decision was a simple flow, built on two things: Claude Code's native tools to manage the project as a whole, and Superpowers for the implementation of each large work item. That's the flow the following sections describe.

#The three layers of the record

Not every conversation with the agent needs to become a file. Asking how something works, weighing two alternatives, having it walk you through a piece of code: that gets settled in the conversation and dies there, at no cost.

What does need to be written down is what the next session will need to know. And that has two audiences.

The first is you. Planning raises your odds on any project, with AI or without: knowing what's already delivered, what's still open, and why the code ended up the way it did.

The second is the agent, and this part is specific to working this way. It starts every session without the previous conversation. What's written down is what it has; what isn't, for it doesn't exist. The record stops being documentation about the work and becomes an input to the work — it's what lets the agent build what you actually want, instead of an approximation of what it managed to infer. When it's missing, that shows up as you re-explaining the same thing every week, and every so often as the agent undoing something the previous session did on purpose.

That's what has to be recorded. When it happens is another matter: a work item can start with no file at all — from a line in the PRD checklist or an idea you just had — and only become a record at closing. What it can't do is end without leaving anything written.

That record is organized in three layers: