issue-status
自分が担当している GitHub issue を棚卸しして、1 件ずつ「今どこで止まっているか・誰の対応待ちか」を表にまとめる。あわせて、次の作業に使える空き worktree を表にする。
設定（使う前に書き換える）
worktree は、リポジトリごとに 1 つの親フォルダにまとめておく前提で動く。
| 項目 | 値（例） |
|---|
| base ブランチ | main |
| worktree の親フォルダ | ~/develop/<リポジトリ名>-worktree/ |
親フォルダが無いリポジトリでは git worktree list の全部を出す。ツールが自動で作る worktree（例: .claude/worktrees/ の下）は表に入れない。
この skill が生まれた背景（守るべき教訓）
- ブランチ／PR の有無だけで状況を判断したら間違えた。 「PR が無い＝未着手」と決めつけたが、実際にはコメントで質問を投げて相手の回答待ちだったり、本人が調査中で方針を練っていたりした。必ず各 issue のコメントを 1 件ずつ読む。
- 事実だけを書く。 「優先度を上げた方がいい」「先に動いた方がいい」のような判断・提案は添えない。誰が何を言ったか、今ボールはどちらか、という事実だけ。
- 平易な日本語で短く。 表にして一目で分かる形にする。専門用語・英語のステータス語を並べない。
いつ使うか
「担当 issue の状況」「自分のチケットの今」「何が止まってる」「ボールどっち」など、自分の持ち issue を一覧で把握したいとき。番号指定があればその範囲だけでもよい。
手順
0. worktree の空き状況を取る（毎回必ず出す）
issue の棚卸しと必ずセットで、worktree の空き状況も出す。並行開発しているなら、次にどのフォルダで着手できるかを一緒に知りたいはずなので、省かない。
状態を取る
git fetch -q origin # origin/<base> を最新にしてから比べる
for p in <worktree の親フォルダ>/*/; do
b=$(git -C "$p" branch --show-current) # 空なら detached
m=$(git -C "$p" status --porcelain | grep -v '^??' | wc -l | tr -d ' ')
u=$(git -C "$p" status --porcelain | grep '^??' | wc -l | tr -d ' ')
git -C "$p" merge-base --is-ancestor HEAD origin/<base> && inbase=yes || inbase=no
echo "$p | [${b:-detached}] | 変更 ${m} 未追跡 ${u} | base に含まれる: ${inbase}"
done
「空き」の決め方
次の 2 つを両方満たすフォルダを「空き」と書く。
- 変更も未追跡も 0 件。
- 次のどれかに当てはまる。
- HEAD が origin/<base> に含まれている。
- そのブランチの PR がマージ済み（squash マージだと含まれないので、手順 3 の PR 一覧で確かめる）。
- コミットが全部 push 済みで、そのブランチの issue が閉じている（課題が完了している）。
それ以外は「○○ 作業中」と書く。未追跡だけ残っていて PR がマージ済みのものは、「#N マージ済み・未追跡 N件」と事実をそのまま書く。1 issue = 1 branch なので、着手前にここで既存ブランチ／worktree の重複を確認する。
空きのフォルダで着手するとき・終わったとき
# 着手: 空きのフォルダで、origin/<base> から新しいブランチを切る
git -C <空きのフォルダ> fetch -q origin
git -C <空きのフォルダ> switch -c <feat/N-xxx> origin/<base>
# PR がマージされたら: base の最新に戻して空きにする（変更が無いことを確かめてから）
git -C <フォルダ> fetch -q origin
git -C <フォルダ> switch --detach origin/<base>
.env のように git に入れていないファイルは worktree に無い。新しく作り直したときはメインフォルダからコピーする。
1. 自分とリポジトリを特定する
gh api user --jq .login # 自分の login
gh repo view --json nameWithOwner -q .nameWithOwner # 今のリポジトリ
以降 REPO はこの nameWithOwner。
2. 担当の open issue を取る
gh issue list --repo <REPO> --assignee @me --state open \
--json number,title --jq '.[] | "\(.number)\t\(.title)"'
番号を指定されているときはその issue だけを対象にする。
3. 自分の PR を取って issue に対応づける
gh pr list --repo <REPO> --author @me --state all --limit 50 \
--json number,state,isDraft,title,body \
--jq '.[] | "PR#\(.number)\t\(.state)\tdraft=\(.isDraft)\trefs=\([.body|scan("(?i)#[0-9]+")]|join(","))\t\(.title)"'
注意: リポジトリによっては PR 本文の Closes #N が GitHub に自動リンクされておらず、closingIssuesReferences が空で返る（その場合マージしても issue は自動で閉じない）。たとえば PR の向き先がデフォルトブランチ以外だと、自動リンクは効かない。だから対応づけは PR 本文を #N でスキャンして結びつける。closingIssuesReferences だけに頼らない。
これで「どの issue にどの PR がぶら下がっているか」「その PR は open / draft / merged のどれか」が分かる。マージ済みなのに issue が open のままなら 閉じ漏れの可能性として後で印を付ける。
4. 各 issue のコメントを 1 件ずつ読む（軽いモデルのサブエージェントを並列で）
ここが肝。issue ごとにサブエージェントを 1 つ立て、全部同じターンで並列に投げる。内容を読んでまとめるだけなので、軽いモデル（Claude Code なら model: sonnet）で十分。各サブエージェントへの指示テンプレート：
GitHub issue <REPO> #<N> の現在の状況を、本文とコメントを実際に読んで報告してください。推測しないこと。
1. gh issue view <N> --repo <REPO> --json title,body,state,assignees,labels,comments \
--jq '{title,state,assignees:[.assignees[].login],labels:[.labels[].name],body,comments:[.comments[]|{author:.author.login,createdAt,body}]}'
2. コメントに画像 URL（user-attachments/assets など）があれば存在を記録。状況判断に要りそうなら言及。
3. 事実だけ・平易な日本語で簡潔に報告:
- 何の依頼か（1〜2行）
- コメントのやり取りの要点（誰が・いつ・何を、時系列で）
- 今のボール（誰の対応待ちか）／止まっている理由・決まっていること
- 担当者がすでに着手・回答・対応しているか（コメント上の証拠ベースで）
判断・提案・優先度の意見は添えない。事実と出典（コメント日時・発言者）だけ。
CI bot（github-actions など）の自動コメントは「人のやり取り」と区別する。最後の人間コメントが誰かでボールを判断する。
5. まとめて表にする
3（PR の状態）と 4（コメントから読んだ実態）を突き合わせて、issue ごとに 1 行にまとめる。状況欄には「どの段階か＋今ボールが誰か」を書く。
出力フォーマット
issue の状況表と worktree の空き状況表を両方出す。
issue の状況
| issue | 内容 | 状況 |
|---|---|---|
| #101 | ログイン画面の文言 | PR #120 レビュー中・指摘対応済み → レビュアーのマージ待ち |
| #102 | 一覧の並び順 | 起票者に3点質問中（並べる基準/向き/保存するか）→ 相手の回答待ち |
| #103 | CSV 出力の文字化け | PR #125 マージ済み＋追加分 #128 が下書き |
| #104 | 検索結果の件数表示 | PR #125 マージ済み（issue 開いたまま＝閉じ漏れの可能性） |
worktree の空き状況（毎回出す）
| フォルダ | ブランチ | 未コミット | 用途 |
|---|---|---|---|
| my-app（メイン） | feat/101-... | 1件 | #101 作業中 |
| my-app-worktree/wt1 | main | 0件 | 空き |
| my-app-worktree/wt2 | feat/103-... | 0件 | #103（push 済み・clean） |
| my-app-worktree/wt3 | chore/try-xxx | 3件 | 試し中 |
表の下に 2〜3 行で全体像（例: PR が動いてるのが N 件、相手の回答待ちが N 件、本人検討中が N 件、閉じ漏れ N 件、着手に使える空き worktree が N 件）。ここでも提案はしない。状況の要約だけ。
やってはいけないこと
- ブランチ／PR が無いだけで「未着手」と書く（コメントを読まずに段階を決めつける）。コメントを読めば「質問して回答待ち」「本人が調査中」などが分かる。
- 事実報告に判断・優先度・「こうした方がいい」を混ぜる。
- 英語のステータス語やツール名を並べた読みにくい表にする。
- CI bot の自動コメントを人のやり取りと混同してボールを誤る。
- 番号指定があるのに担当 issue 全部を勝手に広げる。