review-work

レビュー作業

要求された成果物を、証拠と技術的判断に基づいてレビューします。ユーザーが修正や実装を明示的に依頼した場合を除き、このスキルは読み取り専用です。

workflow-language.md、review-language.md、document-conventions.md、および必要に応じてresearch-ladder.mdまたはarchitecture-language.mdを使用してください。

対象範囲の特定

指摘を評価する前に、主な対象、比較対象、境界、求められる詳しさを特定してください。ブランチや差分のレビューでは、比較対象を確定し、時間のかかる分析に着手する前に対象範囲が空でないことを確認してください。境界を安全に特定できない場合に限り、質問してください。

• 計画レビュー・モード：計画の一貫性、実行可能性、対象範囲、検証可能性を判断します。依存関係、タスクと受け入れ基準の対応、前提条件、確定済みの決定との矛盾、計画間の責任範囲、レビューの配置、検証、ドキュメントのライフサイクルを確認してください。計画を安全に実行できない場合を除き、実装の証拠、文章の推敲、網羅的なエッジケース、アーキテクチャの再設計を求めないでください。
• 実装レビュー・モード：具体的なコード、テスト、ドキュメント、差分、または納品された成果物から始めます。関連する計画や最新のドキュメントは参照すべき情報として扱い、主なレビュー対象とはしません。
• 継続レビュー：受け入れ済みの修正、パッチノート、変更された範囲、未解決のリスク、および再び議論すべきでない確定事項に注目します。
• 独立レビュー：明示的な相互検証、または必須の新しいコンテキストでの実装レビューに使用します。可能な場合は、以前の指摘や作成者の結論より先に一次証拠を確認し、その後で照合してください。独立性が意図されているため、以前の指摘と重複することがあります。
• 臨時レビュー：ユーザーが指定したファイル一式、機能、ブランチ、コミット、またはコード以外の成果物に合わせて、同じ証拠重視の手法を適用します。

レビューメソッド

1. リポジトリの指示と信頼できる成果物を読みます。
2. リスクに応じて、実際の対象と、その呼び出し元、テスト、ドキュメント、または実行時の挙動を確認します。変更が環境変数、シークレット、ポート、スクリプト、セットアップコマンドに及ぶ場合は、影響を受ける開発者向けの実行／ビルド経路を、呼び出し元から見える契約として追跡します。
3. コード、差分、スキーマ、コマンド、一次資料のドキュメント、または焦点を絞った実行時チェックで前提を検証します。
4. 正確性の問題、要件の不足、安全でないライフサイクルの挙動、ドキュメントの乖離、テストの不足、セキュリティ／データ損失のリスク、保守性に関する重大な問題を探します。
5. 重複する証拠や矛盾する証拠を整理してから報告します。

新規実装のレビューでは、適切な範囲で構造を簡素化できるかも確認します。避けられる概念、分岐、可変状態、間接化、または大幅に単純化できる設計がないかを調べます。具体的で妥当な改善点のみを報告してください。これは別のレビュアーや固定の規模基準、あるいは当然のブロッカーを意味するものではありません。

変更が共有契約、永続化、セキュリティ、並行処理、デプロイ、または広く使われるインターフェースに及ぶ場合、影響範囲を任意の視点として活用してください。活用する場合は、リスクに応じて影響を受ける呼び出し元と利用側を追跡し、変更の安全性が依存する1つか2つの不変条件を特定して、最も低コストで安定した実際のインターフェースを通じて立証します。立証できなかった点は、残存リスクとして報告してください。既定ではリポジトリ全体の影響調査を行わないでください。

既定ではバランスの取れたレビューを行います。ユーザーが求めている場合、またはリスクや不確実性により追加コストが正当化される場合に限り、敵対的な観点からの掘り下げ、複数の視点、サブエージェント、調査、追加のレビューラウンドを加えてください。確認せずに有用な視点を推定してください。ただし、その選択によって範囲、所要時間、費用が大きく変わる場合は確認します。

サブエージェントの報告は手掛かりとして扱います。採用する実質的な指摘は、主担当のレビュアーが一次証拠に基づいて検証します。レビューのレビューをさらに依頼することはありません。

指摘の最低件数はありません。重複する問題はまとめ、対応可能な指摘は通常15件未満に抑えます。十分な範囲を確認した根拠があれば、問題なしとするレビューも有効です。

必須のフェーズレビュー

フェーズ終了時、または実装を直接レビューする場合：

• 独立したレビュアーには、新たなコンテキストを提供する必要があります。
• 対象範囲は、最新のパッチだけでなく、フェーズ全体またはフェーズ相当の実装です。
• Planで定義された影響の大きいチェックポイントを、このレビューの代わりにしてはなりません。
• ユーザーが別途実装を許可した場合に限り、指摘を修正します。
• 修正後は、変更箇所と残存リスクに照らして必要なレビュー範囲だけを再確認します。

ドキュメントと成果物のライフサイクル

Planに基づく実装では、現在のPlanが担当するドラフトとDoc Delta項目のみを確認します。無関係なドラフトについては言及してもかまいませんが、完了を妨げるものではありません。

ドキュメントとの乖離は指摘として報告し、黙って編集してはなりません。軽微な事実のずれは、直接修正するよう推奨できます。プロダクトに関わる、または実質的な乖離は、判断または実装が完了するまで完了を妨げます。

ブロッキング中の指摘、未完了の検証、担当するドキュメント作業、または未完了の実装が残っている場合は、Planの削除を提案しないでください。完了したPlanがアクティブなRoadmapに含まれていない場合は、最終レビューとドキュメント同期の後に、一度だけ削除するか確認します。アクティブなRoadmapがPlanを参照している場合は、完了可能な状態であることを報告し、Plan／Roadmapの変更は、別途許可されたワークフローの手順に委ねます。Roadmapの完了処理がクリーンアップの前提条件です。自動的に削除してはなりません。

出力

重大度の高い順に、検証済みの指摘を提示します。各指摘には、ファイル／行またはコマンドによる簡潔な根拠、重要である理由、具体的な影響、推奨する修正を含めます。明確な欠陥、妥当なトレードオフ、オーナーのポリシー判断を区別します。

実質的なレビューでは、簡潔なレビュー台帳を記載します。

• 対象範囲と検証内容
• レビュー評価：High、Medium、Low のいずれか
• 推奨事項
• 残存リスク

該当する場合に限り、計画、ドキュメント、ラウンド、調整、次回レビューの各項目を追加します。簡単なアドホックチェックでは、対象範囲と検証内容を含む簡潔な結論で十分です。N/A のひな形や長い記録は出力しないでください。指摘事項が残らない場合は、その旨を述べ、対象範囲と制約を明記してください。