recipe-front-design

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

ドキュメントの振り分けまたは作成の前に、スキル「documentation-criteria」を実行します。 エージェントのプロンプト、引き継ぎ、または生成アーティファクトを書く前に、スキル「llm-friendly-context」を実行します。 エージェントの呼び出しまたは指摘事項の解決の前に、スキル「subagents-orchestration-guide」を実行します。 最初の指摘事項の処置を行う前に、読み込んだ subagents-orchestration-guide スキルの references/review-resolution.md を読みます。

成果と担当範囲

エビデンスから適用可能な UI Spec および承認済みの Design Doc まで、中規模／大規模のフロントエンド設計を調整します。ユーザーはプロダクト要件と対象外事項を管理し、オーケストレーターは収束の準備状況、Structural Scale、ドキュメントの振り分け、ADR の適格性、エビデンスの選定、および Review Resolution を管理します。指名された専門エージェントは、意味上の調査とアーティファクトを担当します。

フロントエンドの Design Doc には、常に実装設計全体を記載します。ADR バッチでは、適格な技術的選択に対象を絞ります。適用可能な UI Spec では、これから設計する UI の構造と動作を記載します。

要件：$ARGUMENTS

フロー

requirement source -> codebase-analyzer -> scope/document routing confirmation [Stop]
                                               |
                             conditional UI analysis -> UI Spec review [Stop]
                                               |
                                   optional ADR batch/review [Stop]
                                               |
              Design Doc -> code-verifier/Resolution -> document-reviewer
                                               |
                               design-sync -> approval [Stop]

対応が必要な指摘事項はすべて Review Resolution を使用します。各 [Stop] で、ユーザーの明示的な確認を待ちます。

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

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

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

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

ステップ 2：リポジトリの設計判断に関する資料を収集する

確定した対象範囲全体について、dev-workflows-frontend:codebase-analyzer を 1 回呼び出します。prd_path: [approved PRD path] を正確に指定するか、承認済み PRD がない場合は requirements: [confirmed requirements verbatim] を正確に指定します。

有効な JSON 結果を 1 つ求め、影響を受けるパス、責任範囲の境界、およびレイヤー間の契約をアナライザーに特定させます。focusAreas は既存の動作を保護するための情報として扱い、要件とはみなしません。

この独立した調査により、オーケストレーターの未検証の実装仮説ではなく、リポジトリのエビデンスに基づいて対象範囲と選択肢の収束を進められます。

ステップ 3：UI Spec の適用可否を判断し、UI のエビデンスを解決する

documentation-criteria の UI Spec 作成条件を適用します。条件に該当しない場合は、UI 分析とステップ 5 をスキップします。

UI Spec が適用される場合、外部リソースによって現在の UI の方向性、コンポーネントの契約、または検証の境界が変わる場合に限り、external-resource-context を読み込み、適用します。それ以外の場合は external_resource_refs: [] を使用します。

未解決の承認済み UI 判断を示す場合、または要件、リポジトリの UI、記録済みリソースから対象を特定できない場合に限り、プロトタイプコードを求めます。任意のプロトタイプがないことは停止条件ではありません。

次のうち、適用するソースを 1 つだけ指定して dev-workflows-frontend:ui-analyzer を呼び出します。

prd_path: [approved PRD path]

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

requirements: [confirmed requirements verbatim]

既存の ui_spec_path、判断に関連する prototype_path、および選定済みの external_resource_refs または [] のみを追加します。

ui_spec_path: [existing UI Spec path]
prototype_path: [decision-relevant path]
external_resource_refs: [selected references or []]

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

スキルを実行します：requirement-convergence。適用される要件の情報源、リポジトリ分析、該当する UI 分析に基づいて、収束記録を作成し、判定します。

4 つの収束フィールドすべてを判定します。ステップ 2 の構造的な根拠から cost を割り当て、不明点を記録します。ヒアリングは ready 未満のフィールドのみを対象にします。

結果と責任範囲の境界から Structural Scale を判断します。ファイル数は補足的な根拠としてのみ扱います。候補となる決定ポイントを、適用される要件の情報源、コード／UI の simplifications、reuse、invalidations と照合して解決します。該当する UI の事実は、残る選択肢を支持または否定する根拠となる場合があります。この収束の後にのみ、文書化基準の Choice と Durability のフィルターを適用し、合格したポイントを adrDecisionPoints として記録します。空のリストも有効です。

要件収束のスコープ確認を提示します。影響を受ける責任範囲、条件を伴う該当する簡素化、条件を満たす ADR ポイント、または none を Decision evidence に記載します。Structural Scale、UI Spec の適用可否、推奨する文書ルートを Workflow に記載します。続行するか、修正して再実行するかを提示します。回答によって収束フィールド、確認された結果、またはスコープが変わる場合にのみ質問します。すべての収束フィールドが ready または weak-but-explicit になった場合にのみ続行します。[Stop: Scope confirmation]。

ステップ 5：UI Spec を作成して承認する

ステップ 3 で UI Spec が適用されると判断された場合にのみ、このステップを実行します。

dev-workflows-frontend:ui-spec-designer を正確な入力で呼び出します：

confirmed_requirement_context: [the value fixed in Step 1]
ui_analysis: [complete Step 3 UI analyzer JSON unchanged]
codebase_analysis: [complete Step 2 codebase-analyzer JSON unchanged]
prototype_path: [decision-relevant path from Step 3 exactly, or absent]
prototype_reference_strength: [binding | reference, present with a prototype_path]
external_resource_refs: [selected Step 3 reference records unchanged, or []]

dev-workflows-frontend:document-reviewer を正確な入力で呼び出します：doc_type: UISpec と、ui-spec-designer が返した UI Spec のパスを変更せずに target として指定します。pass の場合は issues: [] を伴う UI Spec を提示します。needs_revision の場合は Review Resolution を適用し、修正後に再レビューします。rejected の場合は、再レビューの前に要件の情報源との矛盾を解決します。[Stop: UI Spec approval]。

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

adrDecisionPoints が空でない場合：

1. 共有／バックエンドが担当するポイントを先に technical-designer に割り当て、その後、フロントエンドが担当するポイントを technical-designer-frontend に割り当てます。各担当者は、正確な入力で呼び出します：document_to_create: ADRBatch；confirmed_requirement_context；ステップ 4 で確認された、その担当者に対応する順序付きの decision_points（変更せずに指定）；対応するステップ 2 の decisionMaterials.candidateDecisionPoints オブジェクトを同じ順序で変更せずにコピーした decision_materials；その担当者の決定を承認済み UI Spec が制約する場合にのみ ui_spec_path。後続のバッチが先行バッチの後に ADR 番号を割り当てるよう、担当者ごとのバッチを順次実行します。
2. 返されたすべてのパスを集め、dev-workflows-frontend:document-reviewer を正確な入力で 1 回呼び出します：doc_type: ADRBatch、targets: [all paths]、および confirmed_requirement_context。決定のレビューに影響し得る場合、レビュアーは ADR が参照する承認済み UI Spec に従います。
3. まずレビュアーの判定を確認します。pass の場合は issues: [] で続行します。needs_revision の場合は Review Resolution を適用し、各パスにつき ADR を 1 件ずつ順次更新し、バッチ全体を再レビューします。rejected の場合は、再レビューの前に要件の情報源との矛盾を解決します。
4. pass のレビュー後にのみ、バッチ全体の決定を提示します。[Stop: ADR batch approval]。
5. ユーザーの承認後、すべての ADR のステータスを Accepted に設定し、ステータスが更新されたことを確認します。

ステップ 7: フロントエンド設計ドキュメントの作成

レビュー済みの成果物と変更されていないリポジトリ/UI の証拠から、フロントエンド MVP 実装の完全な設計を作成します。これにより、Design Doc はオーケストレーターが作成したシャドウ設計ではなく、承認済みのソースに対してトレーサブルに保たれます。

dev-workflows-frontend:technical-designer-frontend を次のとおり正確に呼び出します:

• document_to_create: DesignDoc;
• confirmed_requirement_context;
• structural_scale;
• 該当する承認済みの ui_spec_path を正確に、および選択された外部リソース参照レコードを変更せずに;
• adr_paths: [accepted paths or []];
• codebase_analysis: [complete Step 2 JSON unchanged];
• ui_analysis: [complete Step 3 JSON unchanged; omit when absent]。

Design Doc はコンポーネントからサービスまでの実装全体を所有し、該当するすべての下流のセーフガードを保持します。

ステップ 8: 検証、レビュー、承認

検証者の所見を変更せずに保つことで、修正がオーケストレーターが作成した設計指示になるのではなく、観察されたリポジトリの証拠に対してトレーサブルに保たれます。

dev-workflows-frontend:code-verifier を doc_type: design-doc および document_path に technical-designer-frontend から返された Design Doc のパスを変更せずに指定して呼び出し、計画された動作を意図として扱いつつ、現在の前提と実現可能性を検証します。ドキュメントレビューの前に Review Resolution を適用し、適用された所見を新規の technical-designer-frontend 更新呼び出しに Operation Mode: update、Existing Document: [Design Doc path]、および correction_findings: [complete findings unchanged except for their dispositions] を指定して送信します。設計者は、未検証の意思決定を変える前提に対して、レビューによってトリガーされる限定付きの自己検証ゲートを適用します。この新規の設計者が唯一の修正スペシャリストであり、証拠ルートを選択します。適用された修正の後に、前回の完全な結果、ディスポジション、および修正の差分またはパスを prior_feedback として検証を再実行し、その後、最新の結果から 1 つの verification_evidence オブジェクトを構築します。Review Resolution の収束条件で続行します。

dev-workflows-frontend:document-reviewer を次の正確な入力で呼び出します: doc_type: DesignDoc; target には返された Design Doc のパスを変更せずに; review_context: creation; 元のユーザー要件を変更せずに requirements_verbatim として; ステップ 1 の confirmed_requirement_context を変更せずに; 設計者に提供したものと同じ変更されていない codebase_analysis および任意の ui_analysis; そしてステップ 8 の verification_evidence を変更せずに。レビュアーは、Design Doc が引用する該当する UI Spec および承認済み ADR パスに従うのは、それらがスコープ内の所見を変更し得る場合に限ります。

• pass: 続行します。
• needs_revision: Review Resolution を適用し、既存のパスと完全な適用済み所見を使用して新規の technical-designer-frontend 呼び出しを通じて更新し、影響を受ける境界について検証/レビューを再実行します。
• rejected: Review Resolution を通じて技術的な統治ソースの競合を解決します。確認済みの成果、望ましい将来の要件、および非ゴールのすべてが真のままであり得ず、ユーザーがどちらを変更するかを選択しなければならない場合にのみ、ユーザーに尋ねます。

dev-workflows-frontend:design-sync を source_design に返された Design Doc のパスを変更せずに指定して呼び出し、実行可能な競合に Review Resolution を適用し、Design Doc が 1 つだけ存在する場合は SKIPPED を明確に区別して報告します。

該当する UI Spec、Design Doc、承認済み ADR パス、解決済みの制限/辞退、および同期結果を提示します。[Stop: Design approval]。

完了条件

• 外部の証拠とプロトタイプの証拠は、現在の判断を左右する場合にのみ求められています。
• 範囲と構造規模は、成果と責任範囲に基づいて確認されています。
• ADR は両方のフィルターを通過した項目にのみ作成され、一括レビューと承認を受けています。
• ADR が必要かどうかにかかわらず、該当する UI Spec と完全なフロントエンド設計書が存在しています。
• 既存の UI の動作、契約、前提条件、状態、同等性、検証のためのセーフガードのうち該当するものが、設計書に反映されています。
• レビューでの対応では、needs_revision の課題のみが修正作業に回されています。
• すべての停止ポイントで、ユーザーから明示的な確認を得ています。