festival-intake

Festival Intake

This is the front door. Every other camp skill assumes the user already knows what a festival is. This one does not, and it must fire before they do.

When it fires, you owe the user the six steps below, in order. Do not skip straight to creating things.

Step 1: Size it out loud

Say which gear this is and why, in one line, before doing anything else. The user learns the system has three gears by watching you pick one.

Signal	Route
One file, one session, reversible	Answer in chat. Create nothing.
Linear, a handful of steps, one repo	fest create workflow <name>
Multi-phase, multi-repo, needs review gates, or outlives a session	fest create festival

Most requests are the first row. Reaching for a festival on small work is a failure mode, not thoroughness. When it is genuinely between two rows, pick the smaller one and say you can promote it later.

Step 2: Show the shape, then ask

Before scaffolding anything, present the proposed phases and the sequences under each, and get a yes.

You already have everything you need to do this at that point in the conversation, so it costs nothing. It is the user's one chance to redirect before work gets written to disk, and it is what makes the rest of the run trustworthy.

Step 3: Plan through the loop, not by scaffolding

Create the festival, then drive fest next and answer what it asks.

Do not scaffold every phase and sequence up front and fill in the [REPLACE] markers afterward. That path looks faster and is the single worst thing you can do to a festival:

• Scaffolding ten sequences at once writes hundreds of unfilled markers.
• fest validate drops to 0 the moment they exist, and stays there.
• The pressure is then to fill markers with plausible filler to restore the score, which produces a green festival full of worthless tasks.

fest next walks you through planning one decision at a time and never opens that window. The loop is the planning process, not just the execution process.