audit-issue-scope

1つの親課題を子課題と複数の PR に分けて進めると、同じ事実が課題の本文・課題のコメント・PR のタイトルと本文・補足コメントに散らばります。どれかを直すと、残りに古い記述が残ります。このスキルは親課題の範囲をまとめて照らし、食い違いと、もっと良くできる箇所を洗い出す入口です。

直す手順は持ちません。見つけたものは、対象ごとの既存のスキルで直します（手順4）。

進め方

1. 範囲を集め、ファイルに落とす

集めるもの	取り方
親課題と子課題の本文・コメント	課題管理ツールの API。子課題は親の本文の表と、親子の関係の両方から拾う
関わる PR	親の計画の表、各課題の「Pull Request」の欄、PR 本文の参照（ owner/repo#123 ）。リポジトリをまたぐ
PR ごとの状態	gh pr view <PR> --json title,body,state,isDraft,baseRefName,headRefName,mergeable,files
PR の自分のコメント	issues/<PR>/comments と pulls/<PR>/comments （インラインは line も取る）

会話の記憶で照らさない。 取ったものをスクラッチパッドのファイルへ書き、照らすのはスクリプトと grep で行う。課題も PR も、他のセッションや人が今日のうちに直していることがある。

閉じた PR は照らす対象にしない（ no_operating_on_others_prs.md ）。他人の PR と、他人が起票した課題の本文は、読んで食い違いを報告するだけにする。

2. 他のセッションがいれば、分担を決めてから始める

同じ親課題を別のリポジトリのセッションが進めているなら、ListAgents で探し、持ち主で分ける（ notify_related_repo_sessions.md ）。

受け持つもの	担当
自分のリポジトリの PR	自分
課題の本文	本文を書いたセッション
全体の並び（親の表・各課題・各 PR）	どちらか一方に決める

相手の受け持ちで見つけたものは、根拠（ファイル・行・SHA）を添えて送る。直すのは相手に任せる。

3. 観点ごとに照らす

下の表は上限ではない。 照らしているうちに別の食い違いが見つかったら、それも拾う。

観点	照らすもの	確かめ方
並び	親の計画の表・各課題の「出す順番」・各 PR の「位置付け」・実際の base と GitHub のスタック	baseRefName と、スタックがあれば gh api repos/OWNER/REPO/pulls/<PR> の stack。「積んでいる」「上に」「先に」と書いた行を全部拾って照らす。切り離した PR は、相手側の本文にも古い記述が残りやすい
衝突	mergeable	CONFLICTING を拾う。上に PR を積んだ下段は、rebase ではなく merge で取り込めば上段の差分は変わらない
同じ変更を2本で出した組	hotfix 用と main 用のように中身が同じ PR	課題ごとにどちらの番号で書いたかを揃える
タイトル	各 PR のタイトルと本文の「何が変わるか」	作り直した PR は本文だけ直してタイトルが古いまま残りやすい。もっと伝わる形があれば直す（ /update-pr-description の手順4）
約束	PR 本文の「〜を消す」「〜で解く」「後の PR で〜」	今の差分か、名指しした PR の差分で果たされているかを見る
パスと識別子	本文と課題が挙げるファイル・関数・テスト	差分か head に実在するかを機械的に照らす。0件だったら、実在しないパスを混ぜた対照で照合が動いていたことを確かめる（ verify_the_check_worked.md ）
時点付きの数	課題の「重さ」の行数・件数・見込み	書いた後に差分が動いた PR だけ数え直す。files からテストを除いた数も出す
記述と実装	課題の「作り方」「画面では確認しないもの」が言う上限・権限・テストの置き場	実装の定数・認可・テストのファイルを git grep <語> <ブランチ> で引く
妙に見える実装	周りと1か所だけ形が違う実装	直す前に経緯を遡る（ verify_before_asserting.md の「妙に見える実装は、直す前に変更の経緯を遡る」）。別のブランチで直されていることがある
補足コメント	自分のインラインの [fyi]	載せ直しで元の行から外れたもの（ line が null）と、今の差分では要らなくなったもの
課題に書いた PR の状態	課題の本文とコメント	「マージ済み」などの状態を書いていないか。順番とマージの前の条件で書く（ keep_records_current.md ）
CI	ready の PR の最新の head	失敗がコードによるものか、承認待ちかまで見る。draft では一部の検査が走らないリポジトリがある

4. 直す

見つけたものは、対象ごとに既存のスキルで直す。ここで手順を書き直さない。

対象	直し方
PR のタイトル・本文・自分の補足コメント	/update-pr-description
課題の自分のコメント	/update-backlog-comments
PR の差分（約束の未達・妙な実装・衝突）	直してから /finalize-prs に PR を指定して渡す
課題の本文	自分が書いた本文なら直す。他人が起票したものはコメントで訂正を残す（ verify_before_asserting.md ）
他のセッションの受け持ち	根拠を添えて送る

push・投稿は、ユーザーがこの確認を頼んだことを、直すことへの指示として扱う。ただし差分の直し方が割れるもの（実装の方針を変える・PR を分ける）は、AskUserQuestion で尋ねてから直す。

5. 報告

観点ごとに、見たものと結果を1つの表にする。 食い違いが無かった観点も「無し」と書く。何を見たかが分からないと、見ていない観点と区別できない。

列	中身
観点	手順3の表の行
見た範囲	課題の番号・PR の番号・件数
結果	無し / 直した（コミットの SHA・コメントの URL） / 相手へ送った / ユーザーの判断待ち

最後の1行で、残りがあるかを書く（ summarize_after_each_task.md ）。

やってはいけないこと

• 会話の記憶で照らすこと。取り直したファイルで照らす
• 照らす段（手順1〜3）で書き込むこと（ gh api -X での更新・投稿・削除）。直すのは手順4で、各スキルを通す
• 照合が0件だったことを、対照を置かずに「食い違い無し」と書くこと
• 他人の PR・他人が起票した課題の本文を書き換えること
• 他のセッションの受け持ちを、黙って直すこと
• 直す手順をここで書き直すこと。各スキルを呼ぶ
• 見た観点を書かずに「確認しました」と報告すること

関連

• /list-prs （担当 PR の一覧）: あちらは自分の open な PR を状態で並べ、古い参照を洗い出す。本スキルは親課題の範囲で、課題と PR の記述どうしを照らす
• /plan-issue （着手前の整理）: あちらは手を付ける前、本スキルは PR と課題が揃った後
• /update-pr-description・/update-backlog-comments・/finalize-prs: 手順4の直し方。本スキルは見つけるまでを持つ
• keep_records_current.md （変えたら説明も直す）: 本スキルはその点検を、親課題の範囲でまとめて行う手段