Demo runbook

Ten minutes, live, on a laptop. The point is not to show that a model can write — everyone knows that. The point is to show that the output has a fixed shape, that the shape came from a rubric someone wrote deliberately, and that the skill refuses to make things up.

Before you start

1. Open a Claude project with skills/ loaded.
2. Have a real brief to hand — theirs is best. A paragraph of a job description or a product page works if they don't offer one.
3. Have examples/ open in a second window, so you can jump to a finished artifact if the room wants to see the end state rather than watch it build.

The four beats

1 — The library is cheap until it isn't (30 seconds)

"There are nine skills loaded here. At rest, only the one-line description of each is in context — about forty words a skill. The procedure, the rubric and the templates only load when a task actually matches. So the library scales without costing me anything to carry."

Show README.md, then open one SKILL.md and point at the frontmatter versus the body.

2 — Intake, live (3 minutes)

Paste their brief. Then:

Run brief-intake on this.

What to point at in the output:

• The problem restated in their words, quoted — not paraphrased.
• UNRESOLVED in the metric row. Say: *"It didn't invent a number. That's the most important thing on this screen."*
• The assumption register sorted by cost of being wrong, each with an owner.
• Exactly three questions back — not thirty.

"This file is now the context every other skill reads from. A model amplifies whatever context you hand it, so this is the only part where being slow pays."

3 — The fork (3 minutes)

"From here it splits. If the question is about a design system, that's a counting exercise — I start with artifacts. If it's about a product, it's a people exercise — I start with users. Getting this fork wrong wastes the first two weeks."

Pick whichever is closer to their world and run one:

Run ds-inventory against this repo / these screens.

Run heuristic-audit on the checkout flow. Two critical paths.

What to point at: the severity scale, and the Cost column.

"A finding without a cost is trivia, and nobody funds trivia. The fix list is sequenced by where the fix lands — one primitive often closes ten findings."

If time is short, skip running it and open examples/02-drift-report.md instead.

4 — Critique on my own work (3 minutes)

This is the beat that lands. Take something you just made — in the demo, the output from step 3 — and run:

Run critique on that audit. Attack it on all seven fronts.

"It's arguing against my own work before anyone else has to. If the output is encouraging, the skill has failed — that's written into it."

Then close:

"What I never delegate: the problem statement, talking to users, the final visual call, and anything stated as a fact. The tooling compresses the loop. It doesn't decide what the loop is for."

If they push

"Couldn't anyone do this with a good prompt?"

"For one project, yes. The difference is that the rubric is a file — versioned, improved after every engagement, and runnable by another designer who gets the same shape of output. That's the difference between a prompt and a practice."

"How do you know it isn't making things up?"

"Five house rules run through every skill. The first is never invent a number — every quantity traces to a named source or it gets cut. The second is say what you couldn't determine. You saw both fire in the intake."

"What happens when it's wrong?"

"It's wrong regularly, and confidently. Which is why nothing leaves my hands without the critique pass and my own read. The library makes the first draft fast and consistent — it doesn't make it final."

Timing