From c96ec6f82d2ec0a908b773c4b9245b4d9579d03c Mon Sep 17 00:00:00 2001
From: Hiroki SAKABE <hiroki.sakabe@icloud.com>
Date: Sat, 1 Aug 2026 17:07:34 +0900
Subject: [PATCH] =?UTF-8?q?feat:=20Draft=20issue=20=E3=81=AE=E6=9C=AA?=
 =?UTF-8?q?=E6=B1=BA=E4=BA=8B=E9=A0=85=E3=82=92=E6=98=8E=E7=A4=BA=E3=81=99?=
 =?UTF-8?q?=E3=82=8B?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 AGENTS.md                    |  4 ++--
 README.md                    |  2 ++
 skills/issue-create/SKILL.md | 25 ++++++++++++++++++++++++-
 skills/issue-refine/SKILL.md |  7 ++++++-
 4 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/AGENTS.md b/AGENTS.md
index 34d8e7e..eb03ebe 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -39,13 +39,13 @@ Skills mechanically parse Japanese section headers from issue bodies:
 - `Status: Ready` / `Status: Draft` (must be at the **top** of the body)
 - `Depends on: #N, #M`
 - `親: #N`
-- `## 概要` / `## 背景 / モチベーション` / `## 受け入れ条件` / `## スコープ外` / `## 参考` / `## 実装方針` / `## 再現手順` / `## 期待する挙動` / `## 実際の挙動` / `## 調査メモ`
+- `## 概要` / `## 背景 / モチベーション` / `## 受け入れ条件` / `## Ready にするための未決事項` / `## スコープ外` / `## 参考` / `## 実装方針` / `## 再現手順` / `## 期待する挙動` / `## 実際の挙動` / `## 調査メモ`
 
 These strings are not localizable in the current implementation. Forking is required to use English issues (per README).
 
 ## Status semantics (single source of truth: `issue-create`)
 
-`Status` is judged on **acceptance-criteria certainty only**, not implementation-plan certainty. A bug issue with a prioritized list of fix candidates and verifiable acceptance criteria is `Ready`. Acceptance criteria containing 「仮」/「要検討」 or that are too vague to self-verify → `Draft`. `issue-refine` and `issue-implement` defer to `issue-create` for this rule — do not duplicate the definition; update `issue-create` and reference it.
+`Status` is judged on **acceptance-criteria certainty only**, not implementation-plan certainty. A bug issue with a prioritized list of fix candidates and verifiable acceptance criteria is `Ready`. Acceptance criteria containing 「仮」/「要検討」 or that are too vague to self-verify → `Draft`. Draft issues must include `## Ready にするための未決事項`, listing only the concrete decisions needed to finalize acceptance criteria. `issue-refine` and `issue-implement` defer to `issue-create` for this rule — do not duplicate the definition; update `issue-create` and reference it.
 
 ## Depends on / parent semantics
 
diff --git a/README.md b/README.md
index 474f3a1..99cfde6 100644
--- a/README.md
+++ b/README.md
@@ -100,6 +100,8 @@ issuekit ships seven skills under `skills/`:
 
 `issue-implement` is the orchestrator; the other skills are either entry points or verifiers it calls. `worktree-start` is the only entry point that is Claude Code-specific (`EnterWorktree` is a Claude Code primitive — Codex CLI has no equivalent), so it has no fallback under other agent runtimes. It is also the only entry point that conditionally chains into the orchestrator: when invoked with an issue URL/number whose body has `Status: Ready`, it hands off to `issue-implement` after the worktree switch.
 
+`Status: Draft` is reserved for issues whose acceptance criteria are not yet certain. Draft issues include a `## Ready にするための未決事項` checklist containing the concrete decisions needed to finalize those criteria; implementation-plan choices alone do not make an issue Draft.
+
 ---
 
 ## 🔁 Workflow
diff --git a/skills/issue-create/SKILL.md b/skills/issue-create/SKILL.md
index e1309af..6ca3030 100644
--- a/skills/issue-create/SKILL.md
+++ b/skills/issue-create/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: issue-create
 description: "Invoke for any request to create, file, open, or record a new GitHub issue. Trigger on:\n- Direct creation: 「issue 作って」「起票して」「issue 立て(といて)」「issue 化して」「issue 作れる?」\n- Record intent: 「issue に残したい/残しておいてほしい」「issue として残しておきたい」\n- Issue types: bug reports (with repro steps), feature requests, refactoring tasks, doc fixes, code-review findings to track later\n\nDo NOT trigger for viewing, listing, searching, or implementing existing issues."
-version: 1.0.3
+version: 1.1.0
 ---
 
 # Issue Create Skill
@@ -32,6 +32,19 @@ Status の判定軸は **受け入れ条件の確定度** 一本である。言
 
 上記に該当しない場合は `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`** でよい。
@@ -80,6 +93,16 @@ Depends on: #123, #124 # 依存がある場合のみ。無ければ行ごと省
 
 ### 追加セクション（必要時のみ）
 
+- **Ready にするための未決事項** — `Status: Draft` の場合に追加
+
+  受け入れ条件を確定するために必要な判断を、具体的な問いのチェックリストとして記載する。`Status: Ready` の場合はこのセクションを記載しない。
+
+  ```md
+  ## Ready にするための未決事項
+
+  - [ ] <受け入れ条件を確定するために決めること>
+  ```
+
 - **実装方針** — 方針案を記載する場合に追加
 
   単一の方針が確定しているケースだけでなく、**解消候補を優先順位付き（または試行順）で列挙する書き方も許容する**。バグ issue で「上から順に試す」プロセスが想定される場合は、後者の形式が自然。
diff --git a/skills/issue-refine/SKILL.md b/skills/issue-refine/SKILL.md
index 613f31a..d4fa4b2 100644
--- a/skills/issue-refine/SKILL.md
+++ b/skills/issue-refine/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: issue-refine
 description: 既存の GitHub issue を `issue-create` skill のフォーマットに沿って整理する。タイトルのみで起票された issue や、フォーマット不完全な issue を後から rich plan に仕上げ直したい場合に使用する。
-version: 1.0.3
+version: 1.1.0
 ---
 
 # Issue Refine Skill
@@ -35,6 +35,7 @@ gh issue view "$ISSUE_NUMBER"
 
 - 必須セクションの欠落
 - `Status:` 表記の有無
+- `Status: Draft` の場合、`## Ready にするための未決事項` があり、受け入れ条件を確定するための具体的な問いが列挙されているか
 - 親 issue がある場合の親リンクと「実装前に親 issue を必ず読むこと」明記
 - 追加セクション（実装方針 / 再現手順 / 調査メモ等）の必要性
 
@@ -42,6 +43,8 @@ gh issue view "$ISSUE_NUMBER"
 
 ユーザーに対し、欠けているセクションごとに必要な情報を確認する。一度にまとめて聞かず、優先度の高いもの（概要・受け入れ条件・実装方針）から順に確認するのが望ましい。
 
+`Status: Draft` の場合は、Draft であるという説明だけで終わらせず、受け入れ条件を確定するために必要な判断を `## Ready にするための未決事項` に具体的な問いのチェックリストとして整理する。実装方法の選択肢や、着手後に調査可能な技術的詳細は含めない。
+
 既存の本文は **可能な限り尊重する**。表現を勝手に書き換えず、追記・補完を中心に進める。意図が不明な記述があればユーザーに確認してから整える。
 
 ### 4. Status の再評価
@@ -53,6 +56,8 @@ gh issue view "$ISSUE_NUMBER"
 
 実装方針の確定度では判定しない。複数案を優先順位付きで列挙していれば `Status: Ready` でよい。
 
+`Status: Draft` の間は `## Ready にするための未決事項` を維持する。すべて解消した場合は、決定内容を `## 受け入れ条件` に反映し、未決事項セクションを削除して `Status: Ready` に変更する。
+
 整理前後で Status が変わる場合（例: Draft → Ready）は、その旨をユーザーに伝える。
 
 ### 5. issue 更新