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 or switch to deep. If verify fails twice on a task judged obvious, the task was lying about its size: stop and drill it properly.

Deep mode (the deep skill is active): no sizing, no routing past the interview; the full session runs and the spec is always written.

Run the core-interview skill against the plan or design under discussion.

Shape of the session:

Explore the project context before the first question: code, docs, recent commits.
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. 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.
Cut ruthlessly: anything the stated constraints don't demand leaves the design.

Domain awareness

The interview also challenges the plan against the project's existing domain model. During exploration, look for existing documentation:

CONTEXT.md at the root (or CONTEXT-MAP.md + per-context CONTEXT.md files in a multi-context repo)
ADRs in docs/adr/ (and any context-scoped docs/adr/ directories)