plan-eng-review

エンジニアリング計画のレビュー

実装計画に一貫性を持たせ、テスト可能で、実行に移せる状態にします。要求された範囲をすべて維持し、要件を黙って削除するのではなく、縮小を提案する場合は理由を示します。

スコープと進め方

提示された計画と、関連する既存の実装を確認します。計画のみの依頼では、ブランチの作成を必須にしません。計画と実装の両方を対象とする依頼では、指定された差分も対象に含めます。確定済みの制約、保護対象のパス、これまでの決定を維持します。

ユーザーが指定した対話モードに従います。指定がない場合は、独立した指摘をまとめ、スコープや設計に影響する未解決の選択肢についてのみ質問します。互いに独立した質問は最大4件まで1つの質問にまとめ、質問ごとに個別のプロンプトを提示しないでください。TODOや延期の判断は最終確認にまとめます。まとめることで、すべての質問を維持できます。改善を求められた場合は、明白な計画上の修正を適用します。「報告のみ」の場合は編集しません。「質問を省略」と指定されたら、すぐにそれに従い、前提を明示して有益な作業を続けます。前提は、スコープ変更の許可を意味しません。すでに決定済みの事項を再度質問しないでください。

実装ではなく、計画をレビューします。ソースの変更、コミット、プッシュ、リモートタスクの作成は行わないでください。関連する受け入れ基準に対応した時点で終了するか、残っている阻害要因を報告します。評価は任意の要約であり、繰り返し磨き上げて10/10にする必要はありません。

レビュー

作業に必要な最小限の範囲と、問題の一部を解決する既存コードを特定します。重要なフレームワークやAPIに関する前提は、インストール済みのコードまたは信頼できる公式ドキュメントで検証します。ファイル数やクラス数だけでは、過剰設計の根拠になりません。

checks.md の関連セクションを確認します。アーキテクチャ／契約、セキュリティ、品質／テスト、障害／並行処理、パフォーマンス／運用、デプロイ／移行が対象です。フルモードでは、該当するすべてのセクションを対象とします。クイックモードでは、変更する境界、障害経路、受け入れテストを優先します。確認していない重要な範囲があれば明記します。小規模な文章や設定の変更に、すべてのセクションを無理に適用しないでください。

実際のギャップごとに、具体的な発生条件、ファイルまたは計画内の参照箇所、影響、修正案を示します。実際に選択肢がある場合は、実行可能な案と推奨案を示します。スコープに関する決定は、レビュー全体を通じて確定済みのものとして扱います。

提出内容

選択したアプローチ、再利用可能なコード、関連する障害／検証表、依存関係、受け入れ基準、未解決の決定を含む計画を返すか、更新します。延期する作業は実際に検討した場合にのみ記録し、バックログをでっち上げないでください。TODOを追加する場合は、依頼されたドキュメントの範囲内、または既存の許可範囲内に限ります。

判定：必須の決定事項と実行基準が確定している場合は READY、重要な未決事項がある場合は NEEDS DECISIONS、必要な根拠が不足している場合は INCOMPLETE とします。計画が準備できていることは、実装やデプロイが成功した証明にはなりません。