Run the core-interview skill against the plan or design under discussion. The interview also tests the plan against the project's domain model.

Fast path: first, size the ask. If it has no real decision tree (one obvious change, a small diff, a criterion statable in one sentence), say so and route straight to implement with that sentence as the plan; a spec for an obvious change is ceremony. The fast path still drills its sentence: state it, then test it. A sentence that cannot be stated, or that surfaces a fork or a second decision, was not obvious: run the interview. A genuine fork discovered mid-task is never guessed: stop, name it, let the user answer. If verify fails twice on a task judged obvious, the task was lying about its size: stop and drill it properly.

Explore the project context before the first question: code, docs, recent commits.
Before the first question, look for CONTEXT.md at the root (or CONTEXT-MAP.md and the per-context CONTEXT.md files it lists) and for ADRs under docs/adr/, including any scoped to one context.
First contact: on a nontrivial codebase with no CONTEXT.md, offer one seeding pass: collect candidate terms from the code and the existing docs, then put each to the user during the interview. A term enters the glossary only after the user confirms it.
If the ask bundles several independent pieces, say so and drill the first piece; the rest queue up.
Before settling a direction, put 2 or 3 genuinely different approaches on the table with trade-offs, leading with a recommendation, per exhaust the design space; when a new requirement lands in an existing design, one of them is the redesign from first principles. Screen each architectural shape against design red flags. When a fork turns on look, feel, or flow that prose can't settle, run the prototype skill to build a throwaway to react to, and discard it once the direction is picked.
The session ends when every branch of the decision tree is resolved: state the settled design in a short summary and get explicit agreement before any implementation starts.
When the settled design is implementation work, write the spec to docs/specs/<slug>.md in the target project using spec-format.md: goal, non-goals, checkable acceptance criteria, verification commands, and phases for a phased migration. The spec steers the loop: implement builds from it, verify gates against it, land closes it out and asks whether to keep or delete the file.
When the decision tree cannot resolve here (decisions await research beyond this context, or the tree is simply too large for one session), do not force a settled spec out of an unsettled design. Write the spec as a draft instead: draft-spec.md.