Three posts back we said the prompt isn't the system. Then we described the stack we build on, and then where our reusable prompts come from. All three circle the same unanswered question: what does the work actually look like?
It's four steps, and only one of them is writing code.
1. Work out what you actually need.
The first sessions are a conversation with you, not with a codebase. Often we drive it with the brainstorming skill from the superpowers collection — it takes a rough idea and refines it through questions, surfaces the alternatives nobody weighed, and keeps pulling on the parts that are still vague.
Using an agent here is not a gimmick. It's tireless in a way people aren't, and it has no stake in the answer, so it asks the awkward question about the edge case everyone was hoping wouldn't come up.
The output is a file: requirements.md. Business requirements in plain language, no technology in it. You read it and tell us where we've got you wrong. That's the whole point of writing it down.
2. Turn requirements into an architecture.
Next we take that document and run grill-me against it — Matt Pocock's skill that interviews you relentlessly about a design until every branch of the decision tree is resolved. Now it's Claude grilling us: what happens when two users edit the same record, what's the retention policy, what does this do offline, which of these two data models are you actually committing to.
Answering fifty questions before any code exists is not fun, and it is the highest-leverage hour in the project. Decisions made here are cheap. The same decisions made in week three are a refactor.
The output is architecture.md: the technical design, the trade-offs, and the reasons. This is the document that makes the AI produce better and more maintainable code, because it removes the guessing. An agent with a real design fills in the details; an agent without one invents a design silently, and you find out later what it chose.
3. Then implement.
Only now do we ask Claude to build. It starts from architecture.md rather than from a paragraph typed into a chat box, and that difference shows up in everything downstream — the structure holds together, the naming is consistent, and reviewing the output is a matter of checking it against a document instead of guessing at intent.
This step is fast. That's the part people notice. But the speed comes from steps one and two, not from the model.
4. Validate, and keep the design honest.
After the build, we have the AI validate the result against the requirements and the architecture — and we write those validations down, so what was checked is a matter of record rather than a memory.
And when the design changes during implementation, which it always does, architecture.md gets updated. A design document that stops matching the code is worse than none. Keeping it current is what makes it useful to the next engineer, the next agent, or you, six months from now — and since the repository is yours, all three of those documents are yours too.
The honest caveat.
This is our process as of this month. The field is moving quickly enough that we revise it regularly — the skills we use today weren't published a year ago, and something better will land before the year is out. What we don't expect to change is the shape: think first, write it down, then build.
Asking an AI to implement something is easy. Knowing what to ask for is the job.