coding-review-simplify

コーディングレビューの簡素化

モデルを選ぶ前にブランチを選択します。コーディネーターの作業と決定論的なコマンドは、呼び出し権限の範囲内で進めます。割り当てられた実装担当またはレビュー担当のコンテキストで、この方法を適用します。実装担当は許可されたクリーンアップを行い、独立したレビュー担当は読み取り専用のままにします。この方法ではワーカーをディスパッチしません。ワーカーをディスパッチする場合は、shared/references/model-preview.md と、そこで承認された単一のルートスナップショットを使用します。ネストされたスキルとランナーは、選択やワーカーを追加せずにこれを利用します。

実装コンテキストが新しいうちに、完了した差分を引き締めます。結果は、より小さく一貫性のある形、または証拠を伴う具体的な懸念事項になります。次の利用者は、承認済みのレビュー計画です。

これは動作を維持するための作業です。新しいレビュー経路は作成しません。承認済みのルーティング計画により、後続の重点レビュー、境界レビュー、または詳細レビューが必要かどうかを決定します。

ワークフロー

1. タスクの受け入れ条件、変更ファイル、差分、すでに記録されている検証結果を確認します。変更箇所から始め、実際の境界を越える場合にのみ範囲を広げます。
2. 変更内容を、意図した観測可能な動作と照らし合わせます。バグ、リグレッション、保守上の落とし穴、データリスク、不十分な検証、または読者に重大な混乱をもたらす場合に限り、懸念事項として報告します。
3. 結果が動作を維持する場合に限り、簡素化します。証拠によって不要だと確認できない限り、信頼境界での検証、認可チェック、不変条件のアサーション、エンコーディング、アクセシビリティの保護策は維持します。削除する前に、ランタイムでの読み込みを含め、サポート対象の呼び出し元とエントリーポイントを確認します。削除によって副作用、失敗時の動作、必要な保護策が維持されることを示す証拠と、関連する検証結果を求めます。到達可能性が不明な場合、または維持されることを示す証拠がない場合は、削除しません。
4. 差分によってヘルパーが追加された場合、所有権が変わった場合、またはホットパスや非同期パスに影響する場合は、現在の役割で該当するレビュー上の懸念事項に対処します。その懸念事項に限り、references/personas/ から該当するペルソナを読みます。保存状態または非同期動作が変わる場合は、data-systems-coding-lens を適用します。重大なリスクがある場合、または未解決の疑問がある場合に限り、承認済みの経路を通じて独立した専門家をディスパッチします。
5. 差分が境界を越える場合、または絡み合っていると感じられる場合に限り、コンナセンスパスを実施します。何がコンナセントなのかを特定し、その強度、局所性、次数、および最小限の安全な対処法を述べます。抽出しても安全性が向上せず、間接性が増すだけなら、局所的な静的結合には手を加えません。
6. 境界全体に関わる設計上の懸念には、現在の役割で該当するレンズを適用します。この作業から、より広範なリファクタリングを始めてはいけません。
7. 受け入れた懸念事項ごとに、具体的な修正、テスト、チェック、または明示的なフォローアップに結びつけます。変更によって影響を受けた検証だけを再実行します。

簡素化の手がかり

clean-code の用語を使います。判断を伴わないヘルパー、不自然な契約を隠す型、不要なメモ化やエフェクト、呼び出し元のない互換性コード、無関係な差分の混入を探します。ラッパーより適切な名前を付けるほうがよい場合があります。概念が分岐する可能性があるなら、重複は残してかまいません。

出力

レビューのみの作業では、指摘事項を重大度順に列挙し、場所、影響、最小限で有効な修正、検証内容を記載します。

実装作業では、次の内容を返します。

1. 結果：現状のままで安全、簡素化済み、重点的な修正が必要、または設計上のエスカレーションが必要。
2. 実施した変更。
3. 記録した検証結果。
4. 残っているリスク。

引き継ぎまたはデプロイの直前に限り、references/team-checklists.md を使用します。削除した行数で成功を測らないでください。観測可能な動作を維持しながら、変更をより簡素にすることが基準です。