# Interview

> Socratic interview to crystallize vague requirements

- Skill: `q00/interview` (Agent Skill)
- Install (CLI): `npx skillmds@latest add q00/interview`
- Raw SKILL.md: https://api.skillmd.com/api/skills/q00/interview/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Q00 (https://skillmd.com/u/q00)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/q00/interview

---


# /ouroboros:interview

Socratic interview to crystallize vague requirements into clear specifications.


## Required Skill Capabilities

- `ask_user` — ask human-judgment questions through the active runtime's user-question surface.
- `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.
- `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.
- `run_shell` — run bounded local commands for version checks and repository inspection.
- `refine_answer` — confirm structured interpretations of free-text answers before forwarding them.
- `maintain_ledger` — keep ambiguity, gates, and unresolved decisions visible in the main session.
- `run_closure_gate` — audit readiness locally even when MCP reports `seed-ready`.
- `restate_goal` — restate the goal and require explicit approval before seed generation.

## Non-Skippable Gates

- Refine free-text answers that carry scope, constraints, or decisions.
- Maintain a visible ambiguity ledger in the main session.
- Treat MCP `seed-ready` as permission to audit closure, not as completion.
- Apply Seed Closer criteria before suggesting or running seed generation.
- Run the Restate gate before seed generation.
- Require explicit user approval before suggesting or running seed generation.

## Usage

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

**Trigger keywords:** "interview me", "clarify requirements"

## Instructions

When the user invokes this skill:

### Step 0: Version Check (runs before interview)

Before starting the interview, check if a newer version is available:

```bash
# Fetch latest release tag from GitHub (timeout 3s to avoid blocking)
curl -s --max-time 3 https://api.github.com/repos/Q00/ouroboros/releases/latest | grep -o '"tag_name": "[^"]*"' | head -1
```

Compare the result with the current version in the active runtime's local plugin metadata (for Claude installs this is `.claude-plugin/plugin.json`).
- If a newer version exists, ask the user through the active runtime's `ask_user` capability:
  ```json
  {
    "questions": [{
      "question": "Ouroboros <latest> is available (current: <local>). Update before starting?",
      "header": "Update",
      "options": [
        {"label": "Update now", "description": "Update plugin to latest version (restart required to apply)"},
        {"label": "Skip, start interview", "description": "Continue with current version"}
      ],
      "multiSelect": false
    }]
  }
  ```
  - If "Update now":
    - On Claude-plugin installs only:
      1. Run `claude plugin marketplace update ouroboros` via the active runtime's `run_shell` capability (refresh marketplace index). If this fails, tell the user "⚠️ Marketplace refresh failed, continuing…" and proceed.
      2. Run `claude plugin update ouroboros@ouroboros` via the active runtime's `run_shell` capability (update plugin/skills). If this fails, inform the user and stop — do NOT proceed to the package-manager step.
    - On non-Claude runtimes, skip Claude plugin commands and proceed directly to the package-manager step for `ouroboros-ai`; do not require Claude-only commands or tools.
    3. Detect the user's Python package manager and upgrade the MCP server:
       - Check which tool installed `ouroboros-ai` by running these in order:
         - `uv tool list 2>/dev/null | grep "^ouroboros-ai "` → if found, use `uv tool upgrade ouroboros-ai`
         - `pipx list 2>/dev/null | grep "^  ouroboros-ai "` → if found, use `pipx upgrade ouroboros-ai`
         - Otherwise, print: "Also upgrade the MCP server: `pip install --upgrade ouroboros-ai`" (do NOT run pip automatically)
    4. Tell the user: "Updated! Restart your session to apply, then run `ooo interview` again."
  - If "Skip": proceed immediately.
- If versions match, the check fails (network error, timeout, rate limit 403/429), or parsing fails/returns empty: **silently skip** and proceed.

Then choose the execution path:

### Step 0.5: Load MCP Tools (Required before Path A/B decision)

The Ouroboros MCP tools are often registered as **deferred tools** that must be explicitly loaded before use. **You MUST perform this step before deciding between Path A and Path B.**

1. Use the active runtime's tool-discovery capability to find and load the interview MCP tool:
   ```
   tool discovery query: "+ouroboros interview"
   ```
   This searches for tools with "ouroboros" in the name related to "interview".

2. The tool will typically be named `mcp__plugin_ouroboros_ouroboros__ouroboros_interview` (with a plugin prefix). After runtime tool discovery returns, the tool becomes callable.

3. If the tool is callable — already exposed, or loaded by discovery — proceed to **Path A**.
   An empty discovery result for an already-exposed tool is expected, not a failure.
   Proceed to **Path B** only if the tool is genuinely absent (no Ouroboros MCP server).

**IMPORTANT**: Do NOT skip this step. Do NOT assume MCP tools are unavailable just because they don't appear in your immediate tool list. They are almost always available as deferred tools that need to be loaded first.

**CRITICAL — deferred-schema guard (prevents "Invalid tool parameters"):**
This skill makes `ouroboros_*` MCP calls across multiple turns, and each turn runs
in a fresh tool context. A deferred tool's schema loaded on one turn is NOT
guaranteed to still be loaded on the next. If you call any `ouroboros_*` MCP tool
while its schema is not loaded in the **current** turn, the runtime rejects the
call with **"Invalid tool parameters"** before it ever reaches the server.
Therefore: **immediately before EVERY `ouroboros_*` MCP call in this skill, re-run
the tool-discovery load query for the specific MCP tool you are about to call**
(idempotent — a no-op when the schema is already loaded) so the correct schema is
guaranteed present for that call. Use `"+ouroboros interview"` before
`ouroboros_interview` and `"+ouroboros lateral"` before
`ouroboros_lateral_think`. If a load ever returns no matching tool (and the tool is not already callable — an empty load for an already-exposed tool is an expected no-op, not absence), switch to the
documented fallback / Path B instead of retrying the failing call.

### Path A: MCP Mode (Preferred)

If the `ouroboros_interview` MCP tool is available (loaded via runtime tool discovery above), use it for persistent, structured interviews.

**Architecture**: MCP is a pure question generator. You (the main session) are the answerer and router.

```
MCP (question generator) ←→ You (answerer + router) ←→ User (human judgment only)
```

**Role split**:
- **MCP**: Generates Socratic questions, manages interview state, scores ambiguity. Does NOT read code.
- **You (main session)**: Receives MCP questions, answers them by reading code through the active runtime's `inspect_code` capability, or routes to the user when human judgment is needed.
- **User**: Only answers questions that require human decisions (goals, acceptance criteria, business logic, preferences).

#### Interview Flow

1. **Start a new 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 are queued on the start call and MUST NOT alter the first
   question. On later turns, glossary help is limited to explicitly confused
   terms and references are used only for contrast questions. Do not infer these
   arguments from vocabulary density or fetch referenced URLs/files.

2. **For each question from MCP, apply the routing paths below:**

   **Parent-session question handoff**:
   If an MCP response includes `meta.status="parent_question_required"` or
   `meta.ask_user_directly=true`, treat it as a normal interview continuation,
   not as an MCP/provider/tool failure. Do **not** tell the user MCP failed, do
   not expose `reason_code`, and do not retry the MCP question generator. Ask
   exactly one natural Socratic clarification question yourself, using the same
   routing judgement as any other interview turn. Save the exact user-facing
   question text. When the user answers, call:
   ```
   Tool: ouroboros_interview
   Arguments:
     session_id: <meta.session_id>
     answer: <user answer>
     last_question: <exact question you asked the user>
   ```
   `last_question` is required on this path so MCP can persist the real
   transcript even though the parent session generated the question.

   **Question-first advisory fanout**:
   If an MCP response includes `meta.question_advisory_request`, show the
   interview question to the user first, then use the advisory request as a
   parent-session assist layer. The advisory exists to help the human answer;
   it must not hide, replace, or delay the question itself.

   Read the stamped dispatch contract before running the lanes. With
   `dispatch_mode="host_driven"`, use the declared native parallel mechanism.
   With `dispatch_mode="host_decides"`, use native parallel fan-out when the
   current host exposes it and otherwise process the same payloads sequentially.
   With `dispatch_mode="sequential"`, process payloads in order. For Claude Code
   the parallel mechanism is Task/Agent; for Codex, explicitly start one native
   subagent per payload in a single fan-out turn. Wait for every result, then
   synthesize. The standard lanes are:
   - `code_context` — inspect repo-local facts and reuse
     `meta.code_investigation_request` when present.
   - `web_context` — browse/search only when current external facts genuinely
     affect the answer.
   - `data_context` — take the measurements that inform the question.
     This lane takes the measurement; see "Data measurements" below.
   - `ambiguity_contrarian` — find hidden assumptions, vague terms, missing
     decisions, and risky defaults.
   - `answer_simplifier` — turn the question into 2-3 easy choices or one
     concise draft answer.
   - `architecture_implications` — check whether the answer changes ownership,
     interfaces, rollout, or system shape.

   Synthesize advisory results into a compact helper for the user: 2-3 answer
   options, one recommended draft, or a short "I found these ambiguities" note.
   Do not forward advisory output to `ouroboros_interview` until the user
   approves, edits, or explicitly asks you to auto-confirm a safe answer.
   When `meta.question_advisory_subagents` is present you MUST process every
   payload: treat each entry as spawn-ready advisory work with `title`, `agent`,
   `prompt`, and `context`, and pass its prompt unchanged. Obey
   `meta.question_advisory_host_action`: `spawn_subagents` means parallel support
   was declared; `dispatch_subagents_if_supported` means use native parallel
   dispatch when available and sequential fallback otherwise;
   `process_payloads_sequentially` means ordered processing is required. This is
   required regardless of mode—the payloads themselves are the work contract,
   while the host action selects the execution strategy. Never reconstruct
   prompts from prose. Preserve the original question text while children run.

   **Submitting fan-out results back (re-entry)**:
   When the originating `meta` carries a `fanout_id` (e.g.
   `meta.question_advisory_fanout_id`, or a `fanout_id` in a lateral persona
   panel dispatch), after all advisory/persona subagents return, call
   `ouroboros_submit_fanout_results` with:
   - `session_id`: the session the fan-out was issued under. Required whenever
     the producer ran with one — an omitted session is refused rather than
     waived, because this is what binds a submission to its owner. Contracted
     lanes assert no session of their own; this argument is the binding.
   - `fanout_id`: the stamped id from that meta,
   - `correlation_key`: the stamped `result_correlation_key`
     (`context.lane_id`, `context.persona`, or `code_facts`). Omitting it is
     refused the same way whenever the fan-out recorded one — send back what the
     meta stamped rather than leaving it out,
   - `results`: one `{ "key": <correlation value>, "content": <child output> }`
     per subagent, where `key` is that child's correlation value (its lane id,
     persona, or `code_facts`).
   Every result must be either `{ "key": <lane>, "content": ... }` or exactly
   `{ "key": <lane>, "undispatched": true }` — the literal `true`, no `content`
   beside it, and never an entry carrying neither. One entry per lane: a lane
   reported twice is two statements about it, and nothing here picks between
   them by list position. Anything else comes back as
   `status="invalid_result_entry"` with `invalid_keys`, listing every bad entry
   at once so one resubmission fixes them all.

   A complete set returns a bounded artifact envelope. Call
   `ouroboros_fetch_artifact` with its `contract_id`, then continue from the
   correlated synthesis in the fetched `body`. This explicit MCP fetch is
   required even when the host has no shell. A partial
   set returns `status="partial"` with `missing_required_keys`. **Retry with
   every lane you hold, not only the missing ones** — no submitted output is
   kept between calls, so each call is judged on what it carries. (The record
   stores only what was *asked*; retaining what children *answered* is durable
   result state, deferred with its sanitization duties to a later slice.)
   Sequential hosts submit after processing payloads one-by-one — same tool,
   same contract, so accumulate the outputs on your side and send the growing
   set. Continue the interview from the fetched synthesis; keep the
   user-facing question visible throughout.

   Only lanes marked `required: true` in the request block completion. A lane
   you ran that had nothing to say still submits its output — that is an answer.
   A lane you could **not spawn at all** (no capability for it, the child died,
   the user cancelled it) is submitted as
   `{ "key": <lane id>, "undispatched": true }`. Never invent output for a lane
   you did not run: a fabricated finding is worse than a missing one, and this
   is exactly why the declaration exists.

   **Data measurements**:
   The `data_context` lane discovers what data tools this host exposes, takes
   the measurement itself, and returns the aggregate it read.
   You do not confirm anything before it runs and you do not run anything after
   — it has already happened by the time you read the result. There is nothing
   to approve because the approval already exists: the user registered these
   tools, and registering one is the willingness to have it called. That is the
   standing every other advisory lane runs on, and this lane was the only one
   asked to hold a line in prose that its siblings did not.

   When its output carries measurements:
   - Show the numbers **beside** the question as material for the user's
     judgment. They are never the answer. The user answers in their own words
     on the ordinary `[from-user]` path; there is no `[from-data]` answer to
     forward. This is now the whole of the boundary: the lane carries real
     values, so the only thing standing between a measurement and the Seed is
     that you put it next to the question instead of into the answer.
   - Carry the aggregate as the lane reported it, with its `metric` and the
     decision it informs. Do not re-derive, re-scale, or combine numbers across
     measurements; you did not run the read and cannot know what would survive
     the arithmetic.
   - If the user has already answered the question by the time the measurement
     arrives, drop it. Do not re-open a decision the user has made, and do not
     present the numbers as a reason to reconsider — evidence informs a
     decision, it does not revisit one.

   When `data_needed` is false the lane looked and found nothing to measure.
   Every reason it can give is a statement about the lane, never about the
   user's infrastructure — a subagent sees what reached it, not what is
   connected, so it is not positioned to tell anyone a data path is missing.
   Read them accordingly:
   - `not_a_measurement` / `question_too_ambiguous_to_measure` — about the
     question. Nothing to relay beyond moving on.
   - `answer_would_not_be_an_aggregate` — about the shape of the answer.
   - `no_data_store_described` — nothing the lane was shown holds this answer.
     Worth mentioning only if you know the store exists and the lane was not
     told about it; otherwise it is ordinary.
   - `store_described_but_not_callable` — **this one is yours to handle, not
     the user's to hear.** A store exists and the child could not reach it. You
     see the environment and it does not: check whether the tool is available to
     you, take the read yourself, or re-dispatch the lane. Do not surface it as
     a missing data path. This constant exists because its predecessor was
     relayed to a user as a fact about their own infrastructure while the store
     in question sat described in the child's prompt.

   `no_evidence_reason` is one of a fixed set of constants, so say it in your
   own words rather than pasting the constant.

   What this lane can reach is not classified by anyone. The child names the
   tool it used; it cannot prove that tool was read-only, and MCP carries no
   cost or mutation metadata for you to check against. That risk is accepted
   knowingly and is the same one the sibling advisory lanes already run under.
   Do not manufacture a disclaimer about it: a warning attached to every
   measurement is one users learn to click through, and it would be
   describing a check nothing performed.

   **Milestone lateral-review dispatch**:
   If an MCP response includes `meta.lateral_review_recommended=true`, treat it
   as a required lightweight subagent review for that turn. The interview just
   crossed an ambiguity milestone such as `initial -> progress`,
   `progress -> refined`, or `refined -> ready`, which is exactly when hidden
   assumptions tend to matter.

   After showing the returned question to the user:
   - Tell the user briefly that a few perspectives are checking the question.
   - Call `ouroboros_lateral_think` with `meta.lateral_review_tool_args` when
     present. If only the legacy advisory fields are present, call it with
     `personas=["researcher","contrarian","simplifier"]`, a problem context
     containing the current interview session/milestone/question, and a current
     approach describing the next interview-routing decision.
   - Fold only concrete, user-safe findings into the next answer or user
     question. Do not present every subagent note as a report.
   - If lateral tooling is unavailable, continue the interview and say the
     review could not be run; do not restart the interview.

   The MCP interview tool is still the question generator and source of
   persistent state. Lateral review is a main-session assist layer: it helps the
   user feel supported, but it does not by itself change requirements or mark the
   interview complete.

   **Main-session direct-answer assistance**:
   Use lateral review frequently when the main session would otherwise answer
   the MCP question directly or compress the user's free-text into a decision.
   This is the supported "deep research style" experience for interviews: the
   user should see that multiple perspectives are helping, while the final
   prompt stays easy to answer.

   Trigger a lightweight `ouroboros_lateral_think` call before continuing when
   any of these are true:
   - You are about to synthesize a product/UX/architecture answer from partial
     user input.
   - The question asks for tradeoffs, priorities, non-goals, risk, success
     criteria, or rollout strategy.
   - The factual code answer is lower confidence than an exact config/manifest
     match.
   - The user seems busy, uncertain, terse, or likely to benefit from selectable
     options instead of another open-ended question.

   Prefer `personas=["researcher","contrarian","simplifier"]` for this
   assist. Add `architect` when the answer changes system shape or ownership.
   Summarize the result as 2-3 concrete options or one recommended answer draft,
   then let the user approve, tweak, or switch to auto.

   **PATH 1 — Code Answer** (describe current state from codebase):
   When the question asks about existing tech stack, frameworks, dependencies,
   current patterns, architecture, or file structure:
   - Use the active runtime's `inspect_code` capability to find the factual answer
   - **Description, not prescription**: "The project uses JWT" is fact.
     "The new feature should also use JWT" is a DECISION — route to PATH 2.
   - Evaluate confidence and choose sub-path:

   **PATH 1a — Auto-confirm** (high-confidence factual, no user block):
   When ALL of the following are true:
   - The answer is found as an **exact match** in a manifest or config file
     (e.g., `pyproject.toml`, `package.json`, `Dockerfile`, `go.mod`, `.env.example`)
   - The answer is **purely descriptive** — it describes what exists, not what
     the new feature should do
   - There is **no ambiguity** — a single, clear answer (not multiple candidates)

   Then:
   - Send the answer to MCP immediately with `[from-code][auto-confirmed]` prefix
   - Display a brief notification to the user (do NOT block):
     `"ℹ️ Auto-confirmed: Python 3.12, FastAPI framework (pyproject.toml)"`
   - The user can correct at any time by saying "that's wrong" — re-send correction to MCP
   - Increment the auto-confirm counter (see Dialectic Rhythm Guard below)

   Examples of auto-confirmable facts:
   - Programming language (from pyproject.toml, package.json, go.mod)
   - Framework (from dependencies in manifest)
   - Python/Node version (from config files)
   - Package manager (from lock files present)
   - CI/CD tool (from .github/workflows/, Jenkinsfile, etc.)

   **PATH 1b — Code Confirmation** (medium/low confidence, user confirms):
   When the codebase has relevant information but confidence is not high enough
   for auto-confirm (inferred from patterns, multiple candidates, or no manifest match):
   - Present findings to user as a **confirmation question** through the active runtime's `ask_user` capability:
     ```json
     {
       "questions": [{
         "question": "MCP asks: What auth method does the project use?\n\nI found: JWT-based auth in src/auth/jwt.py\n\nIs this correct?",
         "header": "Q<N> — Code Confirmation",
         "options": [
           {"label": "Yes, correct", "description": "Use this as the answer"},
           {"label": "No, let me correct", "description": "I'll provide the right answer"}
         ],
         "multiSelect": false
       }]
     }
     ```
   - Prefix answer with `[from-code]` when sending to MCP
   - If the user picks "Yes, correct", send the concise factual answer with
     `[from-code]` and do not apply the Refine gate. Increment the
     auto-confirm counter (see Dialectic Rhythm Guard below).
   - If the user picks "No, let me correct", immediately use the `ask_user` capability to collect the corrected answer as free text:
     ```json
     {
       "questions": [{
         "question": "What should I send instead for this MCP question?\n\nMCP asks: What auth method does the project use?\n\nInclude any reasoning, constraints, or scope that should be preserved.",
         "header": "Q<N> — Correction"
       }]
     }
     ```
   - Route the correction text through the Refine gate before sending it to
     MCP. Send the multi-section payload with `[from-user][refined]` (the
     human is now the source of the corrected answer).
   - If the user supplies a correction directly without using the option, treat
     that free text the same way: Refine first, then send with
     `[from-user][refined]`.
   - Reset the Dialectic Rhythm Guard counter to 0 because the corrected
     answer is direct user judgment, even though it was initiated from a code
     or research confirmation path.

   **PATH 2 — Human Judgment** (decisions only humans can make):
   When the question asks about goals, vision, acceptance criteria, business logic,
   preferences, tradeoffs, scope, or desired behavior for NEW features:
   - Present question directly to user through the active runtime's `ask_user` capability with suggested options
   - Prefix answer with `[from-user]` when sending to MCP

   **PATH 3 — Code + Judgment** (facts exist but interpretation needed):
   When code contains relevant facts BUT the question also requires judgment
   (e.g., "I see a saga pattern in orders/. Should payments use the same?"):
   - Use the active runtime's `inspect_code` capability to read relevant code first
   - Present BOTH the code findings AND the question to user
   - If any part of the question requires judgment, route the ENTIRE question to user
   - Prefix answer with `[from-user]` (human made the decision)

   **PATH 4 — Research Interlude** (external knowledge needed):
   When the question asks about third-party APIs, pricing models, library
   capabilities, version compatibility, security advisories, or industry
   standards that are NOT answerable from the local codebase:
   - Use the active runtime's `web_research` capability to gather external information
   - Present findings to user as a **confirmation question** through the active runtime's `ask_user` capability
     (same pattern as PATH 1, but with web sources instead of code):
     ```json
     {
       "questions": [{
         "question": "MCP asks: What rate limits does the Stripe API have?\n\nI found: Stripe allows 100 read ops/sec and 25 write ops/sec in live mode.\n\nIs this correct?",
         "header": "Q<N> — Research Confirmation",
         "options": [
           {"label": "Yes, correct", "description": "Use this as the answer"},
           {"label": "No, let me correct", "description": "I'll provide the right answer"}
         ],
         "multiSelect": false
       }]
     }
     ```
   - Prefix answer with `[from-research]` when sending to MCP
   - If the user picks "Yes, correct", send the concise factual answer with
     `[from-research]` and do not apply the Refine gate. Increment the
     auto-confirm counter (see Dialectic Rhythm Guard below).
   - If the user picks "No, let me correct", immediately use the `ask_user` capability to collect the corrected answer as free text:
     ```json
     {
       "questions": [{
         "question": "What should I send instead for this MCP question?\n\nMCP asks: What rate limits does the Stripe API have?\n\nInclude any source correction, reasoning, constraints, or scope that should be preserved.",
         "header": "Q<N> — Research Correction"
       }]
     }
     ```
   - Route the correction text through the Refine gate before sending it to
     MCP. Send the multi-section payload with `[from-user][refined]` (the
     human is now the source of the corrected answer).
   - If the user supplies a correction directly without using the option, treat
     that free text the same way: Refine first, then send with
     `[from-user][refined]`.
   - Reset the Dialectic Rhythm Guard counter to 0 because the corrected
     answer is direct user judgment, even though it was initiated from a code
     or research confirmation path.
   - **Facts, not decisions**: "Stripe rate limit is 100 req/s" is research.
     "We should use Stripe" is a DECISION — route to PATH 2.

   **When in doubt, use PATH 2.** It's safer to ask the user than to guess.

3. **Send the answer back to MCP**:

   When the user explicitly introduces a new reference or asks what a domain
   term means, include the matching `references` or `confused_terms` argument on
   that call. Do not put product decisions into glossary/reference fields; keep
   those decisions in the user answer.

   **Payload format — preserve the user's reasoning, do NOT compress to one line.**
   MCP cannot read code, browse the web, or call tools. The text you send is
   the only context MCP has when generating the next question. A one-line
   answer collapses the user's reasoning, constraints, and scope decisions
   into a label, which degrades both the next question's quality and the
   ambiguity scoring. Send the user's full reasoning, structured.

   Single-line answers are OK only for **PATH 1a auto-confirmed facts**,
   **PATH 1b / PATH 4 pre-built option confirmations** where the factual
   answer is already explicit, and short PATH 2 answers that have no reasoning
   or constraints attached (e.g., "Yes" / "No" / "Python 3.12"). User
   corrections, free-text reasoning, constraints, or scope decisions must be
   sent as the multi-section payload below after the Refine gate.

   ```
   Tool: ouroboros_interview
   Arguments:
     session_id: <session ID>
     answer: |
       [from-user][refined]
       Decision: Stripe Billing.

       Reasoning:
       - Subscription is the core business model.
       - Stripe bundles invoice/dunning/tax — avoids building those.

       Constraints (user-stated):
       - 30% Korean MAU, KRW required.
       - Revenue recognition automation OUT OF SCOPE this quarter.

       Out of scope (user-stated):
       - Refund policy changes, tax-invoice issuance.

       Codebase context (main session verified):
       - src/billing/ does not exist yet.
       - src/payments/toss_adapter.py is one-shot KRW only.
   ```

   Short-answer cases (single-line OK):
   ```
   "[from-code][auto-confirmed] Python 3.12, FastAPI (pyproject.toml)"
   "[from-code] JWT-based auth in src/auth/jwt.py"
   "[from-research] Stripe allows 100 read ops/sec and 25 write ops/sec in live mode"
   "[from-user] Yes"
   ```

   Append `[refined]` to an existing valid prefix (`[from-code]`,
   `[from-user]`, or `[from-research]`) only when the answer has been through
   the Refine gate (see Step 4). MCP records the answer, generates the next
   question, and returns it.

4. **Refine before forwarding** (free-text answers only):

   When the user gives a free-text answer that carries reasoning, constraints,
   or scope decisions, do NOT forward it to MCP unmodified and do NOT compress
   it to a label. Structure it into the multi-section payload above, then ask
   the user a single `ask_user` capability to confirm nothing is lost:

   ```json
   {
     "questions": [{
       "question": "I structured your answer as follows before sending it to MCP:\n\n<multi-section payload>\n\nIs anything missing or misrepresented?",
       "header": "Refine — preserve the structure of your answer",
       "options": [
         {"label": "Send as-is", "description": "The structure captures my answer faithfully"},
         {"label": "Add to Constraints", "description": "I want to add a constraint I forgot"},
         {"label": "Add to Out of scope", "description": "I want to mark something explicitly out of scope"},
         {"label": "Add context", "description": "I want to add reasoning, code context, or research context"},
         {"label": "Rewrite", "description": "Let me re-state the answer"}
       ],
       "multiSelect": false
     }]
   }
   ```

   The Refine gate replaces "compress to one line" with "preserve the user's
   reasoning, surface anything missing." It is skipped for:
   - PATH 1a auto-confirmed facts
   - PATH 1b / PATH 4 confirmation answers where the user picked a pre-built
     option (the structure is already explicit)
   - Short PATH 2 answers (e.g., "Yes" / single proper noun) with no
     reasoning attached

   **Exception — Restate corrections never skip Refine, regardless of length.**
   Any free-text follow-up collected by the Step 9 Restate gate
   ("Adjust wording" / "Missing scope") must go through Refine before being
   forwarded to MCP. Even a short correction like
   `"Exclude retry scheduling from the seed."` carries scope/boundary
   information that MCP needs in structured form during the reopen call, so
   the short-PATH-2 exemption above does NOT apply to Restate corrections.
   A single-line Restate correction that bypasses Refine would forward
   `[from-user]` instead of `[from-user][refined]` and would not trigger the
   `last_question` reopen, leaving MCP on stale pre-correction state when
   the seed is generated.

   Refine-passed answers count as direct user judgment — they reset the
   Dialectic Rhythm Guard counter to 0 (see below).

   If the user picks "Add to Constraints", "Add to Out of scope", "Add context",
   or "Rewrite", do not infer the missing text from the option label. Immediately
   use the `ask_user` capability for one follow-up to collect the exact text:
   ```json
   {
     "questions": [{
       "question": "What text should I add or change before sending this to MCP?\n\nCurrent structured answer:\n\n<multi-section payload>",
       "header": "Refine — Missing Text"
     }]
   }
   ```
   Apply the follow-up text to the structured payload, then ask the Refine gate
   once more. Do not send the payload to MCP while the user is still telling
   you that required text is missing or the answer should be rewritten. If the
   second Refine response again says "Add to Constraints", "Add to Out of
   scope", "Add context", or "Rewrite", ask a targeted PATH 2 follow-up for the
   exact missing text and withhold the MCP answer until the user either
   supplies that text or explicitly accepts the structured payload. The
   `Add context` option is handled identically to the other three on the
   second pass — never infer omitted content from the option label, and prefer
   stopping over forwarding a payload the user has identified as incomplete.

5. **Mark the answer as Refine-passed**:
   Append `[refined]` to the prefix when sending the structured payload to
   MCP (e.g., `[from-user][refined]`). MCP treats refined answers as
   high-confidence ground truth for ambiguity scoring.
   When the refined answer explicitly closes the interview, add the language-independent
   `[closure]` marker: `[from-user][refined][closure]`. Do not encode closure by
   matching natural-language phrases; the MCP handler treats this marker as the
   structured human decision and all other answers continue through normal routing.

6. **Keep a visible ambiguity ledger**:
   Track independent ambiguity tracks (scope, constraints, outputs, verification).
   Do NOT let the interview collapse onto a single subtopic.

7. **Repeat steps 2-6** until the user says "done" or MCP signals seed-ready.

8. **Seed-ready Acceptance Guard (tri-panel fan-out)**:
   When MCP signals seed-ready, do NOT relay completion blindly. Before
   announcing completion or suggesting `ooo seed`, run the acceptance guard as a
   **3-lane fan-out** instead of a single local check, so closure is pressure
   -tested from three independent perspectives:
   - `closer` — apply the canonical Seed Closer criteria from
     `src/ouroboros/agents/seed-closer.md`. This lane's verdict **gates**.
   - `contrarian` — challenge the interview's conclusions: hidden assumptions,
     overloaded terms, decisions the interview skipped.
   - `gap_hunter` — hunt for missing requirements, unlisted constraints,
     unhandled edge cases, and unverifiable acceptance criteria.

   Spawn one subagent per lane through your runtime's native subagent mechanism
   (Claude Code → one Task/Agent call per lane in one parallel batch; Codex →
   one native Codex subagent per lane; runtimes with no parallel primitive →
   process the lane payloads sequentially). Correlate results by
   `context.lane_id`. Run the check from the main session's perspective,
   including any code, research, or brownfield context MCP did not see.

   **Synthesis (deterministic)**: the `closer` verdict gates — if it is not
   `seed_ready`, do not announce seed-ready. Additionally, any HIGH-severity
   `contrarian` or `gap_hunter` finding blocks closure and its question is
   appended to the blocking follow-ups. If closure is blocked, explicitly
   override the MCP signal: `"MCP says seed-ready, but I am not accepting it yet
   because <gap>."` Explain the gap briefly and ask the single highest-impact
   blocking follow-up question, routed through PATH 2 or PATH 3 as appropriate.
   When no parallel primitive exists, running only the `closer` lane is the
   backward-compatible single-pass fallback.

9. **Restate gate** (only after Seed-ready Acceptance Guard passes):

   Once the Acceptance Guard passes, do not jump straight to `ooo seed`.
   First restate the agreed goal as a single sentence and ask the user to
   confirm it captures the decision. This is the one place where compression
   to a single line is the goal — every other answer in the interview was
   sent to MCP in full multi-section form (see Step 3), and now we collapse
   the accumulated agreement into a one-line goal that another person could
   read and arrive at the same outcome.

   ```json
   {
     "questions": [{
       "question": "Based on the answers we agreed on, here is a one-sentence restatement of the goal:\n\n  goal: <one-sentence restatement>\n\nIf someone else read only this line, would they arrive at the same outcome you have in mind?",
       "header": "Restate — one-line goal before seed",
       "options": [
         {"label": "Yes, generate seed", "description": "The line captures the goal; proceed to ooo seed"},
         {"label": "Adjust wording", "description": "The intent is right but I want to change words"},
         {"label": "Missing scope", "description": "A condition or boundary is missing from the line"}
       ],
       "multiSelect": false
     }]
   }
   ```

   Only after the user accepts the restated line do you suggest `ooo seed`.
   If the user picks "Adjust wording", immediately use the `ask_user` capability
   to collect the replacement wording:
   ```json
   {
     "questions": [{
       "question": "How should the one-sentence goal be worded instead?\n\nCurrent line:\n  goal: <one-sentence restatement>",
       "header": "Restate — Wording"
     }]
   }
   ```

   If the user picks "Missing scope", immediately use the `ask_user` capability
   to collect the missing condition or boundary:
   ```json
   {
     "questions": [{
       "question": "What scope, condition, or boundary is missing from the one-sentence goal?\n\nCurrent line:\n  goal: <one-sentence restatement>",
       "header": "Restate — Scope"
     }]
   }
   ```

   Treat the follow-up text as a real interview correction, not a local-only
   wording tweak. Route the follow-up text through the Refine gate before
   forwarding it. **The Step 4 short-PATH-2 skip rule does NOT apply here,
   even if the correction is a single sentence** — a bare reply like
   `"Exclude retry scheduling from the seed."` still encodes a boundary
   decision that must reach MCP as `[from-user][refined]` with the reopen
   `last_question`; sending it as `[from-user]` would leave MCP on the stale
   pre-correction state. Then build the same structured multi-section
   payload from Step 3 using the canonical five-section schema —
   - **Decision**: the corrected one-line goal verbatim.
   - **Reasoning**: why the wording/scope changed (carry over the user's
     correction text, do not paraphrase).
   - **Constraints (user-stated)**: any constraint introduced or tightened
     by the correction.
   - **Out of scope (user-stated)**: anything the correction marks as
     explicitly excluded.
   - **Codebase context (main session v

…(truncated)