Plan Mode, Brainstorm, or a Design Session
Claude Code gives you a few ways to think before you build. I use three of them, and the choice comes down to how much design the problem actually needs. Plan mode works for changes to code I already understand. superpowers’ brainstorming skill handles a feature of moderate size. When a project is complex enough that getting the design wrong is expensive, I want something heavier, and that’s why I built cc-atelier.
Plan mode plans. It doesn’t design.
Plan mode does what the name says. Claude goes read-only, explores the codebase, and comes back with a plan for you to approve before it touches anything. For a refactor or a bug fix in code I know well, that’s exactly right. The problem is already clear and the open question is how to change the code.
The design question gets skipped. Plan mode starts from your request as written and goes straight to how. It doesn’t ask whether you framed the problem correctly, what you’re assuming, or what alternatives you never considered. You get one plan, and it usually looks reasonable. A plan that looks reasonable is easy to approve without anyone ever having argued with it.
Brainstorming for the middle
superpowers has a brainstorming skill that fills a lot of that gap, and it’s my default for anything mid-sized. Before it asks a single question it restates what it thinks you want, and it keeps what you said separate from what it’s assuming. Then it asks clarifying questions one at a time, offers two or three approaches, and walks you through the design until you approve it. Only then does it move to planning.
For a new endpoint, a feature inside an existing flow, or a “can we even do this?” spike, that’s the right amount of process. I get the alternatives and the pushback in one sitting without paying for ceremony I don’t need.
Bigger problems need a different shape
Some problems don’t fit in one conversation: a new subsystem, something several projects will depend on, a decision that’s expensive to undo. For those I want the design to happen in phases across several sessions, with a record of why I decided what I decided.
cc-atelier is a Claude Code workspace built for that.
It’s a separate workspace
Design happens in its own repo, away from the code. That keeps me out of implementation mode before I’ve finished deciding what to build.
It works in phases, at your pace
Exploration, requirements, options, decision, detail, validation. Claude won’t propose solutions while you’re still exploring, and it won’t recommend anything while you’re laying out options. Laying out options without picking a favorite feels slow, but it’s the only way I get a fair look at the approaches I’d dismiss on reflex.
The phases set what happens in each stage, not how fast you go. The workspace works for you. When you’ve explored enough, move on to the next phase, or jump straight to one with /load-design-phase. Nothing makes you sit through a step you’ve already worked out.
Claude argues with you by default
It pokes at assumptions, names the trade-offs, and makes the strongest case for the option you’re about to throw out. If you need a break, “ease up” turns it down.
The critic hasn’t seen the conversation
/challenge hands the design doc to an agent with no session history. After three sessions I’m anchored on how I got here, and so is the Claude I’ve been talking to. A reviewer that only sees the document reads it the way an outsider would. I still have to accept, reject or defer each concern with a reason, so I can’t wave the whole report through or brush it off.
Decisions get written down
Significant choices become architecture decision records, so six months from now I can find out why we went this way without digging through chat history.
It ends with a spec, not a plan
This is the part I care about most. The design workspace can’t see the code, so it has no business picking file paths and task order. What it hands off is an approved spec covering behavior, edge cases, constraints and the interfaces that can’t change. The repo with the code writes its own plan, with the codebase open. Agents treat whatever you give them as authority. If you give them a detailed plan, they follow it and stop thinking about anything it left out. If you give them a spec, they still have to do the engineering.
What else is out there
cc-atelier isn’t the only attempt to get design done before the code. The best known fall under spec-driven development. GitHub’s Spec Kit runs specify, plan, tasks and implement inside your code repo. Kiro, the AWS IDE, generates a requirements file, a design file and a task list, then works the tasks. BMAD goes further and role-plays a whole agile team (analyst, PM, architect, scrum master) that produces a PRD, architecture docs and user stories.
They’re good at what they’re aimed at, which is getting an agent from intent to working code without wandering off. That’s also the difference. Those pipelines treat the spec as the first step toward tasks. cc-atelier puts its effort into the deciding: options laid out fairly, someone arguing with you, a critic with fresh eyes. It stops when the spec is approved.
On the interview side, grill-me from Matt Pocock’s skills walks a design tree and asks rounds of questions until nothing is left assumed. It’s a great stress test. It also gives a recommended answer with every question, which is exactly what cc-atelier holds back while you’re still laying out options.
Birgitta Böckeler’s look at spec-driven tools on martinfowler.com names the costs. A small bug fix in Kiro turned into four user stories with sixteen acceptance criteria. On Spec Kit’s output she wrote, “I’d rather review code than all these markdown files.”
cc-atelier produces plenty of markdown too. The difference is when you read it. A generated-spec pipeline writes the documents up front and hands you a stack to review. In cc-atelier the conversation does the heavy lifting. You work through the problem with Claude one phase at a time, and the documents record what the two of you already decided. By the time the spec is in front of you for a full read, nothing in it should surprise you. And the sledgehammer problem is the reason cc-atelier triages first: small work never enters it.
They work together
cc-atelier doesn’t replace brainstorming. They hand work back and forth. cc-atelier sizes up every request before asking anything, and anything that’s really a well-scoped change gets sent back to the code repo, where brainstorming takes it. On the other end, superpowers’ writing-plans skill turns an atelier spec into an implementation plan inside the code repo.
So I size the problem first:
| The problem | What I use |
|---|---|
| I know the code, and the question is how to change it | Plan mode |
| A feature or a feasibility question in one repo | superpowers brainstorming |
| A new system, a cross-project interface, a decision that’s expensive to undo | cc-atelier |
When I’m stuck between two rows, I pick the heavier one. Too much process costs me an afternoon. Too little costs me a rewrite.
Try it
git clone https://github.com/liteman/cc-atelier my-design-workspace
cd my-design-workspace
rm -rf .git && git init
Open it in Claude Code and run /start-design-session. It works on its own, and superpowers is a good companion if you want the handoff into planning.