sweep

name	sweep
description	ai-fixable が付いた open Issue を1件ずつ片付け、コミットして close する。人間が `/sweep` と打ったときだけ起動する。
argument-hint	[件数 or Issue番号（省略可・複数可）]
disable-model-invocation	true

/sweep

ai-fixable が付いた open Issue を古い順に1件ずつ直し、Issue ごとにコミットして close する。起動は人間の明示呼び出しに限るが、起動後は最後まで人間への確認なしに自律実行する。

/quick-issue は「割れ窓を見えるようにする」ためのスキルで、見えた窓を塞ぐ担当がいなければ Issue は積み上がるだけになる。本スキルがその担当である。

前提

• 始めるタイミングは人間が握る。 一度に多数の Issue とコミットへ触れるため、いつ走らせるかは作業状況を見て人間が決める。
• ブランチは切らない。 現在のブランチでそのまま作業する。
• 1 Issue = 1 コミット = 1 close。 途中で止まっても、完了した Issue までは履歴と Issue 状態が一致する。
• 他の Issue の変更を混ぜない。 ステージするのは、その Issue で自分が編集したファイルだけ。

処理フロー

Phase 1: 対象の決定

gh issue list --state open --limit 50 --search 'label:ai-fixable label:boy-scout -label:"issue:needs-clean-session"' --json number,title --jq 'sort_by(.number) | .[] | "\(.number)\t\(.title)"'

issue:needs-clean-session を除外するのは、過去の /sweep が着手したうえで「一括では直しきれない」と判定した印だから。同じやり方で選び直しても同じ結果になる（2-2 参照）。

label:boy-scout を条件に足すのは、/to-issues 産の Issue（ai-fixable は付くが boy-scout は付かない）を一斉対応から除くため。正式フローで計画した Issue は、対応する開発フロー Skill（/code-dev 等）で個別に着手する。

引数の解釈は次のとおり。

引数	対象
なし	一覧の全件
数字1つ（≤20）	一覧の古い順にその件数
Issue番号の列	その Issue だけ（ラベルの有無を問わない）

対象が0件なら、その旨を伝えて終了する。決めた対象リストを表示してから Phase 2 へ進む。

Phase 2: 1件ずつ処理する

対象を古い順に1件ずつ、次の 2-1 〜 2-6 を最後まで通してから次の Issue へ移る。複数 Issue を並行して編集しない（コミットが混ざるため）。

2-1. 本文を読む

gh issue view <番号> --json title,body,labels

読む順は「対応方針」→「タスク一覧」→「現状」。方針を決め直さない。 本文の「対応方針」に書かれた採る案どおりに直す。

2-2. 中断条件の判定

中断には2種類ある。本文を読んだ時点で分かるものと、着手して初めて観測できるものである。後者は 2-3 / 2-4 の作業中に観測したら、ここへ戻って同じ手順を踏む。

着手前に分かる中断条件——次のどれかに当たったら直さずに中断し、ラベルを貼り替えて次の Issue へ移る。

中断条件	対応
起票の名指し例外に当たる（判定は quick-issue の「どちらを付けるか」 が正）	gh issue edit <番号> --add-label issue:needs-human-decision --remove-label ai-fixable
「対応方針」が無い、または方針が本文から読み取れない	同上
前提が変わって現物と食い違う（対象箇所が既に無い等）	Issue にコメントを残し、close せず残す

着手後に観測する離脱条件——次のどれかに当たったら、その Issue はこのセッションでは直しきれない。編集したファイルを git checkout -- <パス> で戻し、ラベルを足して次の Issue へ移る。

離脱条件	なぜ一括では直せないか
修正が、本文の「対象箇所」に無い箇所へ波及した	影響範囲が本文の想定を超え、判断が要る
2-4 の検証が落ち、原因がその場で読めない	原因を追うには混んでいない文脈が要る
同一セッションで何件も処理していて、文脈が混んでいる	直せるかどうかではなく、品質が落ちる

gh issue edit <番号> --add-label "issue:needs-clean-session"

ai-fixable は外さない。 AI が直せることは変わらず、変わるのは一括で直せるかどうかだけである。ラベルが付いた Issue は Phase 1 の検索から外れるので、同じセッションで選び直されることはない。

状況	貼るラベル	ai-fixable
方針そのものを人間が決め直す必要がある	issue:needs-human-decision	外す
方針は本文どおりでよいが、一括では直しきれない	issue:needs-clean-session	残す

貼ったときは、なぜ中断・離脱したかを Issue にコメントで残す。理由が無いと、次に開いた人は入口が分からないまま Issue を読むことになる。

issue:needs-clean-session を貼った Issue は、人間が別のセッションで Issue 番号を渡して着手する（CLAUDE.md「issue番号だけで開発フローを自動追従する」）。

2-3. 直す

Issue 本文の「実装フロー（使用するSkill）」に Skill が書かれていれば、その順に実行する（CLAUDE.md「issue番号だけで開発フローを自動追従する」）。「該当なし（直接編集）」なら自分で直す。

タスクを1つ終えるごとに gh issue edit <番号> でチェックリストを更新する（CLAUDE.md の厳守ルール）。

2-4. 検証する

変更した種類に応じて実行する。落ちたら直し、通るまで次へ進まない。

変更した種類	実行するもの
Markdown・Skill 定義	npm run check:links と /quick-doc-review
アプリ／CDK／スクリプト	/code-ci（CDK は /cdk-ci）
.claude/hooks/ 配下	npm run test:hooks

2-5. コミットする

その Issue で編集したファイルだけを git add <パス> で明示的にステージし、/git-commit stage を実行する。ワーキングツリー全体を対象にしてはならない——別セッションの未コミット変更を巻き込む。

件名末尾の (#番号) は git-policy が必須としている。処理中の Issue 番号を渡すこと。

2-6. close する

完了条件をすべて満たしていることを確認してから閉じる。

gh issue close <番号> --comment "<何をしたかを1文>"

sub-issue が open な親 Issue は閉じない。 先に sub-issue を処理するか、その Issue を飛ばす。

gh api graphql -f query='{repository(owner:"<owner>",name:"<repo>"){issue(number:<番号>){subIssues(first:50){nodes{number state}}}}}'

Phase 3: 結果の報告

処理した Issue を表にして報告する。

Issue	タイトル	結果
#123	…	close（コミット abc1234）
#124	…	人間へ差し戻し（理由：不可逆な削除を含む）
#125	…	専用セッションへ離脱（理由：修正が対象箇所の外へ波及）

エラーハンドリング

• 2-3 で直せない（修正が広範に及ぶ）・2-4 が通らない（原因が読めない）→ 2-2 の離脱条件に当たるので、その手順で離脱する。通らない変更をコミットしない
• 2-5 で失敗（pre-commit hook 等）→ 中断して原因を表示する。残りの Issue は処理しない（同じ理由で全件落ちる可能性が高い）

使用方法

/sweep        # ai-fixable の open Issue を全件
/sweep 3      # 古い順に3件だけ
/sweep 123 124  # 指定した Issue だけ