orch-setup

Orch Setup

This skill drives any of the three orch <cmd> --step interviews. All three speak the same stateless step-loop protocol (internal/question): you resubmit everything known so far on every step, and the core tells you what to do next.

State you hold

Maintain one AnswerSet across the whole interview:

{"schema_version": 2, "answers": {}}

Question wire schema_version is closed at 2 for both AnswerSet and Document; reject any other Document before reading kind, questions, or pagination. A rejected AnswerSet means the setup skill and orch binary are out of date with each other; update the older side before retrying.

Resubmit it in full on every step — the core holds no session of its own. Never send a partial or incremental update.

The step loop

1. Write the current AnswerSet to a scratch file (as orch-delivery does: OS temp, outside the repo).
2. Run orch <cmd> --step < <scratch-file> and parse the question.Document on stdout.
3. Dispatch on Document.kind:

kind: "questions"

Document.questions carries 1–4 independent Questions. If none carries pagination, present them as one batched AskUserQuestion call. If any question carries pagination, handle the document in order: ordinary questions use one-question calls and each pagination page uses one call.

For a question without pagination, use its header and prompt as the AskUserQuestion header/prompt, and list its options[] with each option's label for display and description for detail. If an option has recommended: true, say so in the description text (there is no separate "recommended" UI affordance to rely on — put it in words). If the question has a default, mention it in the description of the matching option too.

When the human answers that ordinary question, record answers[question.id] = option.value — the option's value, never its label. The label is display text only; the value is what the core expects back.