Write it down
before you
build it.
First stop on the drawing: deciding what you are building, before anyone builds it.
The spec says what you are building, who uses it, and what it must do. It lives in your project folder as SPECS.md, and Claude Code reads it every session.
When this stop is done you have one file you can read in plain English, and every pack after it is built from that file.
If it writes a whole spec instead of asking, paste this.
Two things /spec-writer will not ask about. It asks good questions and it cannot ask about what it does not know you want, so these two are yours to raise.
The numbers.
Each box gets a number written on it with a marker. How many digits, and can a number be used again after a box is emptied? Say the rule while it interviews you, or Claude Code picks one for you.
The boxes survive the update.
You add three boxes, the app is changed and started again, and the three boxes are still there. Nobody thinks to say so out loud, so you say it.
A pack is one
small piece of work.
Second stop on the drawing, and the one this whole part rests on. A pack is one small job: small enough to finish in one sitting, and clear enough that you can look at the screen and say whether it is done.
Your app is three packs. Here they are, in the order you build them. You finish one before you start the next.
Make a box and see it.
Add a box, get a number for it, write that number on the real box. It appears in your list.
Open a box, list what is in it.
Type the number, land on that box, add things by typing. Close the app, open it again, still there.
Find the kettle.
Type kettle and see every box that has one in it.
The help you are handed shrinks as you go, and that is planned from the start. The drawing below is the whole of it.
A pack closes against its acceptance criteria: the lines that say what must be true before it is finished. You are done when every line is true on your screen, and not before.
Pack 1’s lines read like this: I add a box, the app gives it a number, and that box appears in my list. Every word of that can be checked by looking.
A line you cannot check by looking at the screen is a wish. “The list feels fast” is a wish. “The box appears in the list without me restarting the app” is a line.
A skill is a
method statement.
Five skills landed in your new project when you made it on chapter 02. You have used two of them, /secure-machine and /guardian, back in Part 2. This chapter is the other three, and the check most likely to stop you today.
When this chapter ends you can name what each of your five skills does, and you know the one move that gets you past a check that has stopped you.
Where it holds.
A named procedure. Written once, the same every time, for whoever is on site.
Where it breaks.
A method statement assumes a human reading it with judgment. A skill is followed literally: what it does not say, it does not do.
/spec-writer interviews you and writes the spec. /bootstrap-project turns your new folder into a project and copies the rest of the playbook’s skills into it. /implementation-guide names the step you are standing on.
You run the middle one once, at the start. The other two you use all day.
You met a gate on chapter 03: the double bar across the drawing. This is the one that sits there, and the drawing below is what it actually does, in four steps.
It reads every document your pack leans on and lifts out every question nobody answered. The dangerous ones are the questions nobody marked as open: a line reading “roughly fifty boxes” looks settled and is not, because nothing can be built against “roughly”.
It runs before every pack and it is not optional. Ask the planning step, /feature-plan, for a plan before the gate has run, and it stops and tells you to run the gate first.
When it stops it prints a long name. Paste back exactly what it printed. You never have to type that name and you never have to read it.
One word of it is worth knowing, because it is your own. Architectural here means the shape of the software, not buildings.
Neither the gate nor the planning step is one of your five. Both arrive when /bootstrap-project runs.
Claude Code,
in a window.
Everything so far has happened in a window of typed text. There is a second way to run Claude Code on your Mac, with menus and buttons, and it is called Claude Code Desktop.
It is the same Claude Code doing the same work. The reason you open it today is that the fake iPhone from chapter 11 appears inside it and nowhere else.
When this chapter ends you can point it at your project, recognise every control along the bottom, and know where to look when something needs changing.
Everything you need is on one strip along the bottom of the window. Here it is, from a real screen.
Left to right: where the work runs, which folder, which line of work, then the box you type in. Along the bottom: the mode, and which model is doing the thinking.
The first button asks where the work happens. Yours stays on Local, which means on this Mac. The others send the work somewhere else, and the fake phone cannot be reached from there.
Local is ticked. Leave it there.
The second button. Your folder will not be in the Recent list the first time, so press Open folder and find the one ending in -proper.
Two controls sit at the right hand end, and neither one needs changing today. They are here so you recognise them rather than so you set them.
One is already ticked and it is the right one. If somebody ever asks you which model you are on, this menu is the answer.
Auto already has a tick and the word Default beside it. Nothing to do. It is the yellow button on the strip.
That yellow button has a twin in the typed window, and it does not look anything like it. Same setting, different place, so here is what it looks like there.
No menu here. It is a line of text at the bottom, and the words auto mode on are in yellow. You do not have to switch it on. It arrives on.
Two more things live in menus rather than on the strip, and both are worth knowing where to find before you need them.
The first menu at the top left of your screen, beside the Apple symbol. Check for Updates, then let it restart. It is not in the File menu, so do not go looking for it there.
And connectors, which let it reach into things you already use, like your calendar or your files. You need none of them today. This is only where they live.
The row at the foot of the sidebar opens this. Settings is the first item.
There are two groups. Connectors is in the second one, under Customize, not in the first one under Settings.
Add nothing yet. Every connector you add is one more thing that can go wrong while you are still learning what normal looks like.
Now the fake phone, and the honest part of this chapter.
There is no button that opens it and no setting that turns it on. You point Claude Code Desktop at your folder, ask it in plain words to run your app, and the phone appears beside the conversation on its own.
If you want to open one by hand afterwards, it is in the Views menu, which only lists it once a phone has been attached to that conversation.
This is the three dots at the top right of a conversation. It is published here so you can stop looking: the phone is not in it, and it was never meant to be.
That is the one screen this workshop cannot show you, because nobody here has watched it. What you are aiming at is your own app running in the right hand half, which you can tap with the mouse.
The first time it uses a phone it asks your permission, once for that phone. Say yes. If you say no, the phone still works for your own taps and you can turn its access on later.
And in Anthropic’s own words: pictures of that phone are sent to them and kept with the rest of the conversation, so do not sign in to a real account on a phone it is using.
For the app you are building there is nothing to sign in to, so this one costs you nothing today. It is worth knowing before the day it does.
One last thing, and it is the one that can waste an evening: this half of the window needs the Xcode from chapter 10 to be version 26. Version 27 replaces the phone with something else and it does not work here.
Three packs.
The third one is
yours alone.
Last chapter. Two packs are done with the words handed to you. For the third one nobody hands you anything, and that was the plan from the first page.
Everything in the third pack is something you have already done twice: check the lines that prove it works, run the gate, ask for the plan, build, review, commit.
What is taken away: the lines to paste. What still carries you: your spec, your own list of what must be true, every block that names what it wants, and the four checks. That is not scaffolding. It is the building.
If you do not know what comes next, paste /implementation-guide. It names the step you are standing on and one thing to do next. It is the same line you used to come back on chapter 10.
Solo is not silent either. The Ask button, bottom right of this page, sends a question straight to Munim, and he gets it on his phone right away.
Three lines before, one after.
That number is not a failure. Each one names a place where the playbook does not carry you alone.