要件オーケストレーターは何をしますか？

ソフトウェア要求を、単一の制御エージェントがスコープ、依存関係、エビデンス、統合に責任を持ちながら、独立に検証可能な作業に変換します。このスキルはオーケストレーターであり、プロンプト生成器ではありません。

セマンティックモードの選択

analyze：要求とコードベースを調査し、元帳を維持し、コードを変更せずに実行計画を作成します。実装が要求されていない場合のデフォルトです。
diagnose：報告された障害を再現して説明し、確定した根本原因、エビデンス、未知の事項、推奨される修復パスを分離します。診断が成果物です。コードは変更しないでください。
execute：範囲が定められた作業を派遣し、返された結果をレビューし、統合を完了します。ユーザーが実装または実行を許可した場合にのみ開始します。
challenge：既存の要件、分解、または設計を、その確定した製品目標を変更せずに、欠落やリスクについてテストします。references/challenge.mdを参照してください。

これらはスキルレベルのセマンティックモードです。プラットフォームネイティブの計画モード、EnterPlanMode、または必須の探索/計画エージェントを呼び出したり必要としたりしません。ネイティブモードは、独立して有用であり、ユーザーの制約と互換性がある場合にのみ使用してください。

委譲を必要としない単一根本原因のタスクの場合は、制御ループを直接使用してください。references/spec-driven.mdを読んで仕様（要件、受入シナリオ、コントラクト）を作成してください。既存のコードベースで分解する前にreferences/context-grounding.mdを読んでください。候補タスクが複数ある場合、サービス/ドメイン境界がある場合、スケジューリングの決定がある場合、またはリポジトリの状態が原因となる可能性のあるビルド/デプロイ障害がある場合は、references/decomposition.mdを読んでください。受入エビデンスの基準についてはreferences/verification.mdを読んでください。作業に複数のタスク、エージェント、セッション、またはプラットフォームがある場合はreferences/ledger.mdを読んでください。実行が既存のアーティファクトを書き換え、削除し、または複数にまたがって変更を広げる場合、あるいは外部システムに書き込む場合はreferences/mutation.mdを読んでください。実行例：references/examples/feature-example.mdおよびreferences/examples/bug-example.md。

diagnoseモードでは、観測または再現された障害、確定した根本原因とエビデンス、未検証の項目、影響、推奨される修復パスを報告してください。ユーザーが別途executeを許可しない限り、そこで停止してください。

制御ループ

目標、スコープ、受入基準、制約、検証済みのコードファクトを確立します。まず未知の事項を調査し（references/context-grounding.md）、その結果を仕様（要件、受入シナリオ、コントラクト）として表現します（references/spec-driven.md）。発見可能な事実を調査し、スコープ、受入、または方向性に実質的に影響を与える決定についてのみユーザーに質問します。分解する前に、能力知識ベース（references/knowledge-base.mdを参照）を参照して、目標に関連する既存のスキルと同一ドメインの比較を取得します。ゼロから調査するよりも、既知の能力を再利用またはインポートすることを優先し、選択した能力を元帳に記録します。
- プロジェクトの過去の教訓が存在する場合はそれを読み（references/experience.md）、検証すべき候補事実として扱い、絶対的な真実として扱わないでください。
- 重要なビルドの場合、仕様の後に技術設計（references/tech-design.md）— アーキテクチャ、詳細設計、代替案、横断的関心事 — を作成し、成果物をdocs/レイアウト（references/deliverables.md）の下に永続化します。
報告されたバグまたは障害の場合、根本原因を主張する前に、まず比例的なローカル再現を試みます。観測された障害を報告と比較します。再現されるか、同等の直接的なエビデンスによって裏付けられるまで、根本原因の記述は仮説としてラベル付けし、何が未検証かを明記します。
1つの主要な分解軸を選択し、範囲が定められたタスクを作成します。共有コントラクトを導出し、依存タスクまたは並列作業の前にそれらを固定します（references/spec-driven.md）。依存関係とタスク間コントラクトを明示的に記録します。結果のタスクグループをフェーズ化されたTODO（進行状況表示を参照）に反映します。
正確に1つの制御エージェントを維持します。コントローラーは、元帳、派遣決定、レビューステータス、再計画、および最終統合を所有します。
完全なコントラクトを持つタスクのみを派遣します。最初の派遣の前にreferences/agent-contract.mdを読んでください。ローカルのワーキングツリーを超えたシステムへの書き込みを派遣する前に、以下の対象システム事前チェックを実行します。
ワーカーの結果をreviewに受け入れ、受入エビデンス基準（references/verification.md）に対してエビデンスと境界を検証し、completedとマークするか、具体的な所見とともに差し戻します。一括または外部への変更の場合、ツールの報告された成功数ではなく、独立した読み戻しと構造的な差分によって検証します。
発見、障害、またはスコープ変更の後、影響を受ける依存関係を再計算します。影響を受ける最小のブランチを再作業します。
タスクレベルのチェック、タスク間コントラクト、およびすべての受入シナリオが一緒に合格した場合にのみ、要求が完了したと宣言します。エンドツーエンドのゲートはreferences/verification.mdで定義されています。完了時に、該当するプロジェクト固有の教訓があれば、経験ログ（references/experience.md）に追加します。実行からスキル自体を改善することは、別のオプトインアクションです — 教訓が一般的かつ反復的である場合にのみ提供され、ユーザーが選択した場合にのみ適用され、決して自動的ではありません（references/experience.mdを参照）。

進行状況表示

ユーザーが散文だけでなく、フェーズとステップレベルの進行状況を確認できるように、可視化されたフェーズ化TODOを元帳と同期させて維持します。元帳は詳細な真実のソース（依存関係、スコープ、コントラクト、エビデンス）であり、フェーズ化TODOはその進行状況ビューです。

分解グループごとに1つのフェーズを初期化し、その後最終受入フェーズを設定します（バグフローの場合：对照 / 修复 / 验证；機能フローの場合：機能グループの後に全量验收）。各項目は1つの範囲が定められたタスクまたは検証ステップであり、5～10語で成果として表現します。
プラットフォームのネイティブタスクリストで駆動し、手動でフォーマットされたツリーは使用しません。Claude/ompではtodoツールを使用します：list: [{phase, items}]でinitし、各項目でstart/doneを使用します。Codexでは、そのplan/update-planメカニズムを使用します。
実際の進行状況から状態を進めます：タスクが派遣されたら項目を進行中とマークし、コントローラーが元帳にcompletedを記録した後にのみ完了とします。フェーズカウント（N/M）は、派遣ではなく検証済みの受入を追跡します。
両方の一貫性を保ちます：1つのTODO項目は、元帳の1つのタスクまたは検証ステップに正確に対応します。再計画中に両方を一緒に再計算します。
analyzeおよびdiagnoseモードでは、フェーズは調査または診断のステップであり、それらを完了してもコードは変更されません。

成果物

公開可能なドキュメントと内部オーケストレーション状態を分離します：読み手向けのドキュメントはdocs/の下に配置し（docs/prd/仕様、docs/tech-design/設計）、元帳、計画、教訓は.ai-work/の下の内部作業状態とし — 決してdocs/の下には配置せず、公開可能なプロジェクトの場合はgitignoreします。references/deliverables.mdを参照してください。

重要なビルドの場合、仕様の後、executeの前に技術設計を作成します：アーキテクチャ、詳細設計、検討した代替案、横断的関心事（references/tech-design.md）。単一根本原因の修正で、仕様とタスクリストで十分な場合はスキップします。

生成されたMarkdown成果物は、引き渡し前に毎回自己レビューします：読み直し、読み手が見るようにレンダリングされることを確認します — 構造が整っていること、フェンス/ Mermaidブロックが実際にパースされること（目視ではなくレンダリング）、リンクが解決されること。パース/レンダリングの失敗は、今すぐ修正すべき欠陥です。references/deliverables.mdおよびreferences/verification.mdの「ドキュメント/図の成果物」行を参照してください。

成果物がスタンドアロンプロジェクトの場合、「完了」には公開可能であることが含まれます：README（何を/なぜ、前提条件、インストール、使用例、設定、アーキテクチャ、テスト、制限事項、ライセンス、免責事項）、LICENSE、およびビルド出力、シークレット、.ai-work/を除外する.gitignore。READMEのコマンドが実際に実行されることを確認します。references/deliverables.mdを参照してください。

対象システム事前チェック

ローカルのワーキングツリー以外のシステム（Wiki、チケットシステム、データベース、リモートAPI）に書き込みを派遣する前に、事前に以下を確認します：

書き込み権限と、計画された操作に必要な正確なスコープ（計画に削除や移動が含まれる場合はそれらも含む）。
レート制限と、障害がサイレントかどうか。安全な並行性とリトライまたはバックオフを選択します。
結果を読み戻して検証できること。

不足している機能は、バッチの途中ではなくここで発見してください。必要な権限またはスコープが利用できない場合は、ブロッカーとして扱います：何が不足しているかと、ブロックを解除する最小の許可を正確に述べ、部分的な適用の前に停止します。

プラットフォームルーティング

Codexの場合、references/codex-adapter.mdを読んでください。
Claudeの場合、references/claude-adapter.mdを読んでください。
それらの間で制御を移行する場合、古いコントローラーが派遣を停止する前に、ハンドオフスナップショットを書き込み確認します。
Trellisはオプションです。references/trellis-adapter.mdは、そのエスカレーションシグナルが適用される場合、またはユーザーが要求した場合にのみ読んでください。

不可譲の境界

これらは、表現に関わらずMUST NOTレベルの不変条件です。少数かつ明確に保ってください。このスキルの他の部分では、ルールの強度をRFC 2119キーワード（MUST / SHOULD / MAY）で格付けし、大文字の場合にのみ意味を持ち、節度を持って使用します：MUST / MUST NOTは正確性や危害のために予約し、好みはSHOULD / MAYとして残します。各禁止には、「代わりにこれを行う」という肯定的な指示をペアにします：エージェントにとって、否定のみのルールは信頼性が低く（禁止する行動を誘発する傾向があるため）、少数のハードな境界と肯定的なデフォルトが堅牢な形式であり、増え続ける必須チェックリストではありません。

タスクツリーの位置を実行依存関係として扱ってはいけません。
ワーカーが黙って書き込みスコープを拡大することを許可してはいけません。
依存関係が解決され、書き込みスコープが重複せず、共有コントラクトが固定され、検証が独立している場合を除き、書き込みエージェントを並列で実行してはいけません。
ワーカーはレビューのために作業を提出できますが、完了とマークできるのはコントローラーのみです。
既存のアーティファクトを変更する場合、タスクが作成しておらず再生成できないものをクリアして書き換えてはいけません。その場で挿入またはパッチを適用し、再実行安全なマーカーでマークし、独立した読み戻しで検証します。
検証されたソースを超えて、派生値（分類、ラベル、要約、リスク評価、推奨）を主張してはいけません。未検証の派生は、値を捏造するのではなく、そのようにマークします。
.trellis/が存在するという理由だけでTrellisをアクティブにしてはいけません。
analyzeおよびdiagnoseは読み取り専用です。プラットフォームの権限やネイティブ計画の承認は編集を許可しません。ユーザーからの別の指示が実装を承認した後にのみ、executeを開始します。
成果物を、読み手が読むように消費せずに引き渡してはいけません — ドキュメントをレンダリングし、README/使用コマンドをリポジトリルートから記述されたとおりに実行します。（代わりに行うこと：図をレンダリングし、コマンドを実行し、引き渡し前に破損を修正します。）
スタンドアロンプロジェクトは、機能するREADME、LICENSE、.gitignoreがない状態、または内部の.ai-work/アーティファクトがコミットされた状態で完了と呼んではいけません。（代わりに行うこと：公開可能な足場を提供し、オーケストレーション状態をリポジトリの外に保持します。）

要件オーケストレーター