issue-createlisted

# Issue Create Skill GitHub issue を起票する際のフォーマットと手順。 ## 基本方針 - 種別（feature / bug / task など）は持たない。共通セクションの組み合わせで表現する。 - ラベルやテンプレ整備はリポジトリ側に委ねる。本 Skill はあくまで本文構造を統一する。 - 起票は `gh issue create` を使用する。 ## ステータス issue 本文の **先頭** に必ず以下のいずれかを記載する。 - `Status: Ready` — 受け入れ条件確定、着手可 - `Status: Draft` — 受け入れ条件未確定、議論中（着手不可） ### Draft とする条件 Status の判定軸は **受け入れ条件の確定度** 一本である。言い換えると **「やったかどうか自分で判定できる��け入れ条件があるか」** で判断する。 受け入れ条件が以下のいずれかに該当する場合は `Status: Draft` とする。 - 「仮」「要検討」等を含み確定していない - 検証不能なほど曖昧で、「やったかどうか自分で判定できない」状態 上記に該当しない場合は `Status: Ready` とする。 `Status: Draft` の場合は、本文に `## Ready にするための未決事項` セクションを必ず設ける。ここには Draft であるという状態説明ではなく、**何を決めれば受け入れ条件を確定できるか**を具体的な問いのチェックリストとして記載する。 ```md ## Ready にするための未決事項 - [ ] 対応対象に Linux を含めるか - [ ] エラー時の期待結果を A / B のどちらにするか ``` - 受け入れ条件の確定を妨げている事項だけを書く。実装方法の選択肢や、着手後に調査可能な技術的詳細は含めない。 - 未決事項が解消したら、その決定を `## 受け入れ条件` へ反映し、未決事項セクションを削除して `Status: Ready` に変更する。 - 未決事項が 1 件でも残っている間は `Status: Draft` を維持する。 実装方針の確定度は Status に絡めない。バグ issue では「方針 A を試して直らなかったら B」というプロセス自体が正しい進め方であり、方針の事前確定を強制すると実態とミスマッチする。受け入れ条件が確定していて `acceptance-check` skill で検証可能であれば、「方針 A を採用したのにバグが直っていないまま close される」事故は防げる。 そのため **実装方針が複数案あっても、優先順位付き（または順序付き）で列挙されていれば `Status: Ready`** でよい。 ### 着手時の確認 着手依頼を受けた際、agent は **実装を始める前に必ずこのステータスを確認する**。`Status: Draft` の場合は実装に着手せず、ユーザーに受け入れ条件の確認を行うこと。 ## 依存 issue (Depends on) 他 issue の完了を待つ必要がある場合、`Status:` 行の直下に `Depends on: #<番号>` を記載する。 - 形式: `Depends on: #123, #124`（複数あればカンマ区切り） - 依存が無ければ **行ごと省略** する（空の `Depends on:` を残さない）。 -