issue-check

boy-scout Issue を監査してください。あなたは判定本体を行わず、**Issue×レンズごとに割って並列に走らせ、返ってきた結果を統合して Issue へ反映する**役です。 `/quick-issue` は確認なしで即起票します。速さのために削れるのは推敲だけのはずですが、実際にはポリシーに反する対応方針や、よく見ると直す必要が無い課題も混ざります。`/sweep` は本文の対応方針どおりに直す設計なので、誤った方針はそのまま実装されます。**着手前にここで潰します。** ## 前提 - **起動はスラッシュコマンドの明示呼び出しに限ります。** 一度に多数の Issue を書き換えるため、モデルが自分の判断で走らせてはいけません。 - **リポジトリのファイルは変更しません。** 触るのは GitHub Issue（タイトル・本文・ラベル・コメント・close）だけです。 - **判定の基準と優先順位は [`references/audit-criteria.md`](references/audit-criteria.md)（観点一覧）が、レンズの一覧と担当観点は `issue-auditor-agent` の定義が正典です。** ここに書き写しません——2箇所に持つと、判定を変えたときに片方が古いまま残ります。 - **`issue:checked` の意味は「一度 `/issue-check` を通した」**であって、「いま妥当」ではありません。 ## Phase 1: 対象の決定 ```bash gh issue list --state open --limit 100 --search 'label:boy-scout' \ --json number,title,labels --jq 'sort_by(.number) | .[] | "\(.number)\t\([.labels[].name]|join(","))\t\(.title)"' ``` `ai-fixable` で絞りません。`issue:needs-human-decision` の Issue も、名指し例外に本当に当たるかを検査する対象です。`issue:needs-clean-session` も含めます——読むだけの判定なので、一括で直せるかどうかとは無関係です。 **`issue:checked` が付いた Issue も除外しません。** 判定のうち「前提が現物と食い違う」は、リポジトリが動けば真偽が変わります。前回の判定を貼った時点で凍結できないので、毎回すべて見直します。`issue:checked` を検索条件に使わないことで、Issue 番号を直接指定した経路との食い違いも起きません。 取得件数が `--limit` に指定した件数ちょうどなら、上限で切れている可能性があるので、その旨を伝えてから処理します。 引数の解釈は次のとおりです。**素の数字は常に件数**として読みます——同じ形の入力が件数にも Issue 番号にもなると、誤用を防げないからです。 - **なし**：一覧の全件 - **数字1つ**：一覧の古い順にその件数 - **`#` 付き番号（複数可）**：その Issue だけ（ラベルの有無を問わない） 対象が0件なら、その旨を伝えて終了します。決めた対象リストを表示してから Phase 2 へ進みます。 ## Phase 2: 並列監査 `issue-auditor-agent` を、**Issue 1件につきレンズごとに1回ずつ、1メッセージ内でまとめて** Task 起動します。逐次に投げると、割った意味（速さ）が消えます。1波は Issue 5件（起動はレンズの数×5回）までとし、超える分は次の波へ回します。 起動の前に `.claude/agents/issue-auditor-agent/issue-auditor-agent.md` の「レンズ一覧と担当観点（正典）」を Read し、そこにあるレンズ名をそのまま使います。各起動に渡すのは **レンズ名と Issue 番号だけ**です。本文もポリシーもエージェント自身が読みます。**この SKILL.md に書いた指示は Task 起動されたエージェントには届かない**ので、判定に要る情報をここから渡そうとしないでください。 ## Phase 3: 統合と反映 ### Issue ごとに判定を1つにする Issue ごとに、各レンズが返した「判定」を並べ、観点一覧「判定の優先順位」で上にあるもの1つを、その Issue の判定にします。**判定を決め直さないでください。** 各レンズは担当観点の現物を読んで決め切っており、ここで評価し直すと、1レンズ1問いに絞った意味が消えます。 - **「差し替える本文」「提案ラベル」**：判定に選ばれたレンズのものを使います - **両方のレンズが「人間判断」**：2つの「人間に決めてほしいこと」の論点を並べて、1つのセクションにします。並べるだけで、書き直しません ### バッチ内の重複を検査する 並列で走ったエージェントは互いを見られません。**同じ対象箇所を指す Issue が2件以上ある場合、その検出はここでしかできません。** 要否レンズのレポートの「現物確認」表に並んだ対象箇所を突き合わせ、重なっていれば**番号の大きい側を「不要（重複）」に倒します**。倒した側のコメントには、残す側の Issue 番号を書きます。 これは「判定を決め直さない」の唯一の例外です。判断を挟まないよう、「対象箇所が重なる」「番号の大きい側を倒す」という機械的な規則だけで決めます。 ### 判定ごとに反映する **`gh` を並列で叩かないでください。** 1件ずつ順に処理します。同じ Issue へ複数の更新が同時に飛ぶと、あとから投げたほうが前の更新を消します。 - **GO**：レポートに「未確認」または本文と現物の食い違いが挙がっていれば、その内容をコメントで残す。無ければ何もしない（`issue:checked` は下記のとおり全件に貼る） - **方針差し替え**：本文の該当セクションを差し替え、何を・なぜ変えたかをコメントで残す - **ラベル訂正**：ラベルを貼り替え、どの名指し例外に当たる／当たらないかをコメントで残す - **不要**：close する - **人間判断**：`issue:needs-human-decision` を足して `ai-fixable` と `issue:decided` を外し、本文に「人間に決めてほしいこと」を足して、論点をコメントで残す レンズが「照合したポリシー」を「該当なし（policy-gap 候補）」と返したら、判定が何であれ `policy-gap` ラベルが無ければ足します。ポリシーを足す候補は、ここで拾わないと二度と拾えません。 **どの操作にも必ず理由コメントを添えます。GO で注記だけを残すときも同じです。** 理由が無いと、次に Issue を開いた人は「なぜ本文が変わったのか」を追えません。注記が無いと、監査で分かった事実はセッションのログにしか残らず、次に着手する人は誤った本文のまま実装します。 **判定が出た Issue には、判定が何であれ `issue:checked` を貼ります。** ```bash gh issue edit <番号> --add-label "issue:checked" ``` GO の Issue には他に何も残らないので、貼らないと「監査を通した」と「一度も見ていない」を後から区別できません。貼った日時は GitHub のタイムラインに残るので、コメントで補いません。close する Issue にも貼ります——判定した記録は、閉じたかどうかとは別に要ります。 #### 本文を差し替える エージェントが返した「差し替える本文」を、セクション単位で入れ替えます。本文全体を書き直してはいけません——監査対象でないセクションまで変わってしまいます。 ```bash gh issue view <番号> --json body --jq .body > <スクラッチパッド>/issue-<番号>.md ``` 書き出したファイルを Read し、Edit で該当セクションだけを差し替えてから反映します。 ```bash gh issue edit <番号> --body-file <スクラッチパッド>/issue-<番号>.md ``` 「差し替える本文」の先頭にある「タイトル：」の行は本文に貼りません。「変更なし」以外なら、タイトルに反映します。 ```bash gh issue edit <番号> --title "<新しいタイトル>" ``` ラベルを `ai-fixable` へ訂正したときは「対応方針」が、`issue:needs-human-decision` へ訂正したときは「人間に決めてほしいこと」が本文に要ります。`/quick-issue` はこの2セクションを排他と定めているので、**片方を足したらもう片方を消します。** #### close する **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}}}}}' ``` ```bash gh issue close <番号> --comment "<なぜ不要と判定したかを、引用またはコマンド出力を添えて>" ``` ## Phase 4: 報告 処理した Issue を表にして報告します。 | Issue | タイトル | 判定 | 根拠（1文） | 取った操作 | | ----- | -------- | ------------ | ------------------------------------------------ | ------------------------ | | #123 | … | GO | どの観点の「該当と判定する条件」にも当たらない | なし | | #126 | … | GO | 該当は無いが、本文の「現状」が現物と食い違う | コメント（未確認の注記） | | #124 | … | 方針差し替え | 対応方針が documentation-policy の「〜」に反する | 本文差し替え＋コメント | | #125 | … | 不要 | 対象箇所が既に存在しない | close | 末尾に **GO と判定した Issue 番号の一覧**を出します。人間はこれを見て `/sweep` を打ちます。 まだ監査していない Issue は、後からこれで引けます。 ```bash gh issue list --state open --search 'label:boy-scout -label:"issue:checked"' \ --json number,title --jq 'sort_by(.number) | .[] | "\(.number)\t\(.title)"' ``` ## エラーハンドリング - **どれか1つのレンズでも定型フォーマットで返さない**：その Issue は判定を出さず、タイトル・本文・ラベル・state を一切変更しません（`issue:checked` も貼りません）。壊れた出力と組み合わせて close しないためで、監査を通せていない以上「通した」印も残しません。報告では「監査不能」として並べます - **レンズが引用の無い「該当」を返した**：その観点を落とす。そのレンズに他の該当が残らなければ、そのレンズの判定を GO に戻してから優先順位を当てる（裏が取れていない指摘で本文を書き換えない） - **`gh issue edit` が失敗する**：その Issue の処理を中断し、エラーを表示して次の Issue へ進む - **同じ Issue に別セッションの更新が入っている**：上書きせず中断し、その事実を報告する ## 使用方法 ``` /issue-check # boy-scout の open Issue を全件 /issue-check 3 # 古い順に3件だけ /issue-check #123 #124 # 指定した Issue だけ ``` 引数: $ARGUMENTS