issue-createlisted

# Issue Create Skill Claude Code 経由で GitHub issue を起票する際のフォーマットと手順。 ## 基本方針 - 種別（feature / bug / task など）は持たない。共通セクションの組み合わせで表現する。 - ラベルやテンプレ整備はリポジトリ側に委ねる。本 Skill はあくまで本文構造を統一する。 - 起票は `gh issue create` を使用する。 ## ステータス issue 本文の **先頭** に必ず以下のいずれかを記載する。 - `Status: Ready` — 受け入れ条件確定、着手可 - `Status: Draft` — 受け入れ条件未確定、議論中（着手不可） ### Draft とする条件 Status の判定軸は **受け入れ条件の確定度** 一本である。言い換えると **「やったかどうか自分で判定できる受け入れ条件があるか」** で判断する。 受け入れ条件が以下のいずれかに該当する場合は `Status: Draft` とする。 - 「仮」「要検討」等を含み確定していない - 検証不能なほど曖昧で、「やったかどうか自分で判定できない」状態 上記に該当しない場合は `Status: Ready` とする。 実装方針の確定度は Status に絡めない。バグ issue では「方針 A を試して直らなかったら B」というプロセス自体が正しい進め方であり、方針の事前確定を強制すると実態とミスマッチする。受け入れ条件が確定していて `acceptance-check` skill で検証可能であれば、「方針 A を採用したのにバグが直っていないまま close される」事故は防げる。 そのため **実装方針が複数案あっても、優先順位付き（または順序付き）で列挙されていれば `Status: Ready`** でよい。 ### 着手時の確認 着手依頼を受けた際、Claude Code は **実装を始める前に必ずこのステータスを確認する**。`Status: Draft` の場合は実装に着手せず、ユーザーに受け入れ条件の確認を行うこと。 ## 依存 issue (Depends on) 他 issue の完了を待つ必要がある場合、`Status:` 行の直下に `Depends on: #<番号>` を記載する。 - 形式: `Depends on: #123, #124`（複数あればカンマ区切り） - 依存が無ければ **行ごと省略** する（空の `Depends on:` を残さない）。 - **依存 issue の状態（open / closed）は本文に書かない。** GitHub UI 側で close 済み issue は取り消し線で表示されるため、本文に状態を書くと二重管理になり古い情報が残るリスクがある。状態を判定したいときは `gh issue view <番号> --json state` で実体を確認する。 - `Status` との関係: `Status` は spec 自体の確定度（Ready / Draft）、`Depends on` は他 issue の完了待ちを表し、両者は独立した軸。「Ready だが Depends on あり」「Draft かつ Depends on あり」のような組み合わせもありうる。 ## 本文フォーマット ### 共通セクション（必須） ```md Status: