issue-refinelisted

# Issue Refine Skill 既存 issue を取得し、不足セクションを対話で埋め、Status を再評価して `gh issue edit` で更新する。issue-driven 開発サイクルにおける Draft → Ready 移行や、雑に起票された issue の整理に使う。 ## `issue-create` との違い | 観点 | `issue-create` | `issue-refine` | | ---- | ----------------- | -------------------------- | | 対象 | 新規 issue | 既存 issue | | 操作 | `gh issue create` | `gh issue edit` | | 起点 | 白紙 | 既存本文を尊重して差分整理 | フォーマット観点（共通セクション、Status 判定、親子 issue の扱い）は **`issue-create` skill を参照する**。本 skill では重複定義しない。 ## 実行手順 ### 1. 既存 issue の取得 ```bash ISSUE_NUMBER=<issue 番号> gh issue view "$ISSUE_NUMBER" ``` タイトル、本文、ラベル、親子関係を確認する。 ### 2. ギャップ分析 `issue-create` skill のフォーマット（共通セクション: 概要 / 背景・モチベーション / 受け入れ条件 / スコープ外 / 参考）に対して、現状の本文に **何が欠けているか** を洗い出す。 - 必須セクションの欠落 - `Status:` 表記の有無 - 親 issue がある場合の親リンクと「実装前に親 issue を必ず読むこと」明記 - 追加セクション（実装方針 / 再現手順 / 調査メモ等）の必要性 ### 3. 対話で不足を埋める ユーザーに対し、欠けているセクションごとに必要な情報を確認する。一度にまとめて聞かず、優先度の高いもの（概要・受け入れ条件・実装方針）から順に確認するのが望ましい。 既存の本文は **可能な限り尊重する**。表現を勝手に書き換えず、追記・補完を中心に進める。意図が不明な記述があればユーザーに確認してから整える。 ### 4. Status の再評価 `issue-create` skill の「Status > Draft とする条件」に従い、整理後の本文で Status を再判定する。判定軸は **受け入れ条件の確定度** 一本。 - 受け入れ条件が「仮」「要検討」を含む / 検証不能なほど曖昧（やったかどうか自分で判定できない）→ `Status: Draft` - 受け入れ条件が「やったかどうか自分で判定できる」形になっている → `Status: Ready` 実装方針の確定度では判定しない。複数案を優先順位付きで列挙していれば `Status: Ready` でよい。 整理前後で Status が変わる場合（例: Draft → Ready）は、その旨をユーザーに伝える。 ### 5. issue 更新 `gh issue edit` で本文（必要ならタイトルも）を更新する。本文は `--body-file -` で標準入力から渡し、記号を含