recipe-review

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

エージェントのプロンプト、引き継ぎ、または生成物を作成する前に、スキル「llm-friendly-context」を実行してください。 ワークフローの判断、エージェントの呼び出し、または指摘への対応を行う前に、スキル「subagents-orchestration-guide」を実行してください。

コンテキスト：実装後の品質保証

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

中核となる役割：「私はオーケストレーターです。」

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

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

実行ゲート：ステップ 1〜10 を順番に完了し、記載された条件によって有効になった分岐のみを実行してください。レビュー、修正、再検証の各段階は、それぞれに定められた収束条件を満たした場合にのみ進めてください。該当するすべての指摘と、解消されずに残る品質上の制限が、必要な処置または再試行結果に達した後に、最終レポートを提示してください。

実行方法

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

オーケストレーターはサブエージェントを呼び出し、構造化 JSON を渡します。必要な成果に対して Design Doc が古い、過剰、または不正確な場合は、設計側の経路を適用してください。どちらの経路でも、既存の実装や以前の設計をデフォルトで正しいものとして扱ってはいけません。

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

Design Doc：$ARGUMENTS

実行フロー

ステップ 1：前提条件の確認

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

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

ステップ 2：code-reviewer を実行

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

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

出力を次の名前で保存：$STEP_2_OUTPUT

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

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

• subagent_type: "dev-workflows: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 に直接進みます。

承認された指摘事項、振り分け先、対象となるファイル／セクション、および提示された合計サイズの上限を、更新または修正を行うエージェントに渡します。再検証の前に、すべての差分ハンクを、承認された指摘事項または必要な整合性更新に対応づけます。対応づけられない意図しない変更は削除します。必要な変更によって、確認済みの値の境界または明示されたサイズ制約が変更される場合は、要件変更検出に戻ります。

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

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

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

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

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

   • subagent_type: "dev-workflows:document-reviewer"
   • description: "更新された Design Doc の文書レビュー"
   • prompt: "更新された [path] の Design Doc を一貫性と完全性の観点からレビューしてください。doc_type: DesignDoc。review_context: update。"
   • 修正後の再レビューと収束への遷移を含め、Review Resolution Gate を実行します。再振り分けされた修正には technical-designer を使用します。収束条件を満たした場合にのみ先へ進みます。

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

   • subagent_type: "dev-workflows:design-sync"
   • description: "Design Doc 間の一貫性チェック"
   • prompt: "source_design: [updated DD path]"
   • sync_status: CONFLICTS_FOUND の場合は、Review Resolution Gate を適用し、制限付きの検証担当への引き継ぎと収束のルールに従います。

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

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

ステップ 6：修正の実行

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

• subagent_type: "dev-workflows:task-executor"
• description: "レビュー修正の実行"
• direct_scope: 確認済みのレビュー範囲および指定された合計サイズの予算内で、承認済みのコード側の修正を適用します
• governing_sources: レビュー済みの Design Doc と、承認済みの要件または ADR のパス
• target_paths: 承認済みのコード側の振り分けについて確認された実装およびテストのパス
• observable_verification: 指摘および適用される基準資料で指定された、対象を絞ったテストまたは観測可能な契約チェックに合格します
• correction_findings: レビュアーの指摘オブジェクト全体を原文どおりに渡し、追加するのはオーケストレーターによる処置のみとします

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

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

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

quality-fixer の結果を振り分けます。

• pass → ステップ 8 に進みます
• stub_detected → incompleteImplementations を変更せずにステップ 6 に戻り、その後ステップ 7 を繰り返します
• verification_incomplete → 結果全体を保持してステップ 8 に進みます
• blocked → Specialist Result Acceptance を適用します

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

この呼び出しの直前に、ステップ 1 の包含ルールを適用して implementationFiles を再導出し、承認済みの修正によって追加または変更された実装成果物を含めます。

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

• subagent_type: "dev-workflows: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: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 の制限ごとに、同じステップ 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]

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