self-review-diff

ユーザーが編集を伴わない監査を求めている場合を除き、明確でリスクの低い問題は修正します。リスクの高い変更や新しいコミットを行う前に確認してください。

調査

該当する AGENTS.md のガイダンスを読み、次を調査します。

git status --short
git branch --show-current
git diff
git diff --staged
git ls-files --others --exclude-standard

未追跡ファイルは直接読みます。HEAD が存在する場合は、git diff HEAD と最終的なファイルの内容を調べ、ステージ済み・未ステージの変更が相互に与える影響を確認します。無関係な編集とステージングの意図は保持します。

ユーザーが範囲を限定していない限り、ローカルの変更をすべてレビューします。指定された重点項目があれば、そこを優先します。周辺のコードやテストを読み、影響を受ける呼び出し元をたどります。

レビューの基準点を確立します。依頼された機能がすでにコミットされている場合は、その機能を含むコミットまたはブランチ差分を調査します。作業ツリーがクリーンであっても、レビューを行ったことにはなりません。レビューのメモは、製品ドキュメントではなく、回答または一時的な作業領域に記録します。

監査と修正

作成者ではなく、敵対的な視点でレビューします。問題が見つからなくなるまで、変更が壊れているものとして扱ってください。コミットメッセージ、コメント、名前、テストの成功、意図に関する自身の記憶を鵜呑みにせず、コードの実際の動作で判断します。変更された各単位について、失敗を引き起こす入力、状態、順序を考えます。

確認項目：

• 正しさ、エッジケース、並行処理、エラー処理、リグレッション。
• セキュリティ、プライバシー、互換性、ロールアウトの安全性。
• パフォーマンス、古いコード、重複、可読性、サイズが大きすぎるファイル。
• 関連するテストカバレッジ、過剰な（不要な）テストカバレッジ、リント、明白でない不変条件に関するドキュメント。
• UI のアクセシビリティ：ラベル、ロール、状態、コントラスト、テキストの拡大、フォーカス、ナビゲーション、タップ領域、動き。
• AGENTS.md に記載されていない、長期的に有効なワークフロー上のルールや落とし穴。

境界をまたぐ契約をたどる

状態を持つ処理、非同期処理、外部との連携については、呼び出し元から処理、返却される結果やイベント、最終的な UI または永続化された状態まで、変更された動作をたどります。受理、完了、再試行、正とする状態の管理主体を特定します。検出、事前確認、実行、復旧で意図した ID とスコープが使われ、検証済みの遷移が保たれていることを確認します。

一般的なチェックリストに頼らず、リスクの高い具体的なシーケンスを選びます。

• 開始元の呼び出しが戻る前に処理が完了した場合、その後の継続処理が完了済みのターンを復活させたり、新しい状態を上書きしたりしないこと。
• 変更処理は成功したものの応答が失われ、その後の復旧読み取りも失敗した場合、副作用を重複させずに、受理が確認された状態、明確な拒否、結果不明を区別すること。
• await 中にキャンセル、置き換え、削除、選択の変更が発生した場合、公開または変更する前に、正とする状態を再取得すること。
• イベントが重複、遅延、順不同で届いた場合、処理の失敗とセッション／プロセスの失敗を区別し、保留中と解決済みのやり取りの両方を調整すること。

変更に関連するシナリオだけを使用します。バグの疑いがある場合は、具体的な発生条件と観測可能な結果を示し、その問題を反証することも試みます。発生条件に到達可能であり、すでに防止されていないことを確認してください。反証された指摘は、報告を水増ししないよう除外します。確認も反証もできない指摘には「未検証」と明記します。ヘルパーだけを検証するアサーションでは配線の不具合を見逃すことがあるため、実際のエントリーポイントと呼び出し元を通る決定論的な再現を優先します。タイミング待ちではなく、既存のテスト用の仕組みでイベントの順序を制御します。ある経路を修正した後は、変更後の動作の影響を受ける関連経路と呼び出し元を調査します。

対象範囲内のフォーマットや誤字、小規模で既存のヘルパーを使うテスト、明らかに不足しているアクセシビリティメタデータ、未使用であることが確認されたプライベートコードの削除、サポート対象の不変条件を説明するコメントは、自動的に修正します。

動作、契約、永続化、生成コード、ロールアウトのロジック、UI の操作やレイアウト、スナップショット、テストの期待値や基盤、公開ドキュメント、AGENTS.md を変更する前には、必ず確認してください。また、大規模なリファクタリングやフォーマッターの実行、動的に参照されているコードの削除についても、事前に確認してください。保留した指摘は、該当ファイル、リスク、推奨する修正方法を添えて報告します。

検証して繰り返す

関連する最小限のリンター、テスト、型チェック、またはスナップショットを実行します。対象範囲に変更がない合格済みのチェックは再利用し、失敗したチェック、不完全なチェック、または確信が持てないチェックは再実行します。スキップしたチェックについて説明します。検証に失敗した場合、依頼がない限り修正はコミットせずに残します。

検証の根拠を、レビュー対象の契約に対応させます。テストされていない順序や複合的な失敗が対象になっていなければ、テストスイートに合格したことやテスト数が多いことだけでは、網羅性の証明になりません。ユーザーが許可した範囲内で、確認された動作上の不具合に対する、的を絞った回帰テストを追加します。影響の小さい編集について、テストケースをむやみに増やしてはいけません。

各パスでステータスと差分を最新の状態に更新し、HEAD が存在する場合は git diff --check、git diff --staged --check、git diff HEAD --check を実行します。未追跡のテキストは git diff --no-index --check -- /dev/null "<file>" でチェックします。終了コードが 1 でも出力が空なら問題ありません。バイナリは通常の成果物チェックで検証します。

最終変更について、クリーンなパスを連続して2回行う必要があります。2回目のパスでは、1回目の前提に疑問を投げかけ、修正を利用側まで追跡します。必要に応じて、別の失敗順序も確認します。空白のチェックを繰り返したり、同じ正常系を読み直したりすることは、別のレビューにはなりません。修正後は最初からやり直し、未解決または再発する問題があれば停止して報告します。

コミット

ユーザーのコミットに関する希望に従います。希望がない場合は、検証後に変更を所有するコミットを amend します。変更を所有するコミットがなければ、修正はコミットせずに残します。所有者が不明確な場合は確認します。

detached HEAD でのコミット、スタック外の先端ではないコミットの書き換え、または複雑なリベースには、明示的な指示が必要です。リベースの続行では GIT_EDITOR=true を使用します。依頼がない限り、プッシュや gh stack push、submit、sync の実行は禁止です。

gh stack の場合：

• gh stack view --json が成功し、branches[].name に現在のブランチが含まれる場合にのみ使用します。終了コード 2 は追跡対象のスタックがないことを意味します。対話型の view と modify は避けます。終了コード 10（未完了の modify セッション）の場合は、gh stack modify --abort で復旧します。
• 変更を所有するブランチにチェックアウトし、git commit --amend で amend した後、そのブランチから gh stack rebase --upstack を実行して下位ブランチを更新します。複数のリモートがあり、remote.pushDefault が設定されていない場合は、対象の --remote <name> を指定します。
• リベースが終了コード 3 で終了した場合は、内容を理解したうえで競合の解決をステージし、gh stack rebase --continue を実行します。--abort はすべてのブランチを復元します。確信を持って解決できない競合は報告します。

対象範囲とベースライン、修正内容、残る指摘、クリーンなパスの回数、実行・再利用・スキップした検証、コミットとスタックの状態を報告します。該当する場合は「レビュー対象範囲に指摘事項はありません」と記載します。検証済みの動作と未調査のパスまたは残る検証上の不足を区別し、クリーンなレビューは網羅的な正しさの証明ではないことを明示します。