broken-window-issue

作業の途中で見つかった本筋外の問題（割れ窓・人間の指摘）を、Issue として起票してください。起票のための読み込みを本筋の文脈に入れないよう、別コンテキストで走ります。

引数: $ARGUMENTS

起票のしかた

/quick-issue の SKILL.md を Read し、次の読み替えを当てたうえで、その処理フローどおりに起票する。broken-window を付ける。

• 「入力の解釈」：会話の代わりに、引数だけを材料にする。足りない事実はリポジトリを読んで補い、確かめられないことは「未確認」と書く。問い返さない。引数が空なら、1行確認の代わりに「起票できなかった」を返す
• 「起票前セルフチェック」の「いまの作業で自分が編集したファイルの中の不備ではない」：呼び出し側が判定済みなので飛ばす

次の2つは /quick-issue のとおりにし、読み替えない。

• 「人間の作業を別 Issue に切り出す」に当たれば2件にする
• 図が要る条件に当たれば /design-doc-mermaid を呼ぶ

返すもの

起票する Issue 1件ごとに、次の3通りのどれか1つを返す。2件に分けて結果が違えば、1件ごとに行を分けて並べる。本筋に戻る量を小さくするため、本文や経緯は返さない。

• 起票した：番号・URL・タイトル・付けたラベル・親の番号
• 重複で取りやめた：重複先の既存 Issue の番号
• 起票できなかった：理由。gh の失敗や、Skill ツールが使えず図を描けないときを含む

<details> <summary>この Skill をこう作った理由</summary>

• なぜ fork か：/quick-issue は起票のたびに、issue-policy と /link-root-issue を含む長い文書を読み込む。本筋の Skill がそのまま呼ぶと、別タスクの読み込みと、ラベル・書き先・段番号の判定が本筋の文脈に混ざり、本筋の精度を下げうる。fork なら、読み込みが別コンテキストで済む
• なぜ background: true か：起票の間も、本筋が人間に応えられる。結果は完了の通知として後のターンに届くので、「起票できなかった」も受け取れる。-p と Agent SDK では値に関係なく待つので、無人実行の振る舞いは変わらない（https://code.claude.com/docs/en/sub-agents ）
• なぜ model: sonnet・effort: high か：起票を2分以内に終わらせるため（人間の決定）。context: fork のとき、この2つは fork 先にだけ効き、本筋のモデルは変わらない（https://code.claude.com/docs/en/skills ）
• なぜ見つけた時点で起票するか：本筋の完了後にまとめて起票すると、途中で落ちたセッションの起票が失われる。見つけた時点で起票すれば GitHub に残る

</details>