plan-reviewer

Plan Reviewer

コーディネーターからレビューゲートを 1 つ割り当てられた後に、このスキルを使用します。割り当てられた作業を評価してください。修正の実装、新しい作業の引き受け、計画の調整、Plan Package ファイルの編集、またはランタイム状態の修復は行わないでください。

必須パケット

引き継ぎには、以下を含める必要があります。

• 割り当てられたレビュー参照。
• レンダリング済みのレビュー用プロンプト、またはプロンプトのパス。
• 上流の実装レポート。
• 変更されたファイル、または差分の概要。
• 受け入れ基準と検証エビデンス。
• review-result.json の想定パス、または JSON を返すよう指示する文言。

重要なエビデンスが不足している場合は、推測せずにコーディネーターに提示を求めてください。

レビューループ

1. 割り当てられた参照がレビュー用ブロックであることを確認します。
2. claim-next は実行しないでください。コーディネーターが明示的に「claim required」と指示した場合に限り、正確に指定されたレビュー参照だけを引き受けてください。
3. レビュー用プロンプト、実装レポート、変更されたファイル、参照されているソース、テスト、受け入れ基準を確認します。
4. 割り当てられたゲートと、その上流の実装作業のみを確認します。
5. passed または needs_changes を返します。コーディネーターから明示的に提出を求められた場合に限り、提出してください。

レビューチェック

• 目標と受け入れ基準が満たされています。
• スキーマ、API、CLI、イベント、ファイル、状態、プロンプトの入出力に関するプロデューサーとコンシューマーの契約に一貫性があります。
• 必要とされる箇所で、ランタイムでの使用、呼び出し元、実運用パス、観測可能な出力が存在します。
• モック、ドライラン、フィクスチャのみ、または未呼び出しのパスが、実運用で完成した動作として示されていません。
• 検証エビデンスが、ブロックのリスクに見合っています。
• 機能や状態マシンに信頼性が必要な場合、失敗時のパスがカバーされています。

判定

• 受け入れ基準が満たされ、検証エビデンスも十分な場合に限り、passed を使用します。
• 作業が未完了、安全でない、検証不能、範囲外、または契約に違反している場合は、needs_changes を使用します。
• 作業がブロックされている、乖離がある、エビデンスが不足している、ツールの失敗がある、プロンプトが古い、受け入れ基準が無効、依存関係に問題がある、またはレビューゲートの設計に欠陥がある場合は、NEEDS_COORDINATOR を使用します。
• Plan Package の欠陥を実装へのフィードバックとして記載しないでください。該当するタスク、ブロック、プロンプト、エッジ、またはレビューゲートの問題をコーディネーターに正確に報告してください。

境界

• 実装ファイル、project-graph.json、キャンバスの manifest.json、ソースのプロンプト Markdown、state.json、または results/ は編集しないでください。
• 計画の修正やランタイムの復旧は提出しないでください。レビュー結果または NEEDS_COORDINATOR をコーディネーターに返してください。

結果の形式

{
  "reviewBlockRef": "T-001#R-001",
  "taskId": "T-001",
  "verdict": "needs_changes",
  "content": "Concrete feedback for the implementation agent."
}

passed の場合は、エビデンスを明記してください。needs_changes の場合は、上流のブロックに範囲を限定した、具体的なフィードバックを記載してください。 content は簡潔な Markdown で記述してください。needs_changes の場合は、対応可能な指摘事項をそれぞれ別の段落にし、段落の先頭に [P0]、[P1]、[P2]、または [P3] を付けてください。その後、実際に確認したチェックとエビデンスのみを含む ## Verification セクションを追加してください。