recipe-design

明示的なユーザー指示：ユーザーは、このレシピで名前を指定した各サブエージェントの呼び出しを明示的に指示し、許可しています。前提条件が満たされたら、該当する各呼び出しを実行してください。

ドキュメントの振り分けや作成の前に、Skill: documentation-criteria を実行してください。 Agent のプロンプト、引き継ぎ、または生成物を作成する前に、Skill: llm-friendly-context を実行してください。 エージェントを呼び出す前、または指摘事項を解決する前に、Skill: subagents-orchestration-guide を実行してください。 最初の指摘事項を処置する前に、読み込んだ subagents-orchestration-guide スキルの references/review-resolution.md を読んでください。

成果と責任範囲

リポジトリの証拠に基づき、承認済みの設計ドキュメントに至るまで設計フェーズを調整します。ユーザーはプロダクト要件と除外事項を担当し、オーケストレーターは収束の準備状況、構造的規模、ADR の適格性、証拠の選定、レビュー解決を担当します。指名されたスペシャリストは、意味的な調査と成果物の作成を担当します。

設計ドキュメントは、中規模／大規模な作業における実装設計の全体を常に記述します。該当する ADR の一括作成では設計ドキュメントの前に技術的な選択肢を絞り込みますが、設計ドキュメントにはフロー全体と実装範囲を記載します。

要件：$ARGUMENTS

フロー

requirement source -> codebase-analyzer -> scope/decision confirmation [Stop]
                                             |
                               optional ADR batch -> batch review [Stop]
                                             |
                 Design Doc -> code-verifier -> Review Resolution
                                             |
                     document-reviewer -> design-sync -> approval [Stop]

前提となる証拠が揃ったら、依存する各ステップを実行してください。対応が必要な検証者、レビュアー、または設計同期からの指摘にはすべて、レビュー解決を適用してください。各 [Stop] では、ユーザーから明示的な確認を得るまで待機してください。

以下の各 Invoke では、エージェントのプロンプトを機械的に抽出して作成してください。指定されたソースの値を正確なフィールドにコピーし、宣言されたシリアライズのみを適用したら、直ちに呼び出してください。

ステップ 1：適用する要件ソースを選択する

承認済み PRD のパスがある場合は、それを使用してください。ない場合は、確認済みの要件をそのまま使用してください。

confirmed_requirement_context には、承認済み PRD のパスを正確に設定してください。承認済み PRD がない場合に限り、オーケストレーターが確認した収束記録を変更せずに使用してください。

ステップ 2：判断材料を収集する

dev-workflows:codebase-analyzer を呼び出してください。

prd_path: [approved PRD path]

または、承認済み PRD がない場合：

requirements: [confirmed requirements verbatim]

確認済みのスコープ全体を対象に、一度だけ呼び出してください。有効な JSON 結果を 1 つ要求し、影響を受けるパス、責任範囲の境界、レイヤー間の契約をアナライザーに特定させてください。アナライザーが示す重点領域は、既存の振る舞いを保護するためのものとして扱い、新たな要件として扱わないでください。

この独立した調査により、オーケストレーターが検証していない実装仮説ではなく、リポジトリの証拠に基づいてスコープと選択肢を収束させます。

ステップ 3：スコープと ADR の決定事項を確認する

スキル requirement-convergence を実行します。オーケストレーターは、ユーザーのリクエストとステップ 2 の証拠に基づいて収束記録を作成し、判定します。

4 つすべての収束フィールドを判定します。cost はステップ 2 の構造的な証拠に基づいて割り当て、不明点を記録します。ヒアリングを実施するのは、ready に達していないフィールドのみです。

結果と責任範囲の境界から構造規模を判断します。ファイル数は補足的な証拠としてのみ扱います。

decisionMaterials.candidateDecisionPoints を、適用される要件の根拠、simplifications、reuse、invalidations に照らして解決します。それらの証拠から、十分なアプローチが 1 つに絞られる場合は、その項目を除外します。残った各項目に対して、ドキュメント基準のフィルターを以下の順に適用します。

1. 確認済みスコープ内で、判断を要する、実質的に異なる信頼できる選択肢が少なくとも 2 つあること。
2. 選択に永続的かつ重大な影響があること。

両方のフィルターを通過したすべての項目を adrDecisionPoints として記録します。リストが空の場合は、Design Doc に直接進みます。ADR の作成対象は、両方のフィルターを通過した項目に限られます。

要件収束のスコープ確認を提示します。対象の責任範囲と、その最も強いファイル証拠、条件が適用される簡素化、各 ADR 決定事項のフィルター証拠、または none を Decision evidence に記載します。構造規模、その境界の根拠、および推奨するドキュメントの進行先を Workflow に記載します。

続行するか、スコープを修正して分析を再実行するかを提示します。回答によって収束フィールド、確認済みの結果、またはスコープが変わる場合に限り、質問をします。すべての収束フィールドが ready または weak-but-explicit になるまで続行しません。[Stop: Scope confirmation]。

ステップ 4：必要に応じて ADR バッチを作成し、承認を得る

adrDecisionPoints が空でない場合：

1. dev-workflows:technical-designer を次の正確な入力で 1 回呼び出します。document_to_create: ADRBatch、confirmed_requirement_context、ステップ 3 で確認済みの adrDecisionPoints を順序を変えずそのまま指定した decision_points、およびステップ 2 の decisionMaterials.candidateDecisionPoints にある対応するオブジェクトを、その順序で変更せずコピーした decision_materials。
2. dev-workflows:document-reviewer を次の正確な入力で 1 回呼び出します。doc_type: ADRBatch、targets: [all returned paths]、および confirmed_requirement_context。
3. 最初にレビュアーの判定に応じて進めます。pass の場合は issues: [] で続行します。needs_revision の場合はレビュー解決手順を適用し、各パスの ADR を順番に 1 件ずつ更新して、バッチ全体を再レビューします。rejected の場合は、再レビューの前に要件の根拠との矛盾を解決します。
4. pass のレビューを受けた後に限り、バッチの決定事項を 1 つ提示します。[Stop: ADR batch approval]。
5. ユーザーの承認後、各 ADR のステータスを Accepted に更新し、変更後のステータスを確認します。

ステップ 5：Design Doc を作成する

レビュー済みの成果物と、変更されていないリポジトリの証拠を基に、MVP 実装の完全な設計を作成します。これにより、オーケストレーターが作成した影の設計ではなく、承認済みの情報源に Design Doc を追跡可能な形で紐付けられます。

dev-workflows:technical-designer を、次の正確な内容で呼び出します。

• document_to_create: DesignDoc；
• confirmed_requirement_context；
• structural_scale；
• adr_paths: [accepted paths or []]；
• codebase_analysis: [complete Step 2 JSON unchanged]。

Design Doc は、エンドツーエンド設計全体を担い、ドキュメント基準テンプレートにある、適用可能なすべての下流の安全策を維持します。

ステップ 6：リポジトリに関する主張を検証して解決する

検証者の観察結果は変更せずに維持し、修正内容がオーケストレーターによる設計指示ではなく、観察されたリポジトリの証拠に基づいて追跡できるようにします。

doc_type: design-doc と Design Doc のパスを指定して dev-workflows:code-verifier を呼び出し、現在の前提と実現可能性を検証します。その際、計画された動作は意図として扱います。ドキュメントレビューの前に、すべての不一致に Review Resolution を適用します。apply の所見のみを、新しい Operation Mode: update、Existing Document: [Design Doc path]、および処置以外は変更していない所見全体を指定する correction_findings: [complete findings unchanged except for their dispositions] を指定して、technical-designer の更新呼び出しに渡します。所見に未検証の意思決定を左右する前提が含まれる場合、デザイナーはレビューを契機とする範囲限定の自己検証ゲートを適用します。この新しいデザイナーが唯一の修正担当者となり、証拠の収集経路を選択します。修正後は、前回の完全な結果、処置、および修正差分またはパスを prior_feedback として渡し、code-verifier を再実行します。最新の結果から、Review Resolution で定義された単一の verification_evidence オブジェクトを作成し、その収束条件に達した時点で続行します。

ステップ 7：レビューして承認する

次の正確な入力を指定して dev-workflows:document-reviewer を呼び出します。doc_type: DesignDoc、target、review_context: creation、元のユーザー要件をそのまま指定する requirements_verbatim、confirmed_requirement_context、codebase_analysis、およびステップ 6 の verification_evidence です。

• pass：続行します。
• needs_revision：Review Resolution を適用し、既存のパスと適用済みの所見全体を使って、新しい technical-designer 呼び出しで更新します。その後、影響を受ける範囲についてステップ 6～7 を再実行します。
• rejected：Review Resolution を通じて、技術上の優先される情報源との矛盾を解決します。確認済みの結果、将来に向けた要件、非目標をすべて同時に維持できず、ユーザーが変更内容を選択する必要がある場合に限り、ユーザーに確認します。

他の Design Doc との整合性を確認するため dev-workflows:design-sync を呼び出し、対応が必要な矛盾には Review Resolution を適用します。Design Doc が 1 つだけの場合は、SKIPPED と明確に報告します。

Design Doc、承認済みの ADR パス、解決済みの制約／対応見送り、および design-sync の結果を提示します。[Stop: Design approval]。

完了条件

• スコープと構造的な規模が、成果と責任範囲に基づいて確認されている。
• ADR は両方のフィルターを通過した意思決定ポイントに限って作成され、完全な一括分が 1 回のレビューと承認を受けている。
• ADR が必要かどうかにかかわらず、Design Doc が存在する。
• 該当する既存動作、契約、前提、同等性、および検証に関する保護策が Design Doc に反映されている。
• Review Resolution により、needs_revision の問題のみが修正作業に回されている。
• すべての停止ポイントで、ユーザーから明示的な確認を得ている。