The four ceremonies
the day is built around.

All three Builders project their laptop screens at the front of the room and, in parallel, walk through the cold-start setup of their Claude Code project. Each Builder narrates their own screen as they work.

Builders work in parallel — not in lockstep. They start at the same `mkdir` moment, but each one is going through their own chosen tooling for whatever spec they're building. The variation is the point. Non-builders see that there is not one right way; they see three experienced people making three different defensible choices in real time.

Open Claude Code in a fresh directory → write CLAUDE.md (the 3–5 sentences that frame the whole project) → install the 1–2 skills the build will lean on → drop in any RAG / context files → verify the deploy target with a hello-world. The deploy command is the climactic moment: three URLs or three running stacks appear at the same time.

The seventeen non-Builder participants in the room have probably never seen this. Their model of AI engineering is a black box. By 10:15 the box is open. If the day delivers nothing else, this ritual alone changes how every participant in the room thinks about what is possible.

The team's first hour together. Every role contributes from their own seat — exactly as they would on day one of a real consulting engagement.

The Product Owner walks the team through the spec end to end. The Builder evaluates feasibility, identifies the MVP slice, and names what gets cut and in what order. The Client Advocate asks the questions a real buyer would — not politely. The Market Analyst describes how they will gather competitive and pricing data. The Narrator takes a first swing at the value prop out loud, knowing it will change. The Pricing Strategist drafts a v0.1 business case so the Narrator has a number to point at by mid-morning.

A shared understanding of the spec. A locked MVP slice and a written cut list. A working agreement: where artifacts get dropped, the Builder's decide-without-me rule, when check-ins happen, what done looks like for the demo. A v0.1 value prop and a v0.1 pricing model. And a running recording of the entire conversation.

Scaffolding. The visible Kickoff Ritual already covered generic project setup. Discovery is when the Builder learns what they are actually building from the team's perspective. Spec-specific scaffolding starts at 11:15, not before.

Teams stay at their stations. Sequenced, not simultaneous. Each Builder gets exactly 60 seconds to show what is currently working — the actual app, not slides, not a pitch. The other people walk over and gather around. Then on to the next team. About 5 minutes of demos, 10 minutes of unstructured wandering before lunch starts.

Show, don't tell — only the actual app counts. Honesty over polish — if a team isn't at proof of life, the Builder says so, names what they're cutting from Sprint 2 to recover, and the room moves on. No prep allowed — the Builder demos cold from whatever state the code is in at 12:30:00.

It is a muscle-memory exercise disguised as a check-in. The skill of demoing rough work in front of peers without preparing for it is exactly the skill consultants are worst at, because we are trained to over-rehearse. Doing it once at lunch makes the 4:00 PM live demo less terrifying. It also gives slow teams a public reality check while they still have an hour and three quarters to recover.

Every participant votes. Nobody votes for their own team. Each voter picks their top team from the other two and writes a one-line reason. Picks tally to a winner. Comments become qualitative feedback the teams take home.

Each team has the floor for about 8 minutes and shares three things in front of the room: one thing that worked, one thing that surprised them, one thing they would do differently. The room hears all 9 reflections back to back, and patterns emerge that wouldn't emerge from any single team.

Each team comes to the front in turn. They make a public commitment, written on a physical index card and read aloud, in this exact format: "By [date], we are [shipping this prototype to {named owner}] OR [killing it and posting a 1-pager on why, owned by {named person}]. The owner of this commitment is [name]." The named owner is in the room. The ship date is within 60 days. The kill date is within 14 days.

It is the moment the day stops being theatre and becomes a contract. Every prototype is now publicly tied to a date and a name. The 1-pager on why-we-killed-it is, in many cases, more valuable to the firm than the prototype itself, because it captures learning the firm normally throws away. The discomfort of standing up and saying we are killing this is the muscle being trained.