lee-spec-kit 0.6.12 → 0.6.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.6.12",
+  "version": "0.6.14",
   "description": "Project documentation structure generator for AI-assisted development",
   "type": "module",
   "bin": {

package/templates/en/common/agents/agents.md

@@ -23,7 +23,7 @@ This document covers **policy only**.
 Approval flow:
 1. Share details first
 2. Wait for explicit approval (OK)
-3. Execute after approval
+3. Execute after approval (for command execution, default to `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`)
 
 Prohibited:
 - Proceeding without user response
@@ -38,6 +38,7 @@ Prohibited:
 - Even when the user asks something else, append the same label block at the end if executable labels exist.
 - If no executable labels exist, print `Available labels: none` and guide re-check with `npx lee-spec-kit context`.
 - If user input does not contain a valid label, do not execute; request label selection again.
+- For approved command options, prefer one-shot `flow --approve <LABEL> --execute`; do not split `context --approve` and `context --execute --ticket` across turns/sessions.
 
 Output format:
 
@@ -70,8 +71,8 @@ Reply format: "<LABEL>" or "<LABEL> OK"
 - Root guide: `npx lee-spec-kit docs get agents --json`
 - Git workflow: `npx lee-spec-kit docs get git-workflow --json`
 - Task execution: `npx lee-spec-kit docs get execute-task --json`
-- Issue procedure/template: `npx lee-spec-kit docs get create-issue --json` → `npx lee-spec-kit docs get issue-template --json`
-- PR procedure/template: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-template --json`
+- Issue procedure/doc: `npx lee-spec-kit docs get create-issue --json` → `npx lee-spec-kit docs get issue-doc --json`
+- PR procedure/doc: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-doc --json`
 
 ---
 
@@ -79,6 +80,7 @@ Reply format: "<LABEL>" or "<LABEL> OK"
 
 - Docs structure/path rules: use `docs/README.md` as SSOT
 - ADR format: use feature `decisions.md` template as SSOT
+- Issue/PR execution state: use each feature's `issue.md` and `pr.md` as SSOT
 
 ---
 

package/templates/en/common/agents/issue-template.md

@@ -1,6 +1,7 @@
 # GitHub Issue Template Guide
 
 A template for AI agents to create GitHub Issues.
+This document is a section policy/style guide. Use feature-local `issue.md` as the SSOT for actual workflow state.
 
 ---
 

package/templates/en/common/agents/pr-template.md

@@ -1,6 +1,7 @@
 # GitHub PR Template Guide
 
 A template for AI agents to create Pull Requests.
+This document is a section policy/style guide. Use feature-local `pr.md` as the SSOT for actual workflow state.
 
 ---
 

package/templates/en/common/agents/skills/create-feature.md

@@ -26,6 +26,7 @@ For gated actions, proceed only after the user replies in **`<label>` or `<label
 - If the CLI asks for writing a file, write that file and follow the format.
 - If the CLI prints a command, **copy/paste and run it exactly**. (It may include repo-safe `git -C ...` commands and scopes like `project` vs `docs`.)
 - When requesting approval, present labels as `A: ...` using the exact CLI detail/cmd text. Do not paraphrase command options.
+- For approved command options, default to one-shot execution via `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute` to avoid session mismatch.
 
 ### Step 3: Repeat
 

package/templates/en/common/agents/skills/create-issue.md

@@ -1,6 +1,7 @@
 # GitHub Issue Creation Process
 
 Guide for creating GitHub Issues.
+Execution-state SSOT is the feature-local `issue.md`.
 
 ---
 
@@ -13,22 +14,22 @@ Guide for creating GitHub Issues.
 
 ## Steps
 
-### 1. Prepare Issue Draft
+### 1. Prepare `issue.md` Draft
 
 > 📖 **If not read in this session, read procedure/template via `docs get`; do not re-read the same doc in the same session, then generate a draft and treat it as the source of truth.**
 
 ```bash
 # 1) Read procedure + template policy (only docs not read in this session)
 npx lee-spec-kit docs get create-issue --json
-npx lee-spec-kit docs get issue-template --json
+npx lee-spec-kit docs get issue-doc --json
 
 # 2) Generate draft body (no remote action)
 npx lee-spec-kit github issue F001 --json
 ```
 
-Use `docs get issue-template --json` output as the section policy,
-and `github issue --json` output `body` as the first draft to review/share.
-If needed, use `bodyFile` as the filesystem source.
+Use `docs get issue-doc --json` output as document-structure policy,
+then refine the feature `issue.md` draft from `github issue --json` `body`.
+Use `issue.md` status (`Draft | Ready`) as the actual workflow state.
 
 | Item     | Format                                      |
 | -------- | ------------------------------------------- |
@@ -37,19 +38,19 @@ If needed, use `bodyFile` as the filesystem source.
 | Labels   | `enhancement`, `bug`, `documentation`, etc. |
 | Assignee | `@me` (default)                             |
 
-### 2. Request User Approval
+### 2. Request User Approval + Move to `Ready`
 
 > 🚨 **User Approval Required**
 
-Before creating issue, share and wait for explicit approval (OK):
+Share the `issue.md` draft and wait for explicit approval (OK):
 
 - Title
-- Full body draft (from `body`)
+- Full body draft (from `issue.md`)
 - Labels
 
-Also refine Goals/Completion Criteria based on spec before creating.
+After approval, set `issue.md` status to `Ready`.
 
-### 3. Create Issue
+### 3. Create Issue (when `issue.md` is `Ready`)
 
 ```bash
 gh issue create \
@@ -62,9 +63,15 @@ gh issue create \
 npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 ```
 
+After creation:
+- sync created issue number into `issue.md`
+- sync issue number into `spec.md` and `tasks.md`
+- keep `issue.md` status as `Ready` (creation state is tracked by issue number/link fields)
+
 ---
 
 ## Reference Documents
 
 - **Draft generator**: `npx lee-spec-kit github issue <feature-name>`
 - **Approval rule**: share title/body/labels first, then run `--create --confirm OK`
+- **Execution-state SSOT**: `docs/features/.../<feature>/issue.md`

package/templates/en/common/agents/skills/create-pr.md

@@ -1,6 +1,7 @@
 # Pull Request Creation Process
 
 Guide for creating Pull Requests.
+Execution-state SSOT is the feature-local `pr.md`.
 
 ---
 
@@ -15,14 +16,14 @@ Guide for creating Pull Requests.
 
 ## Steps
 
-### 1. Prepare PR Body Template
+### 1. Prepare `pr.md` Draft
 
 > 📖 **If not read in this session, read procedure/template via `docs get`; do not re-read the same doc in the same session, then generate a body template and treat it as the source of truth.**
 
 ```bash
 # 1) Read procedure + template policy (only docs not read in this session)
 npx lee-spec-kit docs get create-pr --json
-npx lee-spec-kit docs get pr-template --json
+npx lee-spec-kit docs get pr-doc --json
 
 # 2) Generate body template (no remote action)
 npx lee-spec-kit github pr F001 --json
@@ -31,9 +32,9 @@ npx lee-spec-kit github pr F001 --json
 # - Auto policy (default): --screenshots auto --mermaid auto
 ```
 
-Use `docs get pr-template --json` output as the section policy,
-and `github pr --json` output `body` as the first PR body template.
-If needed, use `bodyFile` as the filesystem source.
+Use `docs get pr-doc --json` output as document-structure policy,
+then refine the feature `pr.md` draft from `github pr --json` `body`.
+Use `pr.md` status (`Draft | Ready`) as the actual workflow state.
 
 | Item     | Format                             |
 | -------- | ---------------------------------- |
@@ -124,19 +125,20 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 
 - Write a Mermaid **`sequenceDiagram`** in the PR body and keep it aligned with the generated body template format.
 
-### 4. Request User Approval
+### 4. Request User Approval + Move to `Ready`
 
 > 🚨 **User Approval Required**
 
 Before creating PR, share the following **in a code block** and wait for **explicit approval (OK)**:
 
 - Title
-- Full body template (from `body`)
+- Full body template (from `pr.md`)
 - Labels (at least 1; cannot be empty)
 
-Before approval/create, refine the generated body template's Changes/Tests sections based on actual work.
+Before approval/create, refine `pr.md` Changes/Tests sections based on actual work.
+After approval, set `pr.md` status to `Ready`.
 
-### 5. Create PR
+### 5. Create PR (when `pr.md` is `Ready`)
 
 ```bash
 gh pr create \
@@ -150,6 +152,11 @@ gh pr create \
 npx lee-spec-kit github pr F001 --create --confirm OK --labels enhancement
 ```
 
+After creation:
+- record created PR link into `pr.md` and `tasks.md`
+- record/keep PR status as `Review`
+- keep `pr.md` status as `Ready` (creation/merge state is tracked by PR link + `PR Status`)
+
 ---
 
 ## Important Notes
@@ -191,3 +198,4 @@ Use **current branch name** for file links in PR body:
 
 - **Body template generator**: `npx lee-spec-kit github pr <feature-name>`
 - **Approval rule**: share title/body/labels first, then run `--create --confirm OK`
+- **Execution-state SSOT**: `docs/features/.../<feature>/pr.md`

package/templates/en/common/agents/skills/execute-task.md

@@ -23,6 +23,7 @@ Execute exactly one option from `👉 Next Options (Atomic)` as printed by the C
 - Treat the task state/approval rules in `tasks.md` **"Task Rules"** as SSOT (e.g. when OK is required for `[TODO]→[DOING]`, `[DOING]→[DONE]`).
 - If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
 - Follow user-facing response format (including the final status/label block in every reply) from `agents.md` **"Label Response Contract (SSOT)"**.
+- For approved command options, default to `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute` and avoid split `context --approve` / `context --execute --ticket` runs across turns.
 
 ### Step 3: Update tasks.md (only what you did)
 
@@ -31,16 +32,7 @@ Keep `tasks.md` aligned with reality.
 - Do not mark `[DONE]` without actually completing the work and verifying criteria.
 - If you need to change a completed task, add a new task instead of rewriting history.
 
-### Step 3.25: Commit per task (important)
-
-- Complete **only one task at a time** (do not batch-finish multiple tasks in one commit).
-- After you share the outcome/verification and get approval (OK), mark the task `[DONE]` (and update any checklist items), then create commits (code commit + docs commit) so each task has its own history.
-- In `tasks.md` test logs, keep one entry per test command and update its timestamp/result on reruns (do not keep appending duplicates). Use `YYYY-MM-DD HH-MM` in local time.
-- If `context` shows `[CHECK required]`, for commits/push/merge, **share the commit message + included files and wait for explicit OK** before running the commands.
-- Once all tasks are `[DONE]`, share the "Completion Criteria" checklist with the user and get **final approval (OK)**, then check it (especially the **Final user approval (OK) received** item).
-  - Note: `Doc Status (Review→Approved)` is **progress approval (OK)**, while the completion checklist approval is **final approval (OK)**.
-
-### Step 3.5: Record decisions (strongly recommended, effectively required)
+### Step 3.25: Record decisions (strongly recommended, effectively required)
 
 To avoid “why did we implement it like this?” losing context, **record any non-obvious or tradeoff-heavy implementation choice** in `decisions.md`.
 
@@ -54,7 +46,27 @@ Record a decision if any of these apply:
 - You changed data shape, file structure, or CLI output rules
 - You expect future readers to ask “why this way?”
 
-Use the feature’s `decisions.md` template format. (Context/Options/Decision/Rationale/Consequences)
+Timing rules:
+
+- When moving a task to `[DOING]`, first add 1-3 lines for `Context/Constraints` and `Trace (initial hypothesis)`.
+- Before moving a task to `[DONE]`, finalize `Options/Decision/Rationale` and strengthen `Trace (final reasoning)`.
+- After PR merge, append 1-2 lines in `Trace (post-merge check)` with actual outcome/impact.
+
+Evidence rules:
+
+- Every ADR must include at least one Evidence link (commit, PR, or test/log evidence).
+- Prefer filling all three (`Commit`, `PR`, `Test/Log`); if not applicable, mark as `N/A`.
+
+Use the feature’s `decisions.md` template format as final SSOT. (Context/Constraints/Options/Decision/Rationale/Trace/Evidence/Consequences)
+
+### Step 3.5: Commit per task (important)
+
+- Complete **only one task at a time** (do not batch-finish multiple tasks in one commit).
+- After you share the outcome/verification and get approval (OK), mark the task `[DONE]` (and update any checklist items), then create commits (code commit + docs commit) so each task has its own history.
+- In `tasks.md` test logs, keep one entry per test command and update its date/result on reruns (do not keep appending duplicates). Use `YYYY-MM-DD` in local date.
+- If `context` shows `[CHECK required]`, for commits/push/merge, **share the commit message + included files and wait for explicit OK** before running the commands.
+- Once all tasks are `[DONE]`, share the "Completion Criteria" checklist with the user and get **final approval (OK)**, then check it (especially the **Final user approval (OK) received** item).
+  - Note: `Doc Status (Review→Approved)` is **progress approval (OK)**, while the completion checklist approval is **final approval (OK)**.
 
 ### Step 4: Repeat
 

package/templates/en/common/features/README.md

@@ -13,6 +13,8 @@ features/
 │   ├── spec.md
 │   ├── plan.md
 │   ├── tasks.md
+│   ├── issue.md
+│   ├── pr.md
 │   └── decisions.md
 ├── (single) F00X-{name}/
 └── (multi)  {component}/F00X-{name}/
@@ -58,6 +60,18 @@ npx lee-spec-kit status --write
 
 ---
 
+## Status Glossary
+
+| Scope | Field | Values |
+| --- | --- | --- |
+| Document status | `Status` in `spec.md`/`plan.md`, `Doc Status` in `tasks.md` | `Draft` \| `Review` \| `Approved` |
+| Issue doc status | `Status` in `issue.md` | `Draft` \| `Ready` |
+| PR doc status | `Status` in `pr.md` | `Draft` \| `Ready` |
+| PR review status | `PR Status` in `tasks.md`/`pr.md` | `Review` \| `Approved` |
+| Pre-PR review status | `Pre-PR Review` in `tasks.md` | `Pending` \| `Done` |
+
+---
+
 ## File Roles
 
 | File           | Role                      | When to Write       |
@@ -65,4 +79,6 @@ npx lee-spec-kit status --write
 | `spec.md`      | **What and Why**          | Feature definition  |
 | `plan.md`      | **How** (technical)       | After spec approval |
 | `tasks.md`     | Specific work items       | After plan approval |
-| `decisions.md` | Technical decisions (ADR) | During development  |
+| `issue.md`     | Issue draft + issue state (`Draft/Ready`) | Before/when creating issue |
+| `pr.md`        | PR draft + PR state (`Draft/Ready`) | Before/when creating PR |
+| `decisions.md` | Technical decisions + reasoning trace + evidence links (ADR) | During development (DOING start / before DONE / post-merge) |

package/templates/en/common/features/feature-base/decisions.md

@@ -7,12 +7,30 @@ Record technical decisions and their rationale.
 
 > Format: `D{number}: {Decision Title} ({YYYY-MM-DD})`
 
+Recording principles:
+
+- Every ADR must capture both **Decision (what was chosen)** and **Trace (how it was evaluated and validated)**.
+- Use fixed timing checkpoints:
+  - Task start (`[TODO] -> [DOING]`): add 1-3 lines for `Context/Constraints` and `Trace (initial hypothesis)`
+  - Right before task done (`[DOING] -> [DONE]`): finalize `Options/Decision/Rationale` and enrich `Trace`
+  - After PR merge: append 1-2 lines in `Trace (post-merge check)` with actual outcome/impact
+- Every ADR must include at least one **Evidence link** (commit, PR, or test/log evidence).
+
 ---
 
 ## D001: {Decision Title} ({YYYY-MM-DD})
 
 - **Context**: Problem situation or background
+- **Constraints**: Constraints (time/technical/operations/compatibility)
 - **Options**: Alternatives considered
 - **Decision**: Final choice
 - **Rationale**: Reason for choice
+- **Trace**:
+  - **At DOING start**: Initial reasoning/hypothesis
+  - **Before DONE**: Finalized reasoning behind the selected option
+  - **Post-merge check**: Actual outcome/impact observed
+- **Evidence**:
+  - **Commit**: Commit hash or link
+  - **PR**: PR link
+  - **Test/Log**: Test output/log/screenshot path
 - **Consequences**: Results and impact (optional)

package/templates/en/common/features/feature-base/issue.md

@@ -0,0 +1,34 @@
+# Issue Draft: {feature-name}
+
+## Metadata
+
+- **Status**: Draft | Ready
+- **Issue Number**: #{issue-number}
+- **Title**: {feature-name}
+- **Labels**: enhancement
+- **Created**: {YYYY-MM-DD}
+
+## Overview
+
+- Problem/Context:
+- Expected Impact:
+
+## Goals
+
+- [ ] (goal 1)
+- [ ] (goal 2)
+
+## Completion Criteria
+
+- [ ] (verifiable criterion 1)
+- [ ] (verifiable criterion 2)
+
+## Out of Scope
+
+- (what this issue does not cover)
+
+## Related Docs
+
+- Spec: `./spec.md`
+- Plan: `./plan.md`
+- Tasks: `./tasks.md`

package/templates/en/common/features/feature-base/plan.md

@@ -9,7 +9,7 @@
 - **Feature ID**: F{number}
 - **Target Repo**: {{projectName}}-{component}
 - **Created**: {YYYY-MM-DD}
-- **Status**: Review | Approved
+- **Status**: Draft | Review | Approved
 
 ---
 

package/templates/en/common/features/feature-base/pr.md

@@ -0,0 +1,35 @@
+# PR Draft: {feature-name}
+
+## Metadata
+
+- **Status**: Draft | Ready
+- **PR**: -
+- **PR Status**: -
+  - Values: Review | Approved
+- **Base**: main
+- **Created**: {YYYY-MM-DD}
+
+## Overview
+
+- Change purpose:
+- User impact:
+
+## Changes
+
+- [ ] (key change 1)
+- [ ] (key change 2)
+
+## Tests
+
+- [ ] (test run 1)
+- [ ] (test run 2)
+
+## Screenshots / Diagrams
+
+- (attach when needed)
+
+## Related Docs
+
+- Spec: `./spec.md`
+- Tasks: `./tasks.md`
+- Decisions: `./decisions.md`

package/templates/en/common/features/feature-base/spec.md

@@ -11,7 +11,7 @@
 - **Target Repo**: {{projectName}}-{component}
 - **Issue Number**: #{issue-number}
 - **Created**: {YYYY-MM-DD}
-- **Status**: Review | Approved
+- **Status**: Draft | Review | Approved
 
 ---
 

package/templates/en/common/features/feature-base/tasks.md

@@ -12,7 +12,7 @@
 
 ## GitHub Issue
 
-- **Doc Status**: Review | Approved
+- **Doc Status**: Draft | Review | Approved
 - **Repo**: {{projectName}}-{component}
 - **Issue**: #{issue-number}
 - **Branch**: `feat/{issue-number}-{feature-name}`
@@ -22,6 +22,10 @@
   - Values: Review | Approved
 - **Pre-PR Review**: Pending | Done
   - Mark `Done` after pre-PR review is completed
+- **Pre-PR Findings**: major=0, minor=0
+  - Update with final findings counts from pre-PR review
+- **Pre-PR Evidence**: -
+  - Example: review note link, log path, or docs path
 
 ---
 
@@ -34,6 +38,7 @@
 
 ```markdown
 - [TODO][P1] T-F{number}-01 {Task Title}
+  - Date: YYYY-MM-DD
   - Acceptance:
     - (verification condition)
   - Checklist:
@@ -53,8 +58,8 @@
 ### Test Run Log (Latest by Command)
 
 > Keep one row per command. If you rerun the same command, update that row instead of appending.
-> Use `YYYY-MM-DD HH-MM` for `Last Run` (local time).
+> Use `YYYY-MM-DD` for `Last Run` (local date).
 
-| Command | Last Run (Local, YYYY-MM-DD HH-MM) | Result |
+| Command | Last Run (Local, YYYY-MM-DD) | Result |
 | --- | --- | --- |
 | `{test command you ran}` | `-` | `{PASS/FAIL summary}` |

package/templates/ko/common/agents/agents.md

@@ -23,7 +23,7 @@
 확인 절차:
 1. 작업 내용을 먼저 공유
 2. 명시적 승인(OK) 대기
-3. 승인 후 실행
+3. 승인 후 실행 (명령 실행은 기본적으로 `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`를 사용)
 
 금지:
 - 사용자 응답 없이 임의 진행
@@ -38,6 +38,7 @@
 - 사용자가 다른 질문을 하더라도, 실행 가능한 라벨이 있으면 응답 마지막에 동일 블록을 다시 표시합니다.
 - 실행 가능한 라벨이 없으면 `선택 가능: 없음` + `npx lee-spec-kit context` 재확인을 안내합니다.
 - 사용자 입력에 유효 라벨이 없으면 실행하지 말고 라벨 선택을 다시 요청합니다.
+- 승인된 command 옵션 실행은 `flow --approve <LABEL> --execute` 1회 호출을 기본으로 하며, `context --approve`와 `context --execute --ticket`를 턴/세션 사이로 분리하지 않습니다.
 
 출력 형식:
 
@@ -70,8 +71,8 @@ B: <detail>
 - 루트 가이드: `npx lee-spec-kit docs get agents --json`
 - Git 워크플로우: `npx lee-spec-kit docs get git-workflow --json`
 - 태스크 실행: `npx lee-spec-kit docs get execute-task --json`
-- 이슈 절차/템플릿: `npx lee-spec-kit docs get create-issue --json` → `npx lee-spec-kit docs get issue-template --json`
-- PR 절차/템플릿: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-template --json`
+- 이슈 절차/문서: `npx lee-spec-kit docs get create-issue --json` → `npx lee-spec-kit docs get issue-doc --json`
+- PR 절차/문서: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-doc --json`
 
 ---
 
@@ -79,6 +80,7 @@ B: <detail>
 
 - docs 구조/경로 규칙: `docs/README.md`를 SSOT로 사용
 - ADR 작성 형식: `docs/features/.../decisions.md` 템플릿을 SSOT로 사용
+- 이슈/PR 실행 상태: 각 Feature의 `issue.md`, `pr.md`를 SSOT로 사용
 
 ---
 

package/templates/ko/common/agents/issue-template.md

@@ -1,6 +1,7 @@
 # GitHub Issue 템플릿 가이드
 
 에이전트가 GitHub Issue를 생성할 때 참조하는 템플릿입니다.
+이 문서는 섹션 정책/스타일 가이드이며, 실제 진행 상태 관리는 Feature 폴더의 `issue.md`를 SSOT로 사용합니다.
 
 ---
 

package/templates/ko/common/agents/pr-template.md

@@ -1,6 +1,7 @@
 # GitHub PR 템플릿 가이드
 
 에이전트가 Pull Request를 생성할 때 참조하는 템플릿입니다.
+이 문서는 섹션 정책/스타일 가이드이며, 실제 진행 상태 관리는 Feature 폴더의 `pr.md`를 SSOT로 사용합니다.
 
 ---
 

package/templates/ko/common/agents/skills/create-feature.md

@@ -27,6 +27,7 @@ CLI가 출력하는 **`👉 Next Options (Atomic)` 목록에서 단 하나의
 - CLI가 이슈 생성을 지시하면 이슈를 생성합니다.
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 - 승인 요청 시 라벨 옵션은 `A: ...` 형식으로 **CLI가 출력한 원문(detail/cmd) 그대로** 공유합니다. 요약/의역하지 않습니다.
+- 승인된 command 옵션을 실행할 때는 세션 불일치 방지를 위해 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용합니다.
 
 ### 3단계: 반복
 

package/templates/ko/common/agents/skills/create-issue.md

@@ -1,6 +1,7 @@
 # GitHub Issue 생성 프로세스
 
 GitHub Issue를 생성할 때 따르는 가이드입니다.
+실행 상태 SSOT는 Feature 폴더의 `issue.md`입니다.
 
 ---
 
@@ -13,22 +14,22 @@ GitHub Issue를 생성할 때 따르는 가이드입니다.
 
 ## 단계
 
-### 1. 이슈 초안 작성
+### 1. `issue.md` 초안 준비
 
 > 📖 **이번 세션에 아직 읽지 않았다면 `docs get`으로 절차/템플릿을 읽고, 이미 읽은 동일 문서는 재호출하지 않은 채 초안을 생성해 기준으로 사용하세요.**
 
 ```bash
 # 1) 절차/템플릿 정책 확인 (이번 세션 미확인 문서만)
 npx lee-spec-kit docs get create-issue --json
-npx lee-spec-kit docs get issue-template --json
+npx lee-spec-kit docs get issue-doc --json
 
 # 2) 초안 본문 생성 (원격 작업 아님)
 npx lee-spec-kit github issue F001 --json
 ```
 
-`docs get issue-template --json` 출력은 섹션 정책으로 보고,
-`github issue --json`의 `body`를 우선 본문 초안으로 사용하세요.
-필요하면 `bodyFile` 경로 파일을 함께 참고하세요.
+`docs get issue-doc --json` 출력은 문서 구조 정책으로 보고,
+`github issue --json`의 `body`를 참고해 `issue.md` 초안을 보완하세요.
+실제 진행 상태는 `issue.md`의 `상태(Draft | Ready)`를 사용합니다.
 
 | 항목   | 형식                                     |
 | ------ | ---------------------------------------- |
@@ -37,19 +38,19 @@ npx lee-spec-kit github issue F001 --json
 | 라벨   | `enhancement`, `bug`, `documentation` 등 |
 | 담당자 | `@me` (기본값)                           |
 
-### 2. 사용자 확인 요청
+### 2. 사용자 확인 요청 + `Ready` 전환
 
 > 🚨 **사용자 확인 필수**
 
-이슈 생성 전 다음 내용을 공유하고 명시적 승인(OK) 대기:
+`issue.md` 초안 기준으로 다음 내용을 공유하고 명시적 승인(OK) 대기:
 
 - 제목
-- 본문 전체 초안 (`body` 기준)
+- 본문 전체 초안 (`issue.md` 기준)
 - 라벨
 
-생성 전 목표/완료 기준을 spec 기준으로 구체화하고 검토하세요.
+승인 후 `issue.md` 상태를 `Ready`로 변경하세요.
 
-### 3. 이슈 생성
+### 3. 이슈 생성 (`issue.md`가 `Ready`일 때)
 
 ```bash
 gh issue create \
@@ -62,9 +63,15 @@ gh issue create \
 npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 ```
 
+생성 후:
+- 생성된 이슈 번호를 `issue.md`에 기록
+- `spec.md`, `tasks.md`의 이슈 번호도 동기화
+- `issue.md` 상태는 `Ready`로 유지 (`Issue Number`/링크 필드로 생성 상태를 관리)
+
 ---
 
 ## 참조 문서
 
 - **초안 생성기**: `npx lee-spec-kit github issue <feature-name>`
 - **승인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
+- **실행 상태 SSOT**: `docs/features/.../<feature>/issue.md`