Kickoff

Kickoff

The user's request is the map. The codebase and the real world are the territory. The difference between them is the user's unknowns — and when you hit one mid-task, you guess. This skill spends a little time up front so you guess less later.

The deliverable is clarity, not code. Kickoff never implements.

Language: write everything user-facing — briefings, questions, prototypes' copy, plans — in the language the user is speaking. File names and code identifiers stay in English.

Step 1 — Diagnose (quietly)

Read the request, glance at the relevant territory (code, docs, history, and working-tree state — uncommitted changes are territory too), and score the signals below. Assess silently — don't lecture the framework; the diagnosis surfaces as one line at the top of Step 2:

Signal	Evidence
Unfamiliar territory	New domain or untouched part of the codebase; user says "I've never…" / "I don't know X"
Confident assertions	Statements about the territory phrased as certainty — "it's stored in X", "nothing else calls this" — especially about code nobody has touched recently
Failed prior attempts	Reverted commits, abandoned branches, "we tried it and it broke", "the last attempt came back wrong and I don't know why"
Taste-driven criteria	Vague quality words — "clean", "modern", "feels right" — user will know it when they see it
Feasibility in doubt	Nobody knows if the approach is physically possible, accurate enough, or fast enough
Open decisions	Ambiguities where different answers produce different architectures
A reference exists	User points at (or you find) code, a library, or a site that already does it

Also collect the user's starting point if not stated — their experience with this problem and codebase, and where they are in their thinking — but ask only if the answer could change what fires; otherwise infer it from context. One short question at most; uncommitted local changes always earn it (are they intended state?).

Step 2 — Run only what fires

Open with the diagnosis in one line — name the signals that fired, the techniques you'll run, and the rough cost: "Two signals fired: unfamiliar territory, open decisions — blind spot pass on src/auth first, then a ~5-question interview." The user can veto or reorder before anything runs; they should never wonder why they're being asked things. When three or more techniques fire, quote the cost as total expected user turns and offer a lite path (premise challenge + interview + plan); fold questions into other techniques' reaction rounds rather than stacking full loops.

For each technique you run, read its reference file first and follow it:

Fires when	Technique	Read
Unfamiliar territory	Blind spot pass — brief them on the questions they didn't know to ask	references/blindspot.md
Confident assertions	Premise challenge — verify what's treated as fact against the territory, before building on it	references/challenge.md
Failed prior attempts	The wreckage is territory — blind spot pass over the failed diffs, premise challenge on the failure's framing ("it's flaky", "it broke X")	references/blindspot.md, references/challenge.md
Taste-driven criteria; feasibility or cause in doubt; an open decision whose option space is unexplored	Brainstorm, throwaway prototypes, or a feasibility/diagnostic spike — turn reactions and measurements into explicit criteria	references/brainstorm.md
A reference exists	Extract its semantics into a keep/adapt/drop checklist	references/use-reference.md
Open decisions remain	Interview — one question at a time, biggest blast radius first	references/interview.md

The listed order is a default — reorder when one technique's output is another's input: a reference's checklist feeds the brainstorm, and a premise that could invalidate the framing gets challenged before anything else. Run only the ones that fired — kickoff is a diagnosis, not a ceremony. Between techniques, keep the user in the loop with one-line status ("territory is clear, but three decisions could flip the architecture — interviewing you next").

If nothing fires: say plainly "no meaningful unknowns here — just implement", and offer to start right away — once nothing fires, kickoff is over and normal work continues in this same session. That answer is kickoff succeeding, not failing.

Step 3 — Always land on a handoff

Every kickoff that ran at least one technique lands on an artifact — the nothing-fired exit needs none; "just implement" is its handoff:

• An unknowns-first plan (read references/plan.md) if the user is heading into implementation. The plan embeds a deviation policy and instructs the implementer to keep implementation notes (read references/impl-notes.md and fold its setup into the plan's handoff section).
• A rewritten prompt if the user just wanted clarity — their original request with resolved assumptions inlined and remaining open questions flagged, ready to paste into a fresh session.
• The requested document itself, when the deliverable is a plan or doc (a migration runbook, a design doc) — the unknowns-first plan is its skeleton, and writing it is not "implementing". Adapt the section vocabulary to the domain and hand off to whoever actually executes (see plan.md's handoff).

Guardrails

• One technique at a time; each technique's output feeds the next.
• If diagnosis reveals the problem should be solved a different way altogether, say so before anything else — that's the most valuable outcome a kickoff can have.
• Simple task, familiar territory, clear spec → don't invent process. Say so and stop.