pm

/ouroboros:pm

製品要件定義書を作成する、PM に特化したソクラテス式インタビューです。

手順

ステップ 0：バージョン確認（PM インタビュー開始前に実行）

PM インタビューを開始する前に、新しいバージョンがあるか確認します。

# 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

結果を、アクティブなランタイムのローカルプラグインメタデータにある現在のバージョンと比較します（Claude のインストールでは .claude-plugin/plugin.json）。

• 新しいバージョンがある場合は、アクティブなランタイムの ask_user 機能を使ってユーザーに尋ねます。

  {
    "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
    }]
  }
  

  • 「今すぐ更新」を選んだ場合：
    • Claude プラグインのインストールの場合のみ：
      1. アクティブなランタイムの run_shell 機能を使って claude plugin marketplace update ouroboros を実行します（マーケットプレイスのインデックスを更新）。失敗した場合は、ユーザーに「⚠️ Marketplace refresh failed, continuing…」と伝えて続行します。
      2. アクティブなランタイムの run_shell 機能を使って claude plugin update ouroboros@ouroboros を実行します（プラグイン／スキルを更新）。失敗した場合は、ユーザーに知らせて停止します。パッケージマネージャーの手順には進まないでください。
    • Claude 以外のランタイムでは、Claude プラグインのコマンドを省略し、ouroboros-ai のパッケージマネージャーの手順に直接進みます。Claude 専用のコマンドやツールは必要ありません。
    3. ユーザーの Python パッケージマネージャーを検出し、MCP サーバーをアップグレードします。
       • 次のコマンドを順番に実行し、ouroboros-ai をインストールしたツールを確認します。
         • uv tool list 2>/dev/null | grep "^ouroboros-ai " → 見つかった場合は、uv tool upgrade ouroboros-ai を使用します。
         • pipx list 2>/dev/null | grep "^ ouroboros-ai " → 見つかった場合は、pipx upgrade ouroboros-ai を使用します。
         • それ以外の場合は、「Also upgrade the MCP server: pip install --upgrade ouroboros-ai」と出力します（pip は自動実行しないでください）。
    4. ユーザーに「更新しました！セッションを再起動して適用し、もう一度 ooo pm を実行してください。」と伝えます。
  • 「スキップ」を選んだ場合：すぐに続行します。
• バージョンが一致する場合、確認に失敗した場合（ネットワークエラー、タイムアウト、レート制限 403/429）、または解析に失敗する／結果が空の場合は、何も通知せずにスキップして続行します。

ステップ 1：MCP ツールを読み込む

tool discovery query: "+ouroboros pm_interview"

重要 — 遅延スキーマのガード（「Invalid tool parameters」を防止）： これは複数ターンにわたるループであり、各ターンは新しいツールコンテキストで実行されます。あるターンで読み込んだ遅延ツールのスキーマが、次のターンでも読み込まれたままとは限りません。現在のターンでスキーマが読み込まれていない状態で ouroboros_pm_interview を呼び出すと、ランタイムはメッセージごとに 「Invalid tool parameters」 を返して拒否します。したがって、以下の ouroboros_pm_interview のすべての呼び出しの直前に、必ず tool discovery query: "+ouroboros pm_interview" を再実行してください（べき等であり、すでに読み込まれていれば何も行いません）。読み込み時に該当するツールが見つからない場合（ツールがすでに呼び出し可能な状態である場合を除きます。公開済みのツールが空の読み込み結果になるのは想定どおりであり、ツールがないことを意味しません）、失敗した呼び出しを再試行せず、以下の「見つからない場合」の診断に従ってください。

見つからない場合は、~/.claude/mcp.json を調査または変更せず、安全側に倒して失敗させます。スタンドアロンの Claude SDK セットアップには MCP 1.x が必要であり、設定済みのバックエンドでは Ouroboros MCP 2 サーバーを有効化できません。次のように説明します。

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.

停止します。

ステップ 2：インタビューを開始

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

この応答には最初の質問が含まれるため、ステップ 3 を適用します。これには 3-A2 のファンアウトも含まれます。最初の質問は記憶を頼りに回答される可能性が最も高いため、エビデンスの確認を省略しない最後の質問です。

ステップ 3：ループ

ステップ 2 が返した質問や、再開時に新たに提示される質問を含め、質問を含むすべての MCP 応答にこれを適用します。

バッチ化されたターン（RFC #2222）。 応答には一度に 1～3 個の質問が含まれる場合があります。meta.question_batch に質問が列挙され、meta.question_advisories には質問ごとに 1 つのアドバイザリーエンベロープが含まれます。それぞれに独自の question_advisory_subagents と question_advisory_fanout_id が設定されています。以下の単一の質問に対する手順と同じように、そのターンのすべての質問を扱います。ただし、バッチの場合は次の仕組みに従います。

• すべてのエンベロープのペイロードを1つのウェーブでディスパッチする — すべての質問にわたって、ペイロードごとに1つのサブエージェントを、単一の並列バッチで実行します。質問のレーンを未ディスパッチのままにしないでください。表示されたすべての質問はその根拠を保持します。
• 結果はエンベロープごとに送信する — 各質問のレーンは、それぞれ自身のエンベロープの question_advisory_fanout_id と question_advisory_result_correlation_key によって関連付けられます。エンベロープごとに ouroboros_submit_fanout_results を1回呼び出します。
• そのターンの回答をまとめて1回の呼び出しで中継する: answers: [{question, answer}, ...]、そのターンが尋ねた質問ごとに1エントリ、それぞれが自身の正確な質問テキストを明示します。1回の呼び出しでそのターンが記録されるため、まずすべての回答を集めてください。そして、セットを完成させるためにユーザーに代わって自動回答、自動延期、または後で決めることを決してしないでください。サーバーはあなたがそれらすべてを送信したかどうかを確認しません。あなたが省略したものは破棄され、記憶されません。
• サーバーは呼び出しと呼び出しの間に何も保持しません。そのターンの回答なしで到着した呼び出しは、古いターンを復元するのではなく、トランスクリプトから新しいターンを計画します。したがって、あなたが破棄したターンは、ユーザーが再び尋ねられるターンになります。
• スキップセンチネルは質問ごとです。その質問に、自身のエントリで回答 "[decide_later]" または "[deferred]" を指定してください。

A. アラートを表示する（meta に存在する場合）:

• meta.deferred_this_round → [DEV → deferred] "question" を出力する
• meta.decide_later_this_round → [DEV → decide-later] "question" を出力する
• meta.pending_reframe → ℹ️ Reframed from technical question. を出力する

A2. エビデンスレーンをファンアウトする — ユーザーに何かを尋ねる前に必須です。

あなた自身がリポジトリを見ることはありません。決して。 このスキルにはコード回答のパスがありません。PM の質問に答えるために Read/Glob/Grep やドキュメント MCP を実行するステップはなく、自分で素早く答えを見つけることは近道ではなく、失敗です。PM がレーンまでたどれないエビデンスは、記録に含まれていないエビデンスです — それは質問に束縛されず、名簿によって境界づけられず、回答契約に対してチェックされません。このスキルは自己完結型です。必要なものはすべてここに、そしてツールのレスポンスにあります。ですから、探索ルールを別のスキルのファイルに探しに行かないでください。

meta.question_advisory_subagents が存在する場合、すべてのペイロードを処理しなければなりません。 まず質問を表示し、次に各ペイロードの prompt を変更せずに渡します。meta.question_advisory_host_action に従ってください。spawn_subagents は並列サポートが宣言されたことを意味します。dispatch_subagents_if_supported は、利用可能な場合はホストのネイティブな並列メカニズムを使用し、そうでない場合は同じペイロードを順次処理することを意味します。process_payloads_sequentially は順序立てた処理を要求します。Claude Code の並列ディスパッチは、1バッチ内のペイロードごとに1回の Task/Agent 呼び出しです。Codex はペイロードごとに1つのネイティブ Codex サブエージェントを使用します。ペイロードは作業契約であり、ホストアクションは実行戦略を選択します。

何が実行されているかを伝えてください。 通常のインタビューが使用するのと同じ形です。質問の後に、区切り線で区切って、いくつの視点が実行されているか、そしてそれらが何であるかを示す1行を置きます — 次に、それらが終了したときに何が到着するかを示します。

---
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.

インタビューの行と異なる点が2つあり、どちらもこのツールが6つではなく2つのレーンを持つことから導かれます:

• 視点はレーン id ではなく、ユーザーの言葉で名付けてください。code_context はファンアウトのための識別子であり、読者が必要とするものではありません。
• 「grounds」で終わり、「options」では決して終わらないでください。 インタビューは結果を回答選択肢に整理することを約束できます。なぜなら、それらを生成するレーンを実行するからです。このツールはそうではなく、シンセシスが守れない約束は、レーンが決してユーザーに手渡してはならないまさにそのものをユーザーが期待するように訓練してしまいます。

その行は、ユーザーが話している言語で書いてください。 レーンがまだ実行中のうちは、ステップ B に進まないでください。 ステップ B は ユーザーに問いかける場面であり、証拠が届く前に問いかけることこそが、このメカニズムが 防ぐために存在する典型的な失敗です。つまり PM が、自分では調べられなかった二つのことを 欠いたまま判断を下してしまいます。待つべきはまだ実行中のレーンです。空で戻ってきた レーン、契約に違反したレーン、起動できなかったレーンは、すでに戻ってきています。

スタブペイロード。 ペイロードの prompt はコンパクトなスタブである場合があります。 それはレーンの回答スキーマ、参照可能な範囲、再利用可能な調査結果を保持し、それらを 説明する文章については ouroboros_fetch_artifact を指し示します。他のペイロードと まったく同じように、変更せずにそのまま渡してください。子は自分でフェッチし、実行 できないフェッチがあっても子は止まりません。ちょうど UNDISPATCHED とだけ返答した 子は、まったく作業できなかったということです。そのレーンは、空の調査結果としてではなく { "key": <lane id>, "undispatched": true } として提出してください。

結果を送り返す。 meta.question_advisory_result_correlation_key （context.lane_id）で対応付けし、meta.question_advisory_fanout_id を指定して ouroboros_submit_fanout_results を呼び出し、session_id を明示的に渡します。 新しいレーンだけでなく、保持しているすべてのレーンを提出してください。実行して 何も見つからなかったレーンもその出力を提出し、まったく起動できなかったレーンは { "key": <lane id>, "undispatched": true } として提出します。リテラルの true で あり、その隣に content は付けません。実行していないレーンの出力をでっち上げないで ください。捏造された調査結果は、欠落した調査結果よりも悪いものです。

返答を読む。 contract_id がある場合は、保持している出力から統合します。 ない場合は、missing_required_keys と contract_violations を読み、その後、すべての レーンを保持したまま一度だけ再提出します。それでもない場合は、残ったもので B に 進むか、何もない状態で B に進み、調査が戻らなかったことを一行で述べます。インタビューは これを待ちません。

返答が何と言おうと、二つのレーンは決してブロックに到達しません。 contract_violations に名前が挙がったレーンは除外し、undispatched として提出した レーンも除外します。実行されなかったレーンは空の場所を持つのであって、明確な場所を 持つのではありません。また、そのうちの一つが実行されなかったのに、返答が受け入れられる ことがあります。ブロックがそのレーンを載せていたであろう箇所には、実行されなかった と書いてください。

レーンは二つあり、どちらも必須です。code_context と data_context です。どちらも 証拠専用（RFC #2222）です。レーンが見つけたものは質問のそばに表示され、どこにも 送信されません。公開されたファンアウトがすでにその記録であり、インタビューはユーザーが 書いたものだけを記録します。レーンが明確に回答したからといってユーザーへの問いかけを 省略しないでください。また、レーンの調査結果を回答として送信しないでください。

証拠ブロックに統合する。 これが synthesis_contract.output_shape = "evidence_beside_question" の意味であり、同じ セッションを二度実行しても同じ見え方になるよう固定された形状です。質問のすぐ上に 出力し、その後、質問を変更せずにそのまま尋ねます。

Evidence (examined: billing-api, storefront)

What the system does today
  · [billing-api] access continues to the end of the paid period
  · [storefront]  access is revoked immediately
    ! These two repositories implement this differently.

Measured — active subscriptions by plan, last 90 days
  · standard 12,480 / premium 3,120

画面はプロダクトの言葉を話し、ストアは引用を保持します （RFC #2222 決定 4）。 各コードの主張は、レーンが記述した plain_statement から レンダリングされます。決して policy_claim からではなく、あなたが言い換えることも ありません。画面上にファイルパス、クラス名、フラグの値は出ません。path + policy_claim の引用は公開されたファンアウトに残り、その contract id でフェッチ できます。それらはどこにも表示されず、他のどこにも記録されません。レーンは質問の 言語で plain_statement を書くので、あなたが翻訳するものはありません。上記のラベルは ブロックの形状を表すプレースホルダーであり、コピーするテキストではありません。

このブロックがそうではないもの。 それには回答の選択肢、推奨、順位付け、 「したがって……」という文は含まれません。回答を提案した瞬間、それはもはや証拠では ありません。これこそが、このツールと、実際に選択肢を統合する通常のインタビューとの 決定的な違いです。PRD はシステムがどうすべきかを問い、上記のすべてはシステムが どうであるかを述べます。

構築するためのルール:

• 各主張はそのリポジトリに紐づけたままにします。 2 つのリポジトリの主張を 1 行に統合してはいけません。また、不一致を 1 つのポリシーと例外として提示してはいけません — 上記のようにフラグを立てます。この矛盾は PM に見せられる最も有用な情報であり、 きれいにまとめた要約が最初に破壊してしまうものです。
• 常に調査対象スコープを出力します。 examined にはレーンが読み取ったリポジトリごとに 1 つのエントリがあり、各主張はそれぞれのエントリ内にあります。5 つのうち 2 つの リポジトリで「何も見つからなかった」という結果は、5 つすべてで見つからなかった場合とは 意味が異なります。policy_claims が空のエントリは、読み取ったが何もなかったという ことです — そのように伝えます。エントリがないリポジトリは一度も開かれておらず、 クリーンであるとして出力してはいけません。
• 測定値は報告されたままに扱います — レーンの metric、そのグループ、その数値。 再スケーリング、統合、丸めは行いません。読み取りを実行したのはあなたではないからです。
• no-op レーンは最大 1 行、多くの場合は 0 行です。 理由はユーザーのシステムについての 記述ではなく、そのレーンについての記述として読み取ります: not_a_policy_question / not_a_measurement → 何も出力しません。この質問は単に その種類ではないだけです。no_repository_in_roster / roster_repository_not_readable / store_described_but_not_callable → これらはあなたが 対処するものです (何も登録されていない、パスが開けなかった、ストアが応答しなかった)。 これらのいずれも「あなたのシステムにはそのようなポリシー／データはありません」として 伝えてはいけません。
• ユーザーがすでに回答して先に進んだ所見は破棄します。 レーンがまだ実行中にユーザーが 回答した場合、確定した決定をその所見で再び開いてはいけません。それを置く場所はありません: 所見はそれが取得されたラウンドを受け取り、そのラウンドはすでに消費されています。
• ロスター外からの証拠は証拠ではなく提案です。 それは提出時に拒否されるため、 所見として伝えると、記録に含まれていないものをユーザーに見せることになります。 代わりにそのリポジトリを登録することを提案し、次の質問をそれに対して回答できるようにします。

A3. 所見は証拠であり、決して回答ではありません (RFC #2222)。

記録のステップはありません。所見の永続的な記録は、公開されたファンアウトそのものです — コントラクト ID でアドレス指定可能で、最近の所見を通じて後続のレーンに再提示されます — したがって、それを回答として再び送信すると、ストアが重複し、それに質問のターンを 費やすことになります。[from-code] の回答を送信してはいけません。所見を別のターンとして 「確認」するようユーザーに求めてはいけません。また、所見をいかなる回答ペイロードにも 貼り付けてはいけません。証拠ブロックが所見の唯一の出現です。ユーザーは証拠を目の前にして、 自分の言葉で質問に答えます。

B. コンテンツを表示し、ユーザー入力を受け取る (A2 のレーンが戻った後):

質問テキストはすでに A2 で表示されており、ユーザーはいつでも回答できます。ここで待っているのは あなたの正式なプロンプトであり、人ではありません。

まず MCP コンテンツテキストをユーザーに出力し、その横にレーンの所見を添えます。

ユーザーに、推測的な回答を考案する必要はないと伝えます。質問が不明、ステークホルダー依存、 範囲が広すぎる、または後で決定する方が安全な場合は、それを確定した要件として提示するのではなく、 既存の前提／後で決定／延期のメカニズムを通じてルーティングします。

次に確認します: meta.ask_user_question は存在しますか？

• YES → それを直接 AskUserQuestion に渡します:

  AskUserQuestion(questions=[meta.ask_user_question])
  

  変更してはいけません。オプションを追加してはいけません。質問を言い換えてはいけません。
• NO → これはインタビューの質問です。meta.question を指定して AskUserQuestion を使用します。
  • 一括ターン：ターン内のすべての質問を、1 回の AskUserQuestion 呼び出しにまとめます。質問ごとに 1 つのエントリーを指定します（ツールが受け付けるのは最大 4 件です）。それぞれの選択肢は、以下の同じルールに従い、meta.question_batch 内の各エントリーから個別に作成します。スキップの選択肢は、ほかの質問ではなく、その質問自身の classification に従います。
  • meta.skip_eligible == true の場合は、meta.classification に基づいてスキップの選択肢を追加します。
    • classification == "decide_later" → 選択肢 {"label": "後で決める", "description": "スキップ — PRD の未決事項として記録されます"} を追加します。
    • classification == "deferred" → 選択肢 {"label": "開発チームに委ねる", "description": "スキップ — この技術的な決定は開発フェーズに委ねられます"} を追加します。
  • ほかの選択肢として、回答候補を 2〜3 個生成します。適切な場合は、「まだわかりません — 仮定または後で決める項目として記録する」のような、推測を含まない不確実性を示す選択肢を含めます。

C. 回答を返す：

ユーザーが「後で決める」を選んだ場合 → answer="[decide_later]" を送信します。 ユーザーが「開発チームに委ねる」を選んだ場合 → answer="[deferred]" を送信します。 それ以外の場合 → 以下のリファインゲートを通してユーザーの回答を送信します。

一括ターンの場合：各回答をそれぞれのリファインゲートに通してから、1 回の呼び出しで answers: [{question, answer}, ...] として送信します。質問文は、そのターンで提示したものと完全に同じにします。ターンを送信する呼び出しは、次のターンの質問を返します。

リファインゲート — 構造化し、誰の言葉かを明示してから、ユーザーに確認します。

ユーザーが選択肢を選んだだけの場合も含め、必ず回答を構造化します。送信するテキストは、次の質問と、PRD に決定事項として記録する内容について、MCP が参照できる唯一のコンテキストです。そのため、ラベルだけでは決定に至った経緯がすべて失われます。安全に構造化するには、以下の 2 つが重要です。

各セクションが誰の言葉かを明示します。 ユーザー自身の言葉を含むセクションには (user-stated) とラベルを付けます。回答に対するあなたの解釈を含むセクションにはラベルを付けません。これにより、読み手は両者をひと目で区別できます。

[from-user][refined]
Decision: <what they decided, in their words>

Reasoning:
- <your reading of why, drawn from what they said in this session>

Constraints (user-stated):
- <constraints they stated>

Out of scope (user-stated):
- <what they put out of scope>

記載する内容がないセクションは省略します。空の Constraints (user-stated) は、もっともらしい内容で埋めるより省略したほうが適切です。また、ユーザーが何も述べていないのに Reasoning を記載することこそ、このラベル付けで明らかにしようとしている失敗です。

コードベースのコンテキストのセクションや、レーンの調査結果は含めません。 通常のインタビューでは、メインセッションがコード自体を調査するため、そのようなセクションを追加します。しかし、ここでは調査しません。レーンの調査結果は、公開されたファンアウトと質問の横の画面上にあります。それをこのペイロードに含めると、ユーザーの決定の一部として記録されてしまいますが、実際にはそうではありません（A3）。

次に確認します — これがゲートであり、上記の構造化を行うための条件です。 送信前に AskUserQuestion を 1 回実行します。

{
  "questions": [{
    "question": "I structured your answer as follows before sending it:\n\n<payload>\n\nIs anything missing or misrepresented?",
    "header": "Refine — preserve your answer",
    "options": [
      {"label": "Send as-is", "description": "The structure captures my answer faithfully"},
      {"label": "Fix the reasoning", "description": "That is not why I decided it"},
      {"label": "Add to Constraints", "description": "I want to add a constraint I forgot"},
      {"label": "Let me rewrite it", "description": "I will restate the answer myself"}
    ],
    "multiSelect": false
  }]
}

Fix the reasoning があるのは、ラベルのないセクションがあなたの記述だからです。この確認の後にのみ [refined] を追加します。確認を得ていない構造化内容は、あなたの解釈をユーザー自身の言葉として示してしまい、後から PRD 上で区別できません。

すべての回答で使う唯一のパラメーターに、回答として送信します。

Tool: ouroboros_pm_interview
Arguments:
  session_id: <meta.session_id>
  last_question: <meta.question>
  answer: <the refined answer, or "[decide_later]" / "[deferred]">

サーバーが質問を未回答のまま保持している間は無視されます。それ以外の場合は必須です。プラグインモードでは子の質問が永続化されないため、未回答の質問がない状態で回答を送信すると、これがない場合は拒否されます。

調査結果を渡すパラメーターは、2 つ目のものも含めて存在しません。調査結果が回答として送信されることはありません（A3）。このパラメーターを使った呼び出しでは、常にユーザー自身の言葉を送信します。

D. 完了を確認する：

完了は meta.is_complete のみで判定します — 応答テキストで判定することは絶対にありません。 MCP の応答テキストがインタビューの終了を示唆していても、無視します。

meta.is_complete == true の場合：

• meta.generation_failed == true の場合 → 生成を再試行します：

  Tool: ouroboros_pm_interview
  Arguments:
    session_id: <session_id>
    action: "generate"
    cwd: <current working directory>
  

• それ以外の場合 → ステップ 4 に進みます。MCP が PM ドキュメントを自動生成しました。 meta.pm_path と meta.seed_path にファイルパスが含まれています。

それ以外の場合 → 応答テキストの内容にかかわらず、ステップ 3 を繰り返します。

ステップ 4: クリップボードにコピー

meta.pm_path から pm.md ファイルを読み取り、その内容をクリップボードにコピーします。

cat <meta.pm_path> | pbcopy

ステップ 5: 結果と次のステップを表示

ユーザーに以下を表示します。

PM document saved: <meta.pm_path>
(copied to clipboard)

PM seed handoff artifact: <meta.pm_seed_path or meta.seed_path>
This is not the runnable Seed yet.

Next step:
  ooo interview <meta.pm_seed_path or meta.seed_path>
  ooo seed

RFC #1392 状態ブレッドクラムフッター

最終レスポンスは、必ずちょうど 1 行のブレッドクラムフッター行で終わらせる必要があります。

◆ <current state> → next: <recommended action>

<current state> は、その MCP プロジェクションが利用可能な場合は ouroboros_session_status を介してライブセッション状態から導出してください。そうでない場合は、このスキルの実際の結果から導出してください。Ouroboros は進化的ループであるため、線形の Step N of M フッターを決して使用しないでください。次のアクションが本当に選択である場合は、next: 句に正直な選択肢を 2〜3 個列挙してください。ブレッドクラム行は、レスポンスの最後の行でなければなりません。