issue-planlisted

# issue-plan vibe-editor の Issue に対して **「読む → 調査する → 計画を立てる → planned ラベルを付ける → 計画コメントを投稿する」** までを一気通貫で行う skill。 実装 (= branch を切ってコードを書く) は **行わない**。この skill のゴールは「issue 単体を見れば、どう実装するつもりかが第三者にも分かる状態」を作ることまで。実装フェーズに入るときは別途 `vibeeditor` skill / 通常の編集フローに引き継ぐ。 --- ## 全体フロー ``` [1] 入力 (issue 番号 or URL) を受け取る ↓ [2] gh で issue 本体 + 既存コメント + ラベルを取得 ↓ [3] 既に planned が付いていないかチェック (ガード) ↓ [4] リポジトリを探索して関連ファイル・現状動作を把握 ↓ [5] 計画 Markdown を作成 ↓ [6] planned ラベルが無ければ作成 → issue に付与 ↓ [7] 計画 Markdown を issue コメントとして投稿 ↓ [8] 「次は実装フェーズ。branch を切って良いか？」とユーザーに確認して終了 ``` --- ## Step 1: 入力の正規化 ユーザーから受け取る入力は次のいずれかの形: - 数値のみ: `123` - `#123` - 完全 URL: `https://github.com/<owner>/<repo>/issues/123` いずれの場合も最終的に `<num>` (整数) に正規化して以降使う。URL なら数字部分を抜き出す。`gh` は現在のリポジトリを自動で見るので、`<owner>/<repo>` の指定は不要。 複数 issue を一度に渡された場合は、**1 件ずつ順番に** この skill のフローを回すこと。バッチ処理してはいけない (各 issue ごとに独立した調査・計画が要る)。 --- ## Step 2: issue の取得 並列でまとめて取得して良い: ```bash gh issue view <num> --json number,title,body,labels,state,author,comments,url ``` 取得した内容を頭に入れる。特に注目するのは: - `title` / `body` — 何が問題か / 何を作りたいか - `labels` — `bug` / `enhancement` / `refactor` / `area:*` の組合せ - `comments` — 議論の経緯。途中で要件がアップデートされていることが多い - `state` — `closed` だったら原則 plan しない (ユーザーに確認) --- ## Step 3: 重複ガード (planned が既に付いているか) `labels` の配列に `planned` が含まれていたら、いきなり計画を投稿してはいけない。 ユーザーに次の 3 択を確認する: 1. **既存計画が古いので上書き的に新しい計画を追記する** (推奨) 2. **既存計画で十分なので何もしない** (中断) 3. **既存計画コメントを編集する** (該当コメントの URL/ID を特定して