/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 100 --search 'label:ai-fixable label:boy-scout -label:"issue:needs-clean-session"' --json number,title --jq 'sort_by(.number) | .[] | "\(.number)\t\(.title)"'

取得件数がちょうど100件なら上限で切れている可能性があるので、その旨を伝えてから処理する。

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

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

引数の解釈は次のとおり。素の数字は常に件数として読む——同じ形の入力が件数にも Issue 番号にもなると、誤用を防げないからである。

• なし：一覧の全件
• 数字1つ：一覧の古い順にその件数
• # 付き番号（複数可）：その Issue だけ（ラベルの有無を問わない）

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

Phase 2: 1件ずつ処理する

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

2-1. 本文を読む

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

読む順は「対応方針」→「タスク一覧」→「現状」。方針を決め直さない。 本文の「対応方針」に書かれた採る案どおりに直す。「対応方針」の直後にある <details>（/issue-check が追記した外部制約）も読む。「対応方針」の表の「変えた後」の文言が一次資料の原文と食い違うときは、Issue 本文は書き換えず、成果物に書く文言だけを原文に合わせて直す（採る案・書き先・対象は変えない）。例：「変えた後」が「月100回まで無料」と書くが、<details> が引く一次資料は「月50回まで」なら、成果物には「月50回まで」と書く。文言を直すのは実装者であり、/issue-check が直すと方針の書き換えになるため。

2-2. 離脱条件の判定

/sweep は ai-fixable の Issue に無条件で着手する。着手してよいかを決めるのは /issue-check の責務である。

中断するのは、着手してみて直せないと分かったときだけである。次のどれかに当たったら、編集したファイルを git checkout -- <パス> で戻し、ラベルを足して次の Issue へ移る。2-3 / 2-4 の作業中に観測したら、ここへ戻る。

• 本文から何を直すか決まらない（「対応方針」の見出しが無い・見出しの中に「採る案」の記述が無い／「対象箇所」に挙げた箇所が既に無い）：直す対象を特定できず、実装に入れない
• 修正が、本文の「対象箇所」に無い箇所へ波及した：影響範囲が本文の想定を超え、判断が要る
• 2-4 の検証が落ち、2回直しても同じ箇所で落ちる：原因を追うには混んでいない文脈が要る
• 同一セッションで5件処理した：直せるかどうかではなく、品質が落ちる

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

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

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

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

2-3. 直す

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

実行する Skill がレビュー（/doc-review・/code-review・/cdk-review・/arch-review・/requirements-review）のときは、合否・再レビューの回数・修正範囲を ai-review-gate-policy に従って決める（自律型ワークフロー）。

• 指摘があれば、severity にかかわらずすべて直す（例外は同ポリシー「直す範囲は毎回すべて」の残してよい例外だけ）。直したら同じレビュー Skill を再実行する。再レビューには前回の指摘を渡さない
• レビューは同じ Skill ごとに最大2回（初回を含む）。「タスク一覧」の作業として動作確認のために回したものも回数に数える。残してよい例外以外の Critical が0件になった回で合格とし、その回に出た High・Medium もその場で直してから次へ進む
• 2回目のレビューで指摘が出たら、直したうえで再レビューせずに 2-4 へ進む

タスクを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-commit Skill が必須としている。処理中の Issue 番号を渡すこと。

2-6. close する

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

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

sub-issue が open な親 Issue は閉じない。 先に sub-issue を処理するか、その Issue を飛ばす。open な子が全部ブロッカー待ちで止まっているなら、`/issue-regroup` の対象として報告に並べる。子の付け替えは人間が起動を決める操作なので、本スキルでは行わない。

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	…	専用セッションへ離脱（理由：修正が対象箇所の外へ波及）

エラーハンドリング

• 2-3 で直せない（修正が本文の「対象箇所」に無い箇所へ波及した）・2-4 が2回直しても同じ箇所で落ちる → 2-2 の離脱条件に当たるので、その手順で離脱する。通らない変更をコミットしない
• 2-4 で呼んだ Skill が進まない（ListAgents が running のまま、表示される経過時間が実時間より大きく遅れている）→ 待ち続けない。TaskStop に Skill 名を渡して止め、その Skill が指定する agent を run_in_background: false で起動し直す
• 2-5 で失敗（pre-commit hook 等）→ 中断して原因を表示する。残りの Issue は処理しない（同じ理由で全件落ちる可能性が高い）

使用方法

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