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

Fast path: when a settled spec in docs/specs/ already covers the request, go directly to implement. Otherwise, first sharpen the request silently. Ask how a top expert would approach it: the sources, the methods, and an outside check that proves the result. An outside check is evidence from outside the work: a test runner, a live system, or an independent source. Ask what the user really wants, and whether the request says too much or too little. Drop constraints that do not serve that goal. Add only what improves the result, and do not make the work larger. Leave open each choice that belongs to the user. Do not show the user a reworded request, except the one-sentence plan below. Then find the size of the request. A request with no real decision tree is obvious. Examples are one obvious change, a small diff, or a criterion that one sentence can state. Say that the request is obvious, and go directly to implement with that sentence as the plan. The sentence keeps the outside check as its criterion. Do not write a spec for an obvious change. The fast path still tests its sentence: state the sentence, then test it. If you cannot state the sentence, or the sentence shows a decision to make, the request was not obvious. Then run the interview.

Before the first question, read the project context: code, docs, and recent commits.
Before the first question, look for CONTEXT.md at the root. Look also for CONTEXT-MAP.md and each CONTEXT.md that it lists. Look for ADRs under docs/adr/, also for ADRs that apply to one context only.
On a nontrivial codebase with no CONTEXT.md, offer to collect candidate terms from the code and the docs. Put each term to the user during the interview. A term goes into the glossary only after the user confirms it.
If the request holds several independent parts, say so. Drill the first part, and keep the other parts for later.
Before you choose a direction, show 2 or 3 different approaches with their trade-offs, not variations of one approach. Put your recommendation first, as exhaust the design space says. When a new requirement comes into an existing design, one approach is the redesign from first principles. Check each architectural shape against the design red flags. Some decisions depend on look, feel, or flow that text cannot settle. For these, run the prototype skill to build a throwaway that the user reacts to. Discard it when the user picks the direction.
The session ends when every branch of the decision tree is resolved. Then state the settled design in a short summary. Get the explicit agreement of the user before any implementation starts.
When the settled design is implementation work, write the spec to docs/specs/<slug>.md in the target project. Use spec-format.md: goal, non-goals, checkable acceptance criteria, verification commands, and phases for a phased migration. Put the outside check from the fast path into the verification commands.
Sometimes this session cannot resolve the decision tree. Decisions can wait for research outside this context, or the tree can be too large for one session. Then do not write a settled spec for a design that is not settled. Write the spec as a draft: draft-spec.md.

Rules:

drill