ai-code-changes

name	ai-code-changes
description	Use this skill when modifying existing code or before creating commits/PRs. Covers pre-change investigation (understand why existing code was written that way) and self-review checklist (correctness, consistency, comment quality, commit quality).
user-invocable	false

AI Code Changes: AI によるコード変更の品質基準

出典: MIT Missing Semester 2026 - Beyond the Code

変更前: 理解してから変更する

1. 変更の「Why」を把握する

コードを変更する前に、以下を明確にする:

• なぜこの変更が必要か？ — ユーザーの要求、バグ、機能追加の背景
• なぜ既存のコードがこう書かれているか？ — コメント、git blame、周辺コードから意図を読み取る
• 変更による影響範囲は？ — 依存関係、テスト、下流のコード

2. 既存の設計判断を尊重する

• コメントで「Why Not」が説明されている選択を安易に覆さない
• 定数にコメントがある場合、その根拠を確認してから変更する
• 「もっと簡単な書き方がある」→ まず既存の方法が選ばれた理由を調査する
• 耐荷重な選択（load-bearing choices）を識別する: 正確性に影響する実装詳細に注意

3. 変更を最小限に留める

• 依頼された変更だけを行う。「ついでに」の改善をしない
• フォーマット変更と機能変更を混ぜない
• リファクタリングが必要な場合は別コミットにする

変更後: セルフレビューチェックリスト

コードの正確性

• 変更が要求された動作を正しく実装しているか
• エッジケース（null、空配列、境界値）を考慮しているか
• 既存のテストが壊れていないか
• 新しいコードにテストが必要な場合、追加したか

既存コードとの整合性

• プロジェクトの命名規則に従っているか
• 既存のエラーハンドリングパターンに合わせているか
• インポート・依存関係の追加は必要最小限か
• 既存のコメントが変更によって不正確になっていないか（更新したか）

コメントの品質（code-comments スキル参照）

• 非自明なロジックに「Why」コメントを付けたか
• 明らかなアプローチを避けた場合「Why Not」を書いたか
• コードの「What」をそのまま繰り返すだけのコメントを書いていないか

コミットの品質（git-commits スキル参照）

• 論理的に独立した変更ごとにコミットを分けたか
• コミットメッセージに「Why」を書いたか
• フォーマット変更と機能変更が同じコミットに混在していないか

変更の影響

• 後方互換性を壊していないか（壊す場合は明示的に説明したか）
• パフォーマンスへの影響を考慮したか
• セキュリティの懸念はないか（入力検証、認証、SQLインジェクションなど）