discovery

/discovery - 高密度ディスカバリーフェーズアダプター

取り込まれたスキル（ag-s43tg）

brainstorm（目標と実装の明確化）＋design（プロダクト適合性のストレステスト）— トリガーの詳細は以下の「統合されたトリガー範囲」を参照してください。

このワークフローは必ず実行してください。説明するだけで終わらせないでください。

制約

• 調査と計画は別々に委任してください。事前検証の委任はMVPスライスモードの場合に限ってください。ファンアウト・デュエルですでに事前検証の判定が出ているためです。
• 新たな構築の範囲を定める前に、機能が存在しないことを証明してください。これにより、機構の重複と新規作成分の誤った見積もりを防ぎます。
• ファンアウト／一方向ドアの判断だけをデュエルに回し、通常のMVPスライスは範囲を限定したクイックパス内で進めてください。
• MVPの事前検証に3回失敗したら、範囲を限定した計画支援のラウンドを1回だけ実行してください。UNSTUCK なら再開し、ESCALATE の場合のみ人間に尋ねてください。

ループ内の位置： 運用ループのmove 1（意図をBDDとして形にする）と、move 3（スライス候補）の種です。 Discoveryは、目標と委任された子成果物を、/crankと/validate向けの高密度な実行パケットにまとめます。また、/rpiのアジャイル再計画ループの再計画エンジンでもあります。初期計画の後は、Learnの計画影響パケットを引用した明示的なオーケストレーターの再計画リクエストがある場合にのみ実行します。スライス候補は小さくすること： Given/When/Thenの振る舞いはそれぞれ1つとし、リファクタリング候補と機能候補は分けてください。小さなバッチとグリーン後のリファクタリングが品質を支える重要な施策であり、テストファーストの順序ではありません（Finster 2026、skills/standards/references/agentic-workflow-evidence.md）。分解の拘束力ある規律は/plan（PR-010/PR-011）に従います。

統合されたトリガー範囲（brainstorm、design）

Discoveryは、廃止された独立スキルbrainstormとdesign（スキル整理フェーズ2）の統合先です。これらのユースケースでは/discoveryを実行してください。

• Brainstorm — 目標と実装を分ける。 計画の前に目標を明確にします。WHATとHOWを分け、解決策を決める前に問題空間を探索し、Given/When/Thenの受け入れ例を記録してください。意図 → Gherkin → 実行済みのred → bead-DAGという一連の契約は、behavior-first-planningが担います。beadに実行可能な完了基準を持たせる必要がある場合は、こちらを引用してください。自由形式のアイデア創出（generate-winnow、--ideate）については、以下の自由形式パスを参照してください。
• Design — Discoveryの前にプロダクト適合性を検証する。 問題の枠組みを定める場合、プロダクトと市場の適合性を確認する場合、またはDiscoveryパケットやコードを書く前にユーザー価値をストレステストする場合に使用します。プロダクト検証ゲート（PRODUCT.mdとの整合、council --preset=product）は、Discoveryにおける条件付きのdesign委任ステップとして実行されます。

厳格な委任契約（デフォルト）

Discovery はブレインストーミングと設計を内部モード（吸収済み、ag-s43tg）として実行し、/research、/plan、/premortem に個別のスキル呼び出しとして委任します。厳格な委任がデフォルトです。

拒否すべきアンチパターン： /research の作業をインラインで行う（grep + read + synthesize）、/plan をインラインの分解にまとめる、/premortem を省略する。契約の全文、サポート対象の圧縮エスケープ（--quick、--skip-brainstorm、--interactive/--auto、--no-scaffold）、およびプレモーテムの合理化防止条項（プレモーテムに該当しないもの：自分で書いたインラインのリスクセクション、今回の計画ではなく入力や前提に対して以前に行った敵対的検証、「関連する審議はすでに実施済み」）については、../shared/references/strict-delegation-contract.md を参照してください。

スコープを定める前に必ず再ベースラインを確認してください（「X を改善する」／「不足している Y を構築する」場合は必須）：新たな構築のスコープを定める前に、/research はその機能がすでに存在しないことを必ず確認しなければなりません。--auto の落とし穴は、作成者が grep せず記憶を頼りに「未構築のもの」を調査し、既存の仕組みを新規開発として再見積もりしてしまうことです。「X が不足している」という主張にはすべて、それを証明した検索結果が必要です。検索がなければ、/premortem の再ベースライン確認（2.4～2.8）で警告または失敗となります。まず ms search "<capability phrase>" で存在確認の検索を実行してください（ms が利用可能な場合の高速な方法です。command -v ms を実行するか、mcp__ms__search ツールが接続されていることを確認してください。利用できない場合は skills/**/SKILL.md と docs/SKILLS.md を grep してください）。その検索結果をパケットの重複・先行事例セクションに記載してください。

機械的な4つのレバーのモデルと、scripts/check-skill-isolation.sh が検出する圧縮パターンについては、references/isolation-contract.md を参照してください。ライフサイクルの原則とアンチパターンの引用表については、references/best-practices.md を参照してください。

ナローワエスト

Discovery は、子スキルの生の出力を引き継ぎません。成果物のパス、判定結果、docs/architecture/intent-to-loop-hexagon.md の hexagon: 境界ブロック、およびコンテキスト密度ルールの次の6つのフィールドを記録します。

フィールド	意味
intent	実現する動作または機能
boundary	境界づけられたコンテキスト、対象外事項、書き込み範囲
evidence	受け入れ例、テスト、ゲート、判定結果
decision	この計画の形を選んだ理由
constraint	安全性、ランタイム、トークン、プロセスの制限
next_action	実行する /crank またはフォローアップコマンドの正確な指定

それ以外はすべて子成果物に残し、パスでリンクします。

Discovery から Plan へのポート

Discovery と Plan の境界には、Skill Ports and Adapters の用語と Intent-to-Loop Hexagon を使用してください。

境界要素	Discovery の契約
インバウンドポート	オペレーターの目標または BDD の意図からの shape_intent
アウトバウンドポート	/plan に渡す plan_slices
駆動アダプター	/discovery スキル呼び出し
被駆動アダプター	/plan スキル呼び出しと br/file の永続化
コンテキストパケット	密度ブロック、成果物リンク、受け入れ例、対象外事項、制約
ガードアダプター	パケット引き渡し前のプラン・ポー・デュエル判定（ファンアウト）または /premortem 判定（MVP スライス）

実行可能な受け入れ条件：references/discovery.feature — Discovery は plan_slices ポートを介して密度の高い意図を引き渡します（インラインから昇格、soc-qk4b.2）。

目標設計パケットの入力（intent.md + driver.md）には references/goal-design-packet-input.md を使用してください。調査の前にチェッカーを実行してください。失敗した場合はブロックされます。チェック済みのパケットは密度フィールドと候補スライスのシードに使用し、/plan の代わりにはしません。

Plan-Pawl デュエルゲート

リスククラスによるルーティング：MVPの垂直スライスとファンアウト（最初に判断）

デュエルの対象は、すべてのスライスではなく、一方通行の決定です。まずルーティングします。

• ファンアウトクラス（アーキテクチャの分岐、一方通行の決定、エージェント間の調整契約、プロダクトの決定）：以下のプラン・ポーンデュエルを実行します。PLAN成果物に対する multi-model ポーンです（docs/contracts/pawls.md）。 これは、従来の単独ジャッジによるCodexファンアウト承認と /premortem 協議会を、1つのクロスファミリーゲートに統合します（ファンアウト／--complexity=full では --duel が自動的に有効になります）。
• MVPの垂直スライス（通常のランタイム／CLI作業のデフォルト）：デュエルをスキップします（--no-duel）。厳格なタイムボックスのもとで探索DAGを実行し、探索は約15分、スライスは約90分を目安にしてから停止します。スライスで実施するのは、インラインの --quick premortem のみです。スライス中に明らかになった作業は、アクティブなbeadに取り込まず、後続のbeadにします。

プラン・ポーンが審査するのはプランの形であり、動作ではありません。2026-06-12のランタイムレビューでは、整合性のあるファンアウトと承認のセットでも、敵対的テストを1つ実施すれば検出できたはずの認証バイパスを見逃しました（学び）。

ゲート（ファンアウトクラスの作業のみ）

/plan がbeadを作成する前に、デュエルを挿入します。2ジャッジの ApprovalEdge の形式は docs/contracts/codex-fanout-approval-packet.mdに、DAGのステップは references/dag.mdのSTEP 3.5に記載されています。

1. 異なる視点（プロダクト／ユーザー価値、アーキテクチャ／ゲートの完全性、運用／移行）から、独立した PerspectivePlan 成果物を少なくとも3つ作成します。
2. それらを1つの SynthesisPacket（選択したプラン、却下した代替案、その理由、未解決の質問、リスク）に絞り込みます。
3. クロスファミリーのDUELを実行します。異なるファミリーのジャッジ用ペインを2つ（例：agent-nativeとntmを使ったClaudeとCodex）用意します。--no-user を指定し、構成上、新鮮なコンテキストを使います。それぞれが .agents/duel/<run-id>/ にジャッジ判定を1つ記録します。
4. 決定は決定論的に行います。ペインを自分で読んではいけません。 ao plan-pawl decide --dir .agents/duel/<run-id> --round <N> --max-rounds <duel-rounds>。 終了コード0の PASS（クォーラム：FAILなし、異なるファミリーが2つ以上）なら /plan へ進みます。終了コード3の REDO なら自動でやり直します（FAILの場合は再合成します。機械的なWARNは自動適用して再審査します。判定によるWARNは表面化しますが、ブロック要因にはなりません）。終了コード4の BLOCKED ならブレーカーが作動しています（ラウンド数が上限を超えた／判定フラグ／振動）。停止します（アンドン）。
5. デュエルの ApprovalEdge（両方のジャッジ用ペイン、duel_verdict_dir、決定）を保存します。ファンアウトではこの判定がpremortemの判定を兼ねるため、2つ目の協議会は実行しないでください。

承認の証拠はworktreeを越えて残す必要があります。ゲート対象のbead／エピックをクローズする前に、協議会／デュエルの成果物（または簡潔な証明パケット）を、追跡される永続的な保存先に複製します（codex-execを参照してください）。一時worktree内の .agents/ は無視されます。

オープンエンドパス（generate-winnow → 運用化 → 改善）

デフォルトのフローに追加されるものであり、厳密な委任契約やアーティファクト優先の DAG に取って代わるものではありません。 このパスは、オープンエンドな「プロジェクトを改善する」形式の目標（"improve the project"、"what should we build next"、"make X more robust"）の場合、または --ideate が渡された場合に有効になります。具体的な目標の場合、デフォルトのフロー（ブレインストーミングによる明確化 → 調査 → 計画 → 事前検死）は変更されません。

オープンエンドパスでは、Discovery が調査／計画の前に generate-winnow の手法を追加し、計画後にも 2 つのステップを加えます。詳細は references/bead-operationalization.md と references/ideation-mode.md を参照してください。

1. アイデアを出す（brainstorm --ideate に委任）。 brainstorm をアイデア創出モードで呼び出します（実際のスキル呼び出しです。厳密な委任は引き続き適用されます。30 個のアイデア生成をインラインで行わないでください）。その結果、どのように／どう認識するか／どのように実装するかのメモ、評価基準のスコア、レッドチームの調査結果を含む、順位付けされた 15 個のアイデアからなるポートフォリオ（上位 5 件＋次点 10 件）が返されます。
2. 調査＋plan-pawl の対決＋計画。 選定したポートフォリオについて調査します。オープンエンドまたは高リスクの作業はファンアウトクラスです。PerspectivePlan アーティファクトと SynthesisPacket を作成し、/plan がトラッカーの行を作成する前に、STEP 3.5 の plan-pawl 対決（異なる 2 つのファミリー、ao plan-pawl decide）を実行します。この対決の判定が事前検死に代わります。その後、単一の目標ではなく、承認済みのパケットに対して通常のアーティファクト優先 DAG を実行します。
3. 運用化。 順位付けされたポートフォリオを、包括的で詳細かつ自己文書化された ビーズのセットに変換します。タスク、サブタスク、依存関係の構造（ao beads exec dep add）、および明示的なテストタスク（詳細なログを伴うユニットテスト＋E2E テスト）を含めます。各ビーズには目的／理由／方法／リスク／成功条件を記載し、元の計画の Markdown を再確認する必要がないようにします。作成前に既存のビーズと重複がないか確認し（ao beads exec list --json）、重複は作らず統合します。
4. 計画空間で改善する（4～5 回のパス）。 パケットを /crank に渡す前に、ビーズのセットを対象に4～5 回の改善パスを実行します。各パスでは、AGENTS.md を再読込し（特にコンパクション後）、すべてのビーズについて妥当性と最適性を確認し、過度に単純化しない／機能や機能性を失わないようにします。パスの間に検証を行います（依存関係に循環がないこと、すべてのリーフが ao beads exec ready で着手可能であること）。

トラッキングには br を使用し、トリアージには bv を使います。これは AgentOps です。運用化と改善のステップでは、brainstorm のアイデア創出出力を使用します。詳しくは references/bead-operationalization.md を参照してください。

このパスの実行可能な受け入れテストは、references/discovery.feature（アイデア創出／運用化／改善のシナリオ、ag-yw0）です。

実行

references/dag.md に記載されたアーティファクト優先 DAG を実行します。 このファイルには、実行可能なワークフロー、状態の形式、ゲートの詳細、各ステップの詳細、受け入れ基準の YAML 契約が定義されています。

フラグ

フラグ	デフォルト	説明
--auto	on	完全自律モード（人間によるゲートなし）です。--interactive の逆です。/research と /plan に引き継がれます。
--interactive	off	リサーチと計画（STEP 3、STEP 4）に人間によるゲートを設けます。premortem ゲートには影響しません。
--skip-brainstorm	auto	目標がすでに具体的な場合、STEP 1 のブレインストーミングをスキップします
--ideate	auto	オープンエンドな生成・絞り込みの経路を強制します。brainstorm --ideate（30→5→15）に委任し、その後、自己文書化する br beads に落とし込み、plan space で4～5回洗練します。オープンエンドな目標では自動的に有効になります。オープンエンドな経路を参照してください。
--complexity=<level>	auto	複雑度レベル（fast / standard / full）を強制します
--no-budget	off	フェーズごとの時間予算を無効にします
--no-scaffold	off	STEP 4.5 での scaffold の自動呼び出しをスキップします
--duel	auto	STEP 3.5 で plan-pawl のクロスファミリー対決を実行します。fanout クラスと --complexity=full では自動的に有効になり、それ以外ではオプトインです。単一ジャッジによる fanout 承認と premortem council を統合します。
--no-duel	off	対決をスキップします（MVP-slice クラス）。承認が必要な場合は単一の Fable ApprovalEdge を使用し、STEP 5 ではインラインの --quick premortem を実行します。
--duel-rounds=<N>	3	最大試行回数のブレーカーが作動するまでの対決ラウンドの最大数（ao plan-pawl decide --max-rounds）です。

クイックスタート

/discovery "add user authentication"              # full discovery
/discovery --interactive "refactor payment module" # human gates in research + plan
/discovery --skip-brainstorm "fix login bug"       # skip brainstorm for specific goals
/discovery --complexity=full "migrate to v2 API"   # force full council ceremony

出力仕様

• パス： .agents/research/、.agents/plans/、.agents/council/ の下に子アーティファクトを配置します。密度の高いパケットと要約は .agents/rpi/ の下に配置し、重要なスライスは解決済みのトラッカーに記録します。
• ファイル名： 最新版／実行ごとのパケットには execution-packet.json、簡潔な要約には phase-1-summary-YYYY-MM-DD-<goal-slug>.md を使用します。スキルから返された子アーティファクト名はそのまま保持します。
• 形式： 標準出力には簡潔な Markdown 要約を出力し、密度フィールド、アーティファクトへのリンク、受け入れ例、制約、任意の epic ID、トラッカーモード、次のアクションを含む、スキーマに準拠した JSON パケットを出力します。
• 終了コード： bash skills/discovery/scripts/validate.sh を実行し、終了コードが 0 であることを確認します。beads では、Gherkin スライスを解決するために ao beads exec show <epic_id> が必要です。一方、tasklist モードでは、epic、slice、Given/When/Then のマーカーを含む .agents/rpi/tasklist.md が必要です。
• 後続工程への引き継ぎ： 密度の高いパケットと、モードに応じたトラッカーの根拠を /crank と /validate に渡します。子の生出力は、それぞれのアーティファクト内でリンクされたままにします。

品質チェックリスト

• 機能不足に関するすべての主張に、既存の仕組みと未実装の作業を区別する検索結果を引用します。
• パケットには、テスト可能な Given/When/Then の動作、非目標、根拠、制約、正確な次のアクションを保持し、子のトランスクリプト全文は含めません。
• リスク分類は使用したゲートと一致させます。また、計画したスライスが有効なトラッカーに存在するまでは、DONE にならないようにします。

完了マーカー

<promise>DONE</promise>      # Discovery complete AND persisted: beads mode requires a resolvable epic_id plus Gherkin-bearing child slices; tasklist mode requires .agents/rpi/tasklist.md with epic, slice, and Given/When/Then markers.
<promise>BLOCKED</promise>   # Report the actual class: fanout/hard gates may block directly; an ordinary MVP breaker blocks only after its bounded helper returns ESCALATE.

トラブルシューティング

よくある問題と解決方法については、references/troubleshooting.md を読んでください。

参照ドキュメント

• references/goal-clarification-brainstorm.md — ブレインストーミングの本文（4段階の明確化＋アイデア創出のファネル）を取り込み済み
• references/idea-rubric.md — ブレインストーミングのアイデア評価基準を取り込み済み
• references/brainstorm.feature — ブレインストーミングの実行可能な仕様を取り込み済み
• references/red-team-checklist.md — ブレインストーミングのレッドチーム用チェックリストを取り込み済み
• references/dag.md — 実行可能なワークフロー、状態の形式、ゲートの詳細、各ステップの詳細、受け入れ基準の YAML コントラクト
• references/complexity-auto-detect.md — キーワードと課題数による分類の優先順位に関するコントラクト
• references/idempotency-and-resume.md — 再実行時の安全性と再開動作
• references/phase-budgets.md — 複雑さのレベルごとの時間予算
• references/troubleshooting.md — よくある問題と解決策
• references/output-templates.md — 実行パケットとフェーズ概要の形式
• references/phase-data-contracts.md — フェーズ成果物のデータコントラクト（references/isolation-contract.md から参照） こちらも参照: research、plan、premortem、crank、rpi、scaffold