reviewable-change

レビュー可能な変更

将来のレビュアーが差分から意図を再構成できるように変更を記述してください。

差分ごとに目的を1つにする

異なる種類の作業は分けてください。

• 動作の変更。
• リファクタリング。
• 名前の変更。
• 書式設定。
• 生成された出力。
• テストのみの変更。
• ドキュメントの変更。

広範なクリーンアップを機能開発に混ぜないでください。クリーンアップが必要な場合は、編集した箇所に限定し、必要な理由を説明してください。

意図を明確にする

意味のある編集は、それぞれ少なくとも次のいずれかに答えられるようにしてください。

• どのような依頼された動作を実装していますか？
• どのような既存のバグやリスクを取り除いていますか？
• どのような既存のパターンに従っていますか？
• どのような検証によって正しさを確認できますか？

意図と結び付けられない編集は削除するか、別の依頼された変更として分けてください。

差分のサイズを抑える

動作を示すために必要な最小限の差分を優先してください。次のことは避けてください。

• 小さな動作変更のためにファイルを書き換える。
• 機能開発中にリポジトリ全体でシンボル名を変更する。
• 変更していないコードの書式を変更する。
• コードを移動する必要性を確認する前に移動する。
• 2つ目の実際の呼び出し元が現れる前に抽象化を導入する。

大きな差分が避けられない場合は、レビュー可能な段階に分け、各段階の依存関係を明記してください。

レビュアーの独立性を保つ

エージェントの非公開の推論を根拠として頼らないでください。差分、テスト、計画、最終報告には、レビュアーが作業を確認できるだけの証拠を含めてください。

最終報告には次の内容を含めてください。

• 変更した動作。
• 変更したファイルまたはモジュール。
• 実行した検証。
• 意図的に影響範囲を広げた変更。
• 人による確認が引き続き必要なリスク。

完了の基準

差分に明確な目的が1つあり、動作の変更が広範なリファクタリングや書式変更のノイズと混在せず、意味のある編集がすべて意図に結び付いており、検証の根拠が確認でき、レビュアーがエージェントの隠れた推論を信頼せずとも変更を理解できる場合、その差分はレビュー可能です。