/interview

name: interview
description: "Use when the user wants to build or change something but the request is vague or open-ended: 'help me figure out what to build', 'I'm not sure what it should do', 'add X' with no details, or no clear definition of done. Runs a short Socratic interview that turns the idea into goals, constraints, and acceptance criteria before any code is written. Not for simple questions, small clear edits, or an existing Seed."
aliases: [socratic]
mcp_tool: ouroboros_interview
mcp_args:
  initial_context: "$1"
  cwd: "$CWD"

/ouroboros:interview

Socratic interview that turns a vague request into the goals, constraints, and acceptance criteria a Seed needs.

Required Skill Capabilities

• `ask_user`: ask human-judgment questions through the active runtime's `ask_user` capability.
• `inspect_code`: answer repo-local factual questions from exact local files before asking the user.
• `call_mcp`: use Ouroboros MCP tools for persistent interview state and seed generation.
• `orchestrate_subagents`: run advisory lanes and the Seed-ready Acceptance Guard lanes.
• `run_lateral_review`: invoke lateral thinking subagents before milestone turns and direct-answer synthesis.
• `web_research`: fetch current external facts only when the interview genuinely depends on them.
• `refine_answer`: confirm structured interpretations of free-text answers before forwarding them (Refine gate).
• `maintain_ledger`: keep ambiguity, gates, and unresolved decisions visible in the main session.
• `run_closure_gate`: run the Seed-ready Acceptance Guard even when MCP reports seed-ready.
• `restate_goal`: restate the goal and require explicit approval before seed generation (Restate gate).

Non-Skippable Gates

• Refine gate on free-text answers that carry scope, constraints, or decisions (step 4).
• A visible ambiguity ledger in the main session (step 6).
• MCP seed-ready (`meta.seed_ready=true`) is permission to run the Seed-ready Acceptance Guard (step 8), not completion.
• Restate gate and explicit user approval before suggesting or running seed generation (step 9).

The server names the last two `seed_ready_acceptance_guard` and `restate_goal_approved` in `required_client_gates`.

Usage

ooo interview [topic]
/ouroboros:interview [topic]

The topic is the skill arguments, or the user's own request when there are none. Start from it at once; do not ask for the topic again or explain Ouroboros first. Updates are checked in the background; if your context carries an Ouroboros update notice, mention `ooo update` once after the first question.

Loading MCP tools (deferred-schema guard)

Ouroboros tools may be deferred, and a schema loaded on one turn can unload by the next. Immediately before each `ouroboros_*` call, load it with the active runtime's tool-discovery capability: `"+ouroboros interview"` for `ouroboros_interview`; `"+ouroboros lateral"` for `ouroboros_lateral_think`. A call whose schema is not loaded fails with "Invalid tool parameters". If the tool is already callable, discovery is a no-op and an empty result is expected. Use the fallback only when the tool is genuinely absent.

If `ouroboros_interview` is callable, use Path A. Use Path B only when it is genuinely absent (no Ouroboros MCP server).

Interview language calibration

Before asking or relaying the first question, look in the current conversation for the most recent `Interview calibration` produced by `ooo idk`. If present, apply it to all user-facing interview prose:

• **Foundational**: use plain language, define necessary terms before using

them, and add one neutral concrete example when it helps.

• **Working**: use standard terminology and briefly define only new or

overloaded terms; frame questions around practical trade-offs.

• **Fluent**: use precise domain terminology and concise trade-off language.

Use one overall explanation level plus explicitly unknown terms. Do not infer low general ability from an unknown English term, typo, or terse answer. Adapt vocabulary, sentence structure, context, and example depth only; preserve the original question's decision, constraints, acceptance meaning, and all interview gates. If the previous `ooo idk` or `ooo interview` response included `meta.interview_calibration`, pass it to the next `ouroboros_interview` MCP call as the `interview_calibration` argument.

If the user says they do not know a word or invokes `ooo idk` while a question is pending, do not forward that statement to MCP as the answer. Explain the term at the calibrated level, update the provisional calibration when warranted, rephrase the same question without steering the decision, and wait for the user's actual answer. The active calibration lives only in the current conversation unless the user supplies it again.

Path A: MCP Mode

MCP generates the questions, keeps state, and scores ambiguity; it cannot read code, browse, or call tools. You (the main session) answer what code or research can answer and route to the user only what needs human judgment: goals, acceptance criteria, business logic, preferences. You never decide for the user; auto-confirm is for facts only.

1. **Start the interview.**

   Tool: ouroboros_interview
   Arguments:
     initial_context: <user's topic or idea>
     cwd: <current working directory>
     confused_terms: <optional explicit terms the user does not understand>
     references: <optional [{reference_id, label, origin, url?, excerpt?}]>

Returns a session ID and the first question. `confused_terms` and `references` are structured adapter context, not requirements. They MUST NOT alter the first question; later, glossary help covers only explicitly confused terms and references serve only contrast questions. Do not infer them from vocabulary density or fetch referenced URLs/files. On a later answer, include them only when the user introduces a new reference or asks what a term means; product decisions stay in the answer.

For