レビュースコープ

レビュースコープスキル

目的

コード変更が意図されたとおりの動作をすることを検証する — それ以上でもそれ以下でもありません。 これはパス/フェイルゲートであり、フィードバックセッションではありません。

使用するタイミング

• TDD検証フェーズ
• スコープ準拠のためのPRレビュー
• スコープ検証が必要なコードレビュー全般

必要な入力

context_files

• 実装計画または要件文書
• 設計書（利用可能な場合）
• レビュー対象の変更ファイル

context_data

• commit_details: この変更が行うべきこと
• requirements: 対応するREQ-*のリスト
• constraints: 満たすべきCC-*制約のリスト
• allowed_files: 変更が許可されるファイル（スコープ境界）

手順

1. スコープ境界の確立

入力から以下を特定する：

• 実行しなければならないこと（要件）
• 実行してはならないこと（制約）
• 変更してもよいファイル
• 期待される動作

2. 変更のレビュー

変更された各ファイルについて：

1. このファイルは許可されたセットに含まれているか？
2. 変更は明示された要件に対応しているか？
3. 要件に関係ない変更が含まれていないか？
4. 変更は制約に違反していないか？

3. 結果の報告

すべてのチェックに合格した場合:

ACCEPT

いずれかのチェックが失敗した場合、違反を列挙する:

VIOLATIONS:
- <ファイル>:<行> - <説明（自分の言葉で）>
- <ファイル> - <説明>

[オプション] THEMES: <注目に値するパターン>

違反の形式

違反は、場所と明確な説明を添えて自然に記述する：

- src/parser.rs:45 - コミットスコープに含まれないロギングインフラを追加
- src/config.rs - 許可セット外のファイルを変更

違反にまたがるパターンに気づいた場合は、それを指摘する：

THEMES: 複数の変更が、明示された要件を超えてエラーハンドリングのリファクタリングに及んでいる

最小変更バイアスチェック

実装エージェントは、目標を達成するために可能な限り最小の変更を行うバイアスを持っています。 違反を特定した後、次のことを考慮する：

違反は、コードをより保守しやすくするための潜在的なリファクタリングを示唆していないか？ 実装者は、より良い構造的解決策を避けて、簡単な修正を優先していないか？

該当する場合は、REFACTORINGセクションにこれを記録する：

REFACTORING: <実装者が避けた構造的改善の説明>

これは違反ではなく、オーケストレーターが検討するためのフラグです。

このスキルが行わないこと

• 違反に関係のない改善を提案する
• 一般的な建設的フィードバックを提供する
• コードスタイルをレビューする（その場合は review-style を使用）

これは二値ゲートです：ACCEPT または VIOLATIONS。リファクタリングノートはオプションのフラグであり、ブロッカーではありません。