Kick Off

Workspace

Run scripts/check-kiko with the opened project root's absolute path as its only argument, and use the returned path as KIKO_ROOT. On exit 3, ask the user to run the setup-kiko skill at the project root, then retry. On any other nonzero exit, report the error and stop. Do not initialize or repair .kiko, and suggest no substitute for setup-kiko.

Cut and pick

Take the request the user brings, which may be empty, together with what is waiting in $KIKO_ROOT/TODO.md as one whole, and cut it vertically into outcomes that are each verifiable on their own: a narrow but complete path through every layer it touches, never one layer of the whole. An outcome waits on the outcomes without which it cannot be delivered and accepted, and on no others; importance never overrides a dependency.

Importance is the mark an outcome carries: [P0] for what must ship for the work to count, [P1] for what must follow, [P2] for what can wait. An outcome inherits the highest mark among the outcomes that wait on it. Propose a mark for every outcome that has none.

Show the user the outcomes in the shape $KIKO_ROOT/TODO.md takes:

# TODO

## Outcomes

- <id> [P0] <outcome>
- <id> [P1] <outcome>
- <id> [P2] <outcome>

## Dependencies

<id> → <id> → <id>
<id> → <id>
<id>

One chain per line, an arrow from an outcome to what waits on it; an outcome on more than one chain appears on each of them, and an outcome on no chain stands on a line of its own.

Then pick what to build next: one or more outcomes, none waiting on anything outside the pick, the most important first, as long as together they still read as one outcome, a single fresh context can build them, and another can verify them in full. Show the pick with who it serves, what changes, and why. Ask whether the cut and the pick suit, and nothing else alongside: the user may adjust either, and a question about the work would rest on a pick that may still change.

Once the user confirms, create the record per references/records.md, and rewrite $KIKO_ROOT/TODO.md as the cut the user confirmed, in the same shape with the ids the user saw, and nothing else. From here on the outcome is what the user picked, and the interview covers only it.

Interview

Interview the user until every decision is settled. Model the work as a design tree: a decision's prerequisites are the upstream decisions and environment facts its options depend on, and its answer opens the decisions below it.

The frontier is every unsettled decision whose prerequisites are all settled. Two frontier decisions never depend on each other, so a dependency chain settles one link per round.

Ask the user only for decisions and for facts only they can provide. A choice the implementer may not replace is a decision, whoever proposed it. Every other fact is a prerequisite you settle yourself from the environment, even one the user stated: what they say about the environment may never have been measured, and a false premise found now costs a question, found in implementation costs the build. A check that contradicts the user is a decision to put to them. While a lookup is running, its dependents stay out of the frontier.

Each round is one call of the harness's structured question tool, covering as much of the frontier as its per-call limit allows, starting with the questions that unblock the most. Without such a tool, ask in the reply with numbered options. In each question, put the recommended option first with its main reason and cost. Wait for the answers, record them and any new facts per references/records.md, update the tree, recompute the frontier, and ask the next round.

The interview ends when the frontier is empty: every decision is settled and nothing is left silently assumed. Do not act on the result until the user confirms the summary.