sweep

# /sweep `ai-fixable` が付いた open Issue を古い順に1件ずつ直し、Issue ごとにコミットして close する。**起動は人間の明示呼び出しに限る**が、起動後は最後まで人間への確認なしに自律実行する。 `/quick-issue` は「割れ窓を見えるようにする」ためのスキルで、見えた窓を塞ぐ担当がいなければ Issue は積み上がるだけになる。本スキルがその担当である。 ## 前提 - **始めるタイミングは人間が握る。** 一度に多数の Issue とコミットへ触れるため、いつ走らせるかは作業状況を見て人間が決める。 - **ブランチは切らない。** 現在のブランチでそのまま作業する。 - **1 Issue = 1 コミット = 1 close。** 途中で止まっても、完了した Issue までは履歴と Issue 状態が一致する。 - **他の Issue の変更を混ぜない。** ステージするのは、その Issue で自分が編集したファイルだけ。 ## 処理フロー ### Phase 1: 対象の決定 ```bash 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. 本文を読む ```bash gh issue view <番号> --json title,body,labels ``` 読む順は「対応方針」→「タスク一覧」→「現状」。**方針を決め直さない。** 本文の「対応方針」に書かれた採る案どおりに直す。 #### 2-2. 離脱条件の判定 `/sweep` は `ai-fixable` の Issue に**無条件で着手する**。着手してよいかを決めるのは `/issue-check` の責務である。 中断するのは、**着手してみて直せないと分かったとき**だけである。次のどれかに当たったら、編集したファイルを `git checkout -- <パス>` で戻し、ラベルを足して次の Issue へ移る。2-3 / 2-4 の作業中に観測したら、ここへ戻る。 - **本文から何を直すか決まらない（「対応方針」が無い・読み取れない／「対象箇所」が既に無い）**：直す対象を特定できず、実装に入れない - **修正が、本文の「対象箇所」に無い箇所へ波及した**：影響範囲が本文の想定を超え、判断が要る - **2-4 の検証が落ち、原因がその場で読めない**：原因を追うには混んでいない文脈が要る - **同一セッションで何件も処理していて、文脈が混んでいる**：直せるかどうかではなく、品質が落ちる ```bash 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番号だけで開発フローを自動追従する」）。「該当なし（直接編集）」なら自分で直す。 タスクを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 する 完了条件をすべて満たしていることを確認してから閉じる。 ```bash gh issue close <番号> --comment "<何をしたかを1文>" ``` **sub-issue が open な親 Issue は閉じない。** 先に sub-issue を処理するか、その Issue を飛ばす。open な子が全部ブロッカー待ちで止まっているなら、[`/issue-regroup`](../issue-regroup/SKILL.md) の対象として報告に並べる。子の付け替えは人間が起動を決める操作なので、本スキルでは行わない。 ```bash 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-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 だけ ```