recipe-front-review

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

Agent プロンプト、ハンドオフ、または生成物を作成する前に、Skill：llm-friendly-context を実行してください。 ワークフローの判断、エージェントの呼び出し、または指摘事項の解決を行う前に、Skill：subagents-orchestration-guide を実行してください。

コンテキスト：React/TypeScript フロントエンドの実装後の品質保証

オーケストレーターの定義

基本的な役割：「私はオーケストレーターです。」（subagents-orchestration-guide スキルを参照）

ローカル権限ゲート：このレシピのワークフローを判断し、返された各結果を直接検証します。成果物の意味的な作成は、指定された専門家に委任します。

レビュー解決ゲート［必須］：修正または次の段階への進行前に、対応が必要な成果物レビューの指摘事項をすべて、subagents-orchestration-guide の Review Resolution を通じて解決してください。 最初の指摘事項の処置を決める前に、読み込んだ subagents-orchestration-guide スキルの references/review-resolution.md を読んでください。

実行ゲート：Step 1～10 を順番に完了し、記載された条件によって有効になった分岐のみを実行してください。各レビュー、修正、再検証の移行は、定められた収束条件に達した場合にのみ進めてください。該当するすべての指摘事項と、継続する品質上の制約について、必要な処置または再試行の結果に至った後、最終レポートを提示してください。

実行方法

• 実装レビュー → code-reviewer が実施
• セキュリティ検証 → security-reviewer が実施
• コード側の修正経路：実装の修正 → task-executor-frontend、品質チェック → quality-fixer-frontend、再検証 → code-reviewer / security-reviewer
• 設計側の更新経路：DD の改訂 → technical-designer-frontend（更新モード）、DD レビュー → document-reviewer、DD 間の整合性 → design-sync（複数の DD がある場合）、再検証 → code-reviewer

設計ドキュメントが古い、過剰である、または必要な成果に対して誤っている場合は、設計側の経路を適用します。どちらの経路でも、既存の実装または以前の設計をデフォルトで正しいものとはみなしません。

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

Design Doc：$ARGUMENTS

実行フロー

Step 1：前提条件の確認

現在のブランチとリポジトリのデフォルトブランチとのマージベースから、現在のリポジトリ状態までの間に変更されたパスを基に、implementationFiles を導出してください。コミット済みの変更、ワーキングツリーの変更、未追跡ファイルを含めます。implementationFiles には、レビュー対象の動作を実装または検証する内容を含むパス、あるいはそのスキーマ、ビルド、デプロイ、実行時の動作を制御するパスをそれぞれ含めます。ソースファイル、テスト、マイグレーション、実行可能なスクリプト、動作に影響する設定が該当します。統括文書と Work Plan は、文書の選定と統括文書の入力に関するそれぞれの役割を維持します。タスクファイルとドキュメントのみのパスは、このレシピにおけるコードレビューおよびセキュリティレビューの対象外です。

$ARGUMENTS で明示的に指定された Design Doc を使用してください。指定がない場合は、まず、宣言された対象ファイルまたは責任範囲が implementationFiles と重なる Work Plan を使用し、そこに記録された Design Doc のパスを取得してください。それによって候補が1つに絞られない場合は、docs/design/ にある唯一の Design Doc を使用してください。統括する Design Doc が複数残る場合に限り、候補を提示してください。該当するものがない場合は、前提条件が不足していることを報告してください。

Step 2：code-reviewer を実行

Agent ツールを使用して code-reviewer を呼び出してください。

• subagent_type：「dev-workflows-frontend:code-reviewer」
• description：「完了したフロントエンド実装のレビュー」
• prompt：「完了したフロントエンド実装をレビューしてください。governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. 初回レビューの JSON を返してください。」

出力の保存先：$STEP_2_OUTPUT

ステップ 3：security-reviewer を実行する

Agent ツールを使って security-reviewer を呼び出します。

• subagent_type: "dev-workflows-frontend:security-reviewer"
• description: "セキュリティレビュー"
• prompt: "governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. セキュリティへの準拠をレビューしてください。"

出力の保存先：$STEP_3_OUTPUT

ステップ 4：判定と応答

いずれかのレビュアーがブロックされた結果、またはその他の理由で使用できない結果を返した場合は、subagents-orchestration-guide の Specialist Result Acceptance をその意味上の原因に適用します。残る検証上の制限だけをレポートに引き継ぎます。

レポートまたは振り分けを行う前に、両方の出力に Review Resolution Gate を適用します。指摘への対応方針によって振り分け先が決まります。

apply 指摘ごとに、以下のルールに基づいて推奨ルートを算出します。選択した修正によって設計上の記述と、その記述で認められた実装の両方を削除する場合、指摘のルートは d と c の両方になります。

指摘のパターン	推奨ルート
元の要件に合致し、古くなった Design Doc を修正するため、現行の実装を維持する解決策	d（設計側の更新）
受け入れ可能な状態にするため、実装の変更が必要な解決策	c（コード側の修正）
必要な結果に不要な、Design Doc が選択した仕組みを削除する解決策	d と c（まず設計上の記述を修正）

その後、裁定結果をユーザーに提示します。apply 指摘は推奨ルートごとにまとめ、却下した ID とその理由を列挙します。

Implementation Review: [verdict from code-reviewer]
  Acceptance Criteria:
  - [fulfilled] [item]: [evidence]
  - [unfulfilled] [item] -> [corresponding finding ID under Required Corrections]
  Required Corrections:
  - [id] [category] [location]: [description] — [basis and effect] [recommended: c | d | d and c]
  Limitations:
  - [unverified judgment and effect]

Security Review: [status from security-reviewer]
  Findings by category:
  - [confirmed_risk] [location]: [description] — [rationale] [recommended: c]
  - [defense_gap] [location]: [description] — [rationale] [recommended: c]

Approve the proposed changes:
  c) Code-side correction — change implementation to reach the accepted state
  d) Design-side update   — correct a stale, excessive, or incorrect Design Doc
  d and c) Reduction     — delete the selecting design statement, then remove the implementation it authorized
  s) Decline              — record the governing reason and accept current state

このレビューコマンドで許可されるのは分析のみです。AskUserQuestion を使って、実装に関する別個の許可を得てください。一括オプションは 「提案されたすべての apply ルートを承認する」 であり、その範囲はそれらのルートだけです。承認された変更セットが空の場合は、直接ステップ 10 に進みます。

承認された指摘、ルート、対象ファイル／セクション、および明示された合計サイズ上限を更新エージェントまたは修正エージェントに渡します。再検証の前に、差分のすべてのハンクを、承認された指摘または必要な整合性更新に対応付けます。対応付けられない偶発的な変更は削除します。必要な変更によって確定済みの値境界または明示的なサイズ制約が変わる場合は、Requirement Change Detection に戻ります。

ステップ 5：設計側の更新

ユーザーが少なくとも 1 件の指摘を d に振り分けた場合にのみ、このステップを実行します。d への振り分けがない場合はスキップし、承認済みの c への振り分けが残っている場合にのみステップ 6 に進みます。

1. Agent ツールを使用して、更新モードで technical-designer-frontend を呼び出します。

   • subagent_type: "dev-workflows-frontend:technical-designer-frontend"
   • description: "レビュー指摘に基づく設計書の更新"
   • prompt: "更新モードで、[path] にある Design Doc を更新します。次の指摘を設計に反映してください：$STEP_2_OUTPUT からの d に振り分けられた指摘オブジェクト全体（承認済みの振り分け先以外は変更しないでください）。指摘が現在のコードを受け入れる内容であれば、該当するセクションにその動作を反映してください。不要な仕組みを削除する指摘であれば、それを選択した記述を削除してください。履歴項目を追加してください。"

2. document-reviewer を呼び出して、更新された Design Doc を検証します。

   • subagent_type: "dev-workflows-frontend:document-reviewer"
   • description: "更新された Design Doc のドキュメントレビュー"
   • prompt: "更新された [path] の Design Doc に一貫性と完全性があるかレビューしてください。doc_type: DesignDoc。review_context: update。"
   • 修正後の再レビューと収束への遷移を含め、レビュー解決ゲートを実行します。振り分け直された修正には technical-designer-frontend を使用します。収束条件を満たした場合にのみ続行します。

3. docs/design/ に複数の Design Doc がある場合は、design-sync を呼び出します。

   • subagent_type: "dev-workflows-frontend:design-sync"
   • description: "Design Doc 間の一貫性チェック"
   • prompt: "source_design: [更新された DD のパス]"
   • sync_status: CONFLICTS_FOUND の場合は、レビュー解決ゲートを適用し、定められた検証担当への引き継ぎと収束ルールに従います。

4. ステップ 5 の完了後：

   • ユーザーがすべての指摘に d を選択した場合（c への振り分けがない場合）→ ステップ 6〜7 をスキップし、再検証のためステップ 8 に進みます。
   • ユーザーが d と c の両方を選択した場合 → 更新された DD に照らして c に振り分けられた指摘を再評価し、DD の改訂で満たされたものは除外します。削減のコード削除は、DD の改訂だけでは満たされたことになりません。その後、残った c の指摘とともにステップ 6 に進みます。

ステップ 6：修正の実行

Agent ツールを使用して task-executor-frontend を呼び出します。

• subagent_type: "dev-workflows-frontend:task-executor-frontend"
• description: "レビュー修正の実行"
• direct_scope: 確認済みのレビュー範囲および提示された合計規模の予算内で、承認されたフロントエンドの修正を適用します。
• governing_sources: レビュー済みの Design Doc、該当する UI Spec、および承認された要件または ADR のパス
• target_paths: 承認されたコード側の振り分け先として確認された実装およびテストのパス
• observable_verification: 指摘および関連する根拠資料で指定された、対象を絞った UI 動作テストまたは観測可能な契約チェックが成功すること
• correction_findings: オーケストレーターによる処理内容のみを追加し、レビュー担当者の指摘オブジェクト全体をそのまま渡します。

ステップ 7：品質チェック

Agent ツールを使用して quality-fixer-frontend を呼び出します。

• subagent_type: "dev-workflows-frontend:quality-fixer-frontend"
• description: "品質ゲートチェック"
• ステップ 6 の direct_scope、governing_sources、observable_verification、correction_findings の入力を変更せずにコピーします。
• ステップ 6 の mutationEvidence を渡します。

quality-fixer-frontend の結果を次のように処理します。

• pass → ステップ 8 に進みます。
• stub_detected → incompleteImplementations を変更せずにステップ 6 に戻り、その後ステップ 7 を繰り返します。
• verification_incomplete → 結果全体を保持してステップ 8 に進みます。
• blocked → スペシャリスト結果の受け入れ手順を適用します。

ステップ 8：code-reviewer による再検証

この呼び出しの直前に、ステップ 1 の対象範囲ルールに従って implementationFiles を再導出し、承認済みの修正で追加または変更された実装成果物が含まれるようにします。

Agent ツールを使用して code-reviewer を呼び出します。

• subagent_type："dev-workflows-frontend:code-reviewer"
• description："フロントエンド実装レビューの再検証"
• prompt："承認済みの修正後に、完了したフロントエンド実装を再レビューしてください。governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. prior_feedback: [{id, disposition, reason?, evidence}]. 受け取ったすべての項目を照合してください。"

ステップ 9：security-reviewer による再検証

この呼び出しの直前に、ステップ 1 の対象範囲ルールに従って implementationFiles を再導出し、承認済みの修正で追加または変更された実装成果物が含まれるようにします。

subagents-orchestration-guide の実装後の 再実行ルールで最新のセキュリティ結果が必要とされる場合は、Agent ツールを使用して security-reviewer を呼び出します。

• subagent_type："dev-workflows-frontend:security-reviewer"
• description："セキュリティの再検証"
• prompt："修正後のセキュリティを再検証してください。governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. prior_feedback: [{id, disposition, reason?, evidence}]. レビュアーの再レビュー対象範囲に基づき、すべての既存項目を照合してください。"

ステップ 10 に進む前に、ステップ 8 とステップ 9 の各結果に Review Resolution Gate を適用します。その maintained 遷移に従い、修正の振り分け先が変更された場合は、影響を受ける検証を繰り返します。Review Resolution が親要件または権限ゲートに移行する場合は、それを適用し、収束条件に達した時点で先に進みます。

ステップ 10 の前に、保持されている各 quality-fixer-frontend の制限事項について、同じステップ 7 の入力と影響を受けるチェックを使って、もう一度再試行します。再試行が pass を返した場合は、その制限事項を保持状態から削除します。新たに未完了の実装が見つかった場合は、ステップ 6〜9 に振り分け、verification_incomplete が繰り返された結果として報告します。再試行によってリポジトリが変更された場合は、報告前に変更後のコードに対してステップ 8〜9 を繰り返します。

ステップ 10：最終報告

最終報告を提示します。

Implementation Review:
  Initial: [verdict from code-reviewer]
  Correction review: [verdict for the re-review scope] (if fixes executed)
  Reconciliation: [resolved / withdrawn / maintained by finding ID]

Security Review:
  Initial: [status]
  Correction review: [status for the re-review scope] (if fixes executed)
  Reconciliation: [resolved / withdrawn / maintained by finding ID]

Quality Check:
  Final: [pass / verification_incomplete / not_run when no code-side fixes were selected]

Remaining proof limitations:
- [reason — affected check and evidence] (only when repeated after retry)

Declined actionable findings:
- [ID: governing reason — evidence] (only when any were declined)

Remaining issues:
- [items requiring manual intervention]

対象範囲：完了したフロントエンド実装レビュー、セキュリティレビュー、およびユーザー承認済みの修正振り分け。