---

name: pm description: "Generate a PM through guided PM-focused interview with automatic question classification. Use when the user says 'ooo pm', 'prd', 'product requirements', or wants to create a PRD/PM document."

/ouroboros:pm

PM-focused Socratic interview that produces a Product Requirements Document.

Instructions

Step 0: Version Check (runs before the PM interview)

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

# 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:

  {
    "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 PM 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 pm 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.

Step 1: Load MCP Tool

tool discovery query: "+ouroboros pm_interview"

CRITICAL — deferred-schema guard (prevents "Invalid tool parameters"): This is a multi-turn loop 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. Calling ouroboros_pm_interview while its schema is unloaded in the current turn makes the runtime reject it with "Invalid tool parameters" every message. Therefore re-run tool discovery query: "+ouroboros pm_interview" immediately before EVERY ouroboros_pm_interview call below (idempotent — a no-op if already loaded). If the 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), follow the not-found diagnosis below instead of retrying the failing call.

If not found → fail closed without inspecting or mutating ~/.claude/mcp.json. Standalone Claude SDK setup requires MCP 1.x and cannot activate the Ouroboros MCP 2 server with its configured backend. Explain:

The PM interview MCP tool is unavailable in this runtime.

Configure a supported CLI-backed host with:
  ouroboros setup --runtime <codex|opencode|kiro|copilot|hermes>

Then restart that host and retry ooo pm. Claude SDK profiles ([claude] and
[claude-sdk]) stay on MCP 1.x; the separate [mcp] server uses [claude-cli]. Do
not combine both MCP majors or add a direct Python fallback.

Stop.

Step 2: Start Interview

Tool: ouroboros_pm_interview
Arguments:
  initial_context: <user's topic or idea>
  cwd: <current working directory>

This response carries the first question, so Step 3 applies to it — including the fan-out in 3-A2. The first question is the one most likely to be answered from memory, so it is the last one to skip evidence on.

Step 3: Loop

Apply this to every MCP response that carries a question, including the one Step 2 returned and any question a resume plans anew.

Batched turns (RFC #2222). A response may carry one to three questions at once: meta.question_batch lists them and meta.question_advisories carries one advisory envelope per question, each with its own question_advisory_subagents and question_advisory_fanout_id. Treat every question of the turn exactly as a single question is treated below, with these batch mechanics:

• Dispatch all envelopes' payloads in one wave — one subagent per payload across all questions, in a single parallel batch. Never leave a question's lanes undispatched: every question shown keeps its evidence.
• Submit results per envelope — each question's lanes correlate by its own envelope's question_advisory_fanout_id and question_advisory_result_correlation_key; one ouroboros_submit_fanout_results call per envelope.
• Relay the turn's answers together in one call: answers: [{question, answer}, ...], one entry per question the turn asked, each naming its own exact question text. One call records the turn, so collect every answer first — and never auto-answer, auto-defer, or decide-later one on the user's behalf to complete the set. The server does not check that you sent them all: whatever you leave out is abandoned, not remembered.
• The server keeps nothing between calls. A call that arrives without the turn's answers plans a new turn from the transcript rather than restoring the old one, so a turn you abandon is a turn the user will be asked again.
• Skip sentinels are per question: give that question the answer "[decide_later]" or "[deferred]" in its own entry.

A. Show alerts (if present in meta):

• meta.deferred_this_round → print [DEV → deferred] "question"
• meta.decide_later_this_round → print [DEV → decide-later] "question"
• meta.pending_reframe → print ℹ️ Reframed from technical question.

A2. Fan out the evidence lanes — required before you ask the user anything.

You do not look at the repositories yourself. Ever. This skill has no code-answer path: there is no step where you run Read/Glob/Grep or a docs MCP to answer a PM question, and finding the answer quickly on your own is the failure, not a shortcut past it. Evidence the PM cannot trace back to a lane is evidence the record does not contain — it is not bound to the question, not bounded by the roster, and not checked against the answer contract. This skill is self-contained: everything you need is here and in the tool response, so do not go looking for exploration rules in another skill's file.

When meta.question_advisory_subagents is present you MUST process every payload. Show the question first, then pass each payload's prompt unchanged. Obey meta.question_advisory_host_action: spawn_subagents means parallel support was declared; dispatch_subagents_if_supported means use the host's native parallel mechanism when available and process the same payloads sequentially otherwise; process_payloads_sequentially requires ordered processing. Claude Code parallel dispatch is one Task/Agent call per payload in one batch; Codex uses one native Codex subagent per payload. The payloads are the work contract, while the host action selects the execution strategy.

Say what is running. Same shape the regular interview uses: after the question, set off by a divider, one line naming how many perspectives are running and what they are — then what arrives when they finish.

---
While you answer this question, two perspectives are reviewing in parallel
(code context / data measurement). When they return I will put what they found
next to the question as grounds.

Two things differ from the interview's line, and both follow from this tool having two lanes instead of six:

• Name the perspectives in the user's terms, not by lane id. code_context is an identifier for the fan-out, not something the reader needs.
• End at "grounds", never at "options". The interview can promise to organise the results into answer choices because it runs a lane that produces them. This tool does not, and a promise the synthesis cannot keep trains the user to expect the one thing the lanes must never hand them.

Write the line in the language the user is speaking.

Do not go to step B while the lanes are still running. Step B is where you ask the user, and asking before the evidence arrives is the exact failure this mechanism exists to prevent: the PM decides without the two things they could not have looked up themselves. Waiting is for lanes still in flight: one that came back empty, broke its contract, or could not be spawned has returned.

Stub payloads. A payload's prompt may be a compact stub: it carries the lane's answer schema, where it may look, and the findings it may reuse, and points at ouroboros_fetch_artifact for the prose that explains them. Pass it unchanged exactly like any payload — the child fetches for itself, and a fetch it cannot make does not stop it. A child that replies exactly UNDISPATCHED could not work at all: submit that lane as { "key": <lane id>, "undispatched": true } rather than as an empty finding.

Submitting results back. Correlate by meta.question_advisory_result_correlation_key (context.lane_id) and call ouroboros_submit_fanout_results with meta.question_advisory_fanout_id, passing session_id explicitly. Submit every lane you hold, not only the new ones: a lane that ran and found nothing still submits its output, and a lane you could not spawn at all is submitted as { "key": <lane id>, "undispatched": true } — the literal true, with no content beside it. Never invent output for a lane you did not run; a fabricated finding is worse than a missing one.

Reading the reply. With a contract_id, synthesize from the outputs you hold. Without one, read missing_required_keys and contract_violations, then resubmit once carrying every lane. Still without one — go to B with what survived, or with none, saying in one line that the investigation did not come back. The interview does not wait on this.

Two lanes never reach the block, whatever the reply says. Leave out a lane named in contract_violations, and leave out a lane you submitted as undispatched — a lane that did not run has an empty place, not a clear one, and a reply can be accepted while one of them never ran. Where the block would have carried that lane, write that it did not run.

There are two lanes and both are required: code_context and data_context. Both are evidence-only (RFC #2222): what a lane finds is shown beside the question and sent nowhere — the published fan-out is already its record, and the interview records only what the user writes. Never skip asking the user because a lane answered clearly, and never send a lane's finding as an answer.

Synthesize into the evidence block. This is what synthesis_contract.output_shape = "evidence_beside_question" means, and it is a fixed shape so the same session twice looks the same twice. Print it immediately above the question, then ask the question unchanged:

Evidence (examined: billing-api, s