Handover Day
Part 5 of 5, for Janika_

Handover
day.

The playbook is Munim’s folder of building methods. A handover is finished work passing to somebody who takes it on, and today yours passes to the playbook.

Four apps are finished. Two you built, in Part 3 and Part 4. Two are Munim’s, from the same idea in the same weeks.

By the end you have one table scoring all four against the lines you wrote in Part 3, and your own written answer underneath it.

You also hand over your site diary, the file where you wrote down what confused you. Every entry in it becomes a proposed change to the playbook.

Nothing so far has asked whether the playbook was worth the extra work it costs. That is this part, and the answer is allowed to be no. You read it alone. You need Munim for parts of it, and for one whole chapter.

ProjectShip It Sheet05 Scale1:1, Briefing RevD
Chapter 01 · On your own now

Three answers,
from nothing.

Say each answer out loud, then tap the card to check it. These three are the words you keep after today.

If one will not come, tap it and read it. Nothing here is scored. Every chapter after this one uses all three of them without stopping to explain them, which is why they come first.

Which file in your project is yours, not Claude Code’s?
SITE_DIARY.md, your site diary: where the playbook failed you, never where you failed.
tap to reveal
What do you write before you are allowed to look?
Acceptance criteria. What must be true before you call it done, written before you look.
tap to reveal
What is a pack? One sentence.
One piece of work, small enough to finish and check in one go.
tap to reveal
One to try
A paste line is a line of text with a copy button. Press the button, then paste it into Claude Code. A guided session is Claude Code working through one part with you, and /workshop 5 starts your last one. Suppose you press copy on it and paste it into the Ask panel at the corner of this page instead. What happens?
Chapter 02 · The comparison

Four apps.
One honest look.

A two by two grid. The columns are asked once and with the playbook. The rows are yours and Munim's. Yours asked once is Build 01, from Part 3. Yours with the playbook is Build 02, from Part 4. Munim's asked once is Build 03 and Munim's with the playbook is Build 04, both built in the same weeks. WHAT CHANGES ACROSS THE FOUR ASKED ONCE WITH THE PLAYBOOK YOURS MUNIM’S BUILD 01 BUILD 02 BUILD 03 BUILD 04 built in Part 3 built in Part 4 built in the same weeks built in the same weeks Two things change across these four: who built it, and which method.

The same app, four times. You built two of them and Munim built two, and each of you built it once by asking and once with the playbook.

This is not a scoreboard of you against Munim. He has built this way for years. His two are in it so you can see what each method does in hands that already know it.

This chapter is where you decide what the playbook bought you and what it cost you. When it ends you know which two of the four are a fair pair to compare, and which two are not.

The cost is not hidden: the playbook made you write things down before anything ran, and writing takes time you could have spent building. It can go either way, and the honest answer is the one that goes in.

Build 01

Yours, asked once.

One paragraph. Whatever came back, you kept.

Built in Part 3
Build 02

Yours, with the playbook.

A written brief, three packs, each one checked at the end.

Built in Part 4
Build 03

Munim’s, asked once.

The same paragraph, from years of doing this.

Built in the same weeks
Build 04

Munim’s, with the playbook.

The playbook, run by its author.

Built in the same weeks
Seeing all four

Build 01 and Build 02 are yours, and they are already on your phone. You opened them there in Part 3 and in Part 4.

Build 03 and Build 04 are Munim’s. Ask him to show you his two. You want to have seen all four before you start the next chapter.

You score all four in the next chapter, in one table, against the lines you wrote in Part 3 before you had seen any app at all.

The last line under that table is your answer to the question above, and you are the one who writes it.

Two to try
Munim has run the playbook for years and cannot un-know it. His Build 03 came out better than your Build 01. Does that show that asking once is enough?
Build 01 went at the whole app in one ask. Build 02 finished three packs and stopped there, on purpose. Build 01 passes more of your acceptance criteria. Did Build 01 do more?
Chapter 03 · The readings

Seven readings.
The last word is yours.

A reading is one measurement, taken the same way each time. Seven of them turn four opinions into something written down that somebody else could check.

When this chapter ends you have one file, READINGS.md, holding all seven readings, and the last thing in it is the answer you write yourself: what the playbook bought you, and what it cost you.

A surveyor's levelling staff standing upright beside a tripod mounted level, with a closed field notebook at its foot
Reading 1, app 1: yours, asked onceIt remembers ......... PASSIt searches inside boxes FAILFifty boxes, not three PASSA photo from my phone UNKNOWNThe rest of your list goes below this, then the same column again for apps 2, 3 and 4.Only readings 2 and 6 cannot be taken today: reading 2 fills in tomorrow, reading 6 in a week.No winner at the bottom. That line is yours.
This is a drawing of one column of your table, not your table. Claude Code writes the real one into a new file, READINGS.md, in your project folder beside your site diary. The rows are the first four lines of your own list. UNKNOWN is the same word the safety check used in Part 2, and it means the same thing here: nothing has been read either way, which is what a reading you have not taken yet looks like. It is an entry, not a blank.
In the session

Start your last guided session.

Paste to Claude Code/workshop 5
What you should see: Claude Code names where you got to, then one question.
The seven readings

1. Does it work? Every line of your acceptance criteria, PASS or FAIL, in all four.

2. Still working tomorrow? Your own two, the next day, on a phone that has never opened them. A phone that has never seen the app cannot be showing you a copy it kept.

3. What breaks in real use? Fifteen minutes with each of the four, doing what you really would.

4. Going round again. One tally mark for every time you had to say “that is not what I meant”. Your two builds only.

5. Sittings. How many sittings each of your two builds took. One sitting is one stretch of work at the desk, counted afterwards, never predicted.

6. Explainable in a week? Seven days from now, say how your own app works in your own words, without opening it.

7. How sure are you? Of your own PASS and FAIL in reading 1. One to five, written beside them.

Paste to Claude CodeMake a new file, READINGS.md, in my project folder beside my site diary. In it put one table: my acceptance criteria down the side, one line each, Build 01 to Build 04 across the top. Then the other six readings under it. Do not tell me which app won. When the table is full, ask me what the playbook bought me and what it cost me, and write my answer at the bottom in my words, unchanged.
What you should see: a filled table in READINGS.md, no winner at the bottom, and your own answer written under it in your words.
Chapter 04 · From memory

Teach it
back.

A closed laptop lying flat with a teacup on a saucer set either side of it

Four working apps do not show whether you can do this alone, because Munim was in the room. Telling him how it works does. This is the one chapter that reads you rather than an app.

What you get from it: one diary entry for every step you had to be reminded of. That is a list of what the playbook never told you, and it is the most useful thing you hand over tomorrow.

Out loud · Nothing on the screen

Walk him through it, from nothing.

Sit with Munim, nothing on the screen. Describe how you take one pack from an idea to a working thing on your phone.

He may ask why. He may not help, because a step he has to supply for you is exactly the thing this is measuring.

Paste to Claude Codediary that
What you should see: he follows it without adding a step you left out. Every gap he fills is one the playbook left. Say those two words to Claude Code once for each gap, while you still remember them, and it writes the entry. If you dry up halfway
You cannot remember what comes next

That is the measurement, not a failure. Doing this with nothing on the screen is the only way to find the steps that are not yours yet. One of them has put its hand up.

Munim still does not fill it in, and that is not him being unkind. A step he supplies for you is a step nobody can count either way afterwards.

Nobody explains a way of working they have used three times without stopping somewhere. Where you stop is where the playbook explains itself worst, which is the whole reason you are doing this out loud.

What it costsNothing. A step you could not name is the most useful line you hand over tomorrow.
What you do
  1. Say out loud which step you have lost, so it gets named rather than passed over.
  2. Carry on from the next step you are sure of. This does not have to come out in one piece.
  3. When you finish, say “diary that” to Claude Code once for each one, while you still remember them.
Paste to Claude CodeAsk me to describe how I build a pack, out loud, then compare what I say with the playbook: what did I leave out, what is out of order, what did I explain better?
What you should see: an answer to all three questions. Where your words beat the playbook’s, Munim changes the playbook.
Chapter 05 · The handover

Your diary
becomes the playbook.

Your site diary, SITE_DIARY.md in your project folder, is where you wrote down every place the playbook left you stuck. Part 2 said this was experimental. Today that record is the point.

It is an RFI register, a log of requests for information, raised against the playbook and never against you. An RFI stops work. A diary entry never did.

When this chapter ends your diary has a list at the end of it. Every entry you raised has become one named change to one named file in the playbook, in words Munim can act on.

A wooden pigeonhole rack with two envelopes waiting in it
Paste to Claude CodeRead SITE_DIARY.md end to end. Turn every entry into one proposed change to the playbook: which file, what it says now, what it should say instead. Group repeats into one. Flag any entry you think I have wrong. Write the whole list at the end of SITE_DIARY.md, under today’s date.
What you should see: a list at the end of your diary, with fewer proposals in it than you wrote entries, because repeats have been grouped. At least one entry Claude Code says you have wrong.
A closed loop with four stops, drawn with arrows showing which way it runs. You raise an entry. It goes to SITE underscore DIARY dot md, one file with two authors, kept in your project folder on GitHub. Munim reads it where it sits, so you send nothing and attach nothing. He makes the change in the playbook. The last leg of the loop returns to you: you get told which entry changed it. HOW YOUR RECORD REACHES THE PLAYBOOK YOU SITE_DIARY.md MUNIM you raise an entry one file, two authors he reads it where it sits you send nothing, you attach nothing THE PLAYBOOK he makes the change you get told which entry changed it
The mechanism

One file, two authors. Munim writes into it because you invited him in Part 2, and you can take that access back whenever you want.

Every entry names who raised it, and is about the playbook, never a person. You can read every page of the playbook and change none. So the diary is how a change gets proposed: you raise it, Munim makes it.

You send nothing and you attach nothing. Your list sits at the end of your diary, in your project folder on GitHub, and Munim reads it there. Tell him it is ready when you want him to look.

When one of your entries changes the playbook, you get told which entry and what the file says now. A record nobody answers is a record nobody keeps.

What you can do now.

Five parts ago, none of this was yours.

A clipboard and pencil resting on a stack of site drawings, the daily site log
The inventory

Ran the safety check on your Mac and read every verdict, including the rows it could not read.

Put your project folder on GitHub, where every version of it is kept. Every page of the playbook is open to you to read.

Wrote your acceptance criteria before you had seen anything, then said where the result missed them.

Took a pack from a written brief to a working app, three times. The third time nobody handed you the words.

Read a review pass (Claude Code reading your finished pack back with one narrow question in mind), and decided what to act on.

Built an app and put it on your own phone, where you opened it and used it.

Scored four finished apps against your own criteria, then said out loud how it all works.

Read that list again, then say one line out loud that starts with “I can”. That sentence is the only thing on this page nobody wrote for you.

If a word from these five parts has gone, WORDS.md in your project folder holds all of them.

You still cannot write code from an empty file, or read somebody else’s. Neither was the point. What you can do is say what a thing has to do, in writing, and then get it built and checked.

Every page of the playbook was written by somebody who got it wrong first. What confused you is what is still badly written. Keep the diary running, and each entry you raise is its next revision.

Your one next action Pick the next thing you want your app to do, and write down what it has to do before you ask for any of it.

End of Part 5 · Handover complete