lee-spec-kit 0.7.0 → 0.7.2

package/package.json

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

package/templates/en/common/README.md

@@ -52,6 +52,8 @@ To avoid ambiguity, treat the following as the single source of truth (SSOT).
 - **Features (`docs/features/`)**: implementation scope/progress SSOT
   - `spec.md`: scope + `PRD Refs` (the PRD IDs this feature covers)
   - `tasks.md`: map each task line to PRD IDs via bracket tags like `[PRD-FR-001]`, or tag non-PRD tasks as `[NON-PRD]`
+    - Use `[NON-PRD]` only for internal work such as refactors, renames, tooling, tests, and cleanup.
+    - If a task changes user-facing behavior, acceptance criteria, or feature scope, backfill PRD first and tag the task as `[PRD-...]` instead of leaving it as `[NON-PRD]`.
   - For legacy docs without PRD IDs yet, backfill the source requirements doc first, then link the feature docs.
   - `decisions.md`: record changes/trade-offs/requirement changes (why it changed) with evidence links
 
@@ -64,6 +66,10 @@ When requirements/scope change, the “what to update” must be explicit in doc
 2. **If still in Idea stage**:
    - `docs/ideas/*.md`: update `PRD Refs` and in/out scope
 3. **If already a Feature**:
+   - If the change started as a `[NON-PRD]` task but becomes a user-facing requirement/scope change, convert it into PRD-backed work:
+     1. backfill/update `docs/prd/*.md`
+     2. update `spec.md` `PRD Refs`
+     3. retag the task as `[PRD-...]` (or add a replacement task if needed)
    - `docs/features/.../spec.md`: update `PRD Refs` + reflect scope change summary
    - `docs/features/.../tasks.md`: add tasks for the change + tag each task as `[PRD-...]` or `[NON-PRD]`
    - `docs/features/.../plan.md`: update if architecture/testing strategy changed

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

@@ -41,8 +41,9 @@ Prohibited:
 - In non-approval state, do not append labels or `approvalRequest.finalPrompt` unless the user explicitly asked for current options.
 - If approval is still pending after answering an unrelated question, answer first, then re-open approval with the exact CLI-provided approval lines (`approvalRequest.userFacingLines`, or `actionOptions[*].approvalPrompt` + `approvalRequest.finalPrompt` in full `--json`).
 - 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.
+- For non-delegated command options, prefer one-shot `flow --approve <LABEL> --execute`; do not split `context --approve` and `context --execute --ticket` across turns/sessions.
 - If `matchedFeature.currentSubstateOwner="subagent"` and `agentOrchestration.subAgentHandoff.required=true` with `mode="command"`, delegation is mandatory: call `spawn_agent` first. Do not execute that command directly from the main agent.
+- If that delegated command is handoff-only (`handoffOnly=true`, `advancesWorkflow=false`), treat `--execute` as handoff preparation only. Continue the delegated work immediately and do not re-approve the same label.
 - Do not delegate auto loops from `autoRun.available` alone. Delegate auto loops only when `agentOrchestration.subAgentHandoff.required=true` and `agentOrchestration.subAgentHandoff.mode="auto_run"`.
 - Prefer `agentOrchestration.subAgentHandoff` as the handoff SSOT. Pass only its minimal fields (`featureRef`, `category`, `cwd`, `cmd`) to the sub-agent.
 - For delegated runs, execute one-time verification from `subAgentHandoff.verify` (`pwd`, `git rev-parse --show-toplevel`) and cache by `verify.cacheKey`. If mismatched, stop and report; collect detailed logs only on mismatch.

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

@@ -42,7 +42,8 @@ Execute exactly one option from `👉 Next Options (Atomic)` as printed by the C
 - Treat `AUTO_MANUAL_REQUIRED` as an automation boundary (instruction-only segment), not an immediate crash. Re-check `context --json-compact` and report whether `approvalRequest.required` is now true.
 - If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
 - Follow `agents.md` **"Label Response Contract (SSOT)"**. Show label prompts only in approval-waiting state, and reuse the exact CLI-provided approval lines instead of paraphrasing them.
-- 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.
+- For non-delegated 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.
+- If the current command is delegated (`matchedFeature.currentSubstateOwner="subagent"` and `agentOrchestration.subAgentHandoff.required=true` with `mode="command"`), call `spawn_agent` first and pass the handoff contract instead of executing that command from the main agent.
 - If `flow/context --execute --json` returns `approved_handoff_prepared`, stop re-approving the same label. Complete the delegated work first, then refresh context.
 
 ### Step 3: Update tasks.md (only what you did)

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

@@ -64,6 +64,8 @@ npx lee-spec-kit status --write
 
 - Assign stable requirement IDs in PRD docs (`docs/prd/*.md`) like `PRD-FR-001`.
 - Link each task line in `tasks.md` with a tag like `[PRD-FR-001]`. For non-PRD tasks, use `[NON-PRD]`.
+- Use `[NON-PRD]` only for internal implementation work such as refactors, test-only work, tooling, renames, and cleanup.
+- If a change affects user-facing behavior, acceptance criteria, or scope, update PRD first and retag the task as `[PRD-...]`.
 - Do not invent PRD IDs inside feature docs. Define them in the PRD source first, and backfill legacy docs before linking tasks.
 - Coverage report: `npx lee-spec-kit requirements` (alias: `npx lee-spec-kit prd`)
 
@@ -75,6 +77,10 @@ When things change mid-work, it must be explicit what was updated.
 
 - Record changes as **new tasks** (do not edit `[DONE]` tasks; create a new task instead).
 - Every change task must be tagged as `[PRD-...]` or `[NON-PRD]`. (Recommended: also add `[CHANGE]`.)
+- If a change starts as internal exploration but ends up changing user-visible behavior, do not leave it as `[NON-PRD]`.
+  - Backfill/update `docs/prd/*.md`
+  - Update `spec.md` `PRD Refs`
+  - Retag the task as `[PRD-...]` or add a replacement PRD-backed task
 - If the change impacts PRD/spec/plan, update these too:
   - `docs/prd/*.md` (add/update/deprecate requirement IDs)
   - `spec.md` (`PRD Refs`, scope/AC)

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

@@ -59,3 +59,4 @@
   - Only list IDs that already exist in the source requirements doc. Do not invent PRD IDs in `spec.md` or `tasks.md`.
   - If this is a legacy requirements doc without PRD IDs yet, backfill IDs in the source first, then update this field and the `tasks.md` task tags together.
   - When requirements/scope change, update PRD docs + this field + `tasks.md` task tags together.
+  - If implementation discovers a better user-facing behavior and the shipped requirement changes, treat that as a PRD update, not a permanent `[NON-PRD]` exception.

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

@@ -10,6 +10,7 @@
 - **PRD mapping (recommended)**: add a PRD requirement ID tag like `[PRD-FR-001]` to each task line, or tag non-PRD tasks as `[NON-PRD]`.
   - Do not invent PRD IDs in `tasks.md`. Only reference IDs that already exist in `docs/prd` or the upstream requirements doc.
   - If this is a legacy feature without PRD IDs yet, backfill IDs in the source requirements doc first, then align `spec.md` `PRD Refs` and task tags together.
+  - `[NON-PRD]` is for internal implementation work only. If the task changes user-facing behavior, acceptance criteria, or scope, backfill PRD first and tag it as `[PRD-...]`.
 
 ---
 
@@ -60,6 +61,7 @@
 ```
 
 > `PRD-FR-001` in the example means an ID that already exists in the PRD source. If it is not defined yet, do not add it to tasks first.
+> If a task began as exploration/internal work but became a product requirement change, update PRD first, then retag the task from `[NON-PRD]` to `[PRD-...]`.
 
 (Recommended) Requirement/scope change task:
 
@@ -74,6 +76,8 @@ Record mid-work changes as **new tasks**, and explicitly list which docs need up
     - decisions.md (why it changed + evidence)
 ```
 
+> Use `[NON-PRD][CHANGE]` only when the change stays internal and does not alter user-visible requirements.
+
 ---
 
 ## Completion Criteria

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

@@ -8,31 +8,32 @@ Core rule: once an idea becomes a Feature, the SSOT moves to `docs/features/`.
 
 ## Conventions
 
-- 1 idea = 1 file (kebab-case recommended)
-  - Example: `login-rate-limit.md`
-  - Example: `admin-dashboard-metrics.md`
+- 1 idea = 1 file
+  - CLI-generated ideas use indexed names like `I001-login-rate-limit.md`
+  - Legacy free-form names like `login-rate-limit.md` can still exist
 - Put at least these at the top:
+  - `Idea ID` (`I###` for indexed ideas)
   - Goal / context
   - Rough scope (what’s in/out)
   - PRD Refs (recommended): `PRD-FR-001, PRD-US-002` (use `NON-PRD` when not tied to PRD)
   - Target component (optional): `api` / `app` / `worker` / `all`
-  - Status (recommended): `Active | Converted | Dropped`
+  - Status: `Active | Featureized | Dropped`
+  - Feature: `F###-slug` when promoted
 - Only list IDs that already exist in the source PRD/requirements doc. If IDs do not exist yet, backfill the source first.
 
 ---
 
 ## Promotion / Cleanup (Idea → Feature)
 
-1. Create a Feature folder with `npx lee-spec-kit feature <name>`
-2. In the new Feature, record all of the following:
-   - Idea doc path in `spec.md` or `tasks.md` (example: `docs/ideas/login-rate-limit.md`)
-   - `PRD Refs` in `spec.md` (example: `PRD-FR-001, PRD-US-002`)
-   - PRD mapping tags in `tasks.md` task lines like `[PRD-FR-001]` (use `[NON-PRD]` for non-PRD tasks)
-3. Remove the idea from the active list (choose one):
-   - **Recommended**: move to `docs/ideas/archive/` and add `Status: Converted`, `Feature: F00X-...` on top
-   - Or: delete it (only if you don’t need history)
+1. Create an idea doc with `npx lee-spec-kit idea <name>` when you want traceable intake.
+2. Promote it with `npx lee-spec-kit feature <name> --idea I001`
+3. In the new Feature, record all of the following:
+- The source idea path is stamped into `spec.md` automatically when `--idea` is used.
+- `PRD Refs` still need to be completed in `spec.md`.
+- `tasks.md` still needs PRD mapping tags like `[PRD-FR-001]`.
+4. Keep the idea doc for history and update it to `Status: Featureized`, `Feature: F00X-...`
 
-> Tip: archiving is usually better than deleting for traceability (“why this feature exists”).
+> Tip: keeping the source idea doc is usually better than deleting it for traceability (“why this feature exists”).
 
 ---
 

package/templates/en/common/ideas/idea.md

@@ -0,0 +1,36 @@
+# Idea: {idea-name}
+
+---
+
+## Overview
+
+- **Idea ID**: {idea-id}
+- **Idea Name**: {idea-name}
+- **Created**: {YYYY-MM-DD}
+- **Status**: Active
+  - Values: Active | Featureized | Dropped
+- **Feature**: -
+- **PRD Refs**: -
+- **Component**: {component}
+
+---
+
+## Context
+
+{{description}}
+
+(Why is this idea worth exploring?)
+
+---
+
+## Rough Scope
+
+- In:
+- Out:
+
+---
+
+## Promotion Notes
+
+- What should stay true if this becomes a feature?
+- What risks or unanswered questions remain?

package/templates/ko/common/README.md

@@ -52,6 +52,8 @@ npx lee-spec-kit context --json-compact
 - **Features (`docs/features/`)**: 구현 범위/진행 SSOT
   - `spec.md`: 범위 정의 + `PRD Refs`(기능이 커버하는 PRD ID 목록)
   - `tasks.md`: 태스크 단위로 PRD ID를 태그(`[PRD-FR-001]`)로 매핑하거나, PRD 무관 태스크는 `[NON-PRD]`로 표시
+    - `[NON-PRD]`는 refactor, rename, tooling, 테스트, cleanup 같은 내부 작업에만 사용합니다.
+    - 태스크가 사용자 동작, acceptance criteria, 기능 범위를 바꾸게 되면 `[NON-PRD]`로 끝내지 말고 PRD를 backfill한 뒤 `[PRD-...]`로 연결합니다.
   - 레거시 문서에 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 Feature 문서를 연결합니다.
   - `decisions.md`: 변경/트레이드오프/요구사항 변경(왜 바뀌었는지) 기록 + Evidence 링크
 
@@ -64,6 +66,10 @@ npx lee-spec-kit context --json-compact
 2. **Idea 단계라면**:
    - `docs/ideas/*.md`: `PRD Refs` 및 범위(포함/제외) 갱신
 3. **Feature 단계라면**:
+   - 시작은 `[NON-PRD]`였더라도, 진행 중 사용자 요구/동작/범위 변경으로 바뀌었다면 PRD 기반 작업으로 승격합니다:
+     1. `docs/prd/*.md` backfill/수정
+     2. `spec.md`의 `PRD Refs` 갱신
+     3. 해당 태스크를 `[PRD-...]`로 재태깅 (필요하면 대체 태스크 추가)
    - `docs/features/.../spec.md`: `PRD Refs` 갱신 + 스코프 변경 요약 반영
    - `docs/features/.../tasks.md`: 변경을 반영하는 새 태스크 추가 + 각 태스크에 `[PRD-...]` 또는 `[NON-PRD]` 태그 부여
    - `docs/features/.../plan.md`: 아키텍처/테스트 전략이 바뀌면 함께 갱신

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

@@ -41,8 +41,9 @@
 - 비승인 상태의 진행 보고/분석/일반 답변에서는 라벨 블록이나 `approvalRequest.finalPrompt`를 덧붙이지 않습니다. 현재 옵션을 사용자가 직접 물었을 때만 예외입니다.
 - 관련 없는 질문에 먼저 답한 뒤에도 승인이 여전히 필요하면, 답변 후 CLI가 준 승인 문구(`approvalRequest.userFacingLines`, 또는 전체 `--json`의 `actionOptions[*].approvalPrompt` + `approvalRequest.finalPrompt`)를 다시 제시합니다.
 - 사용자 입력에 유효 라벨이 없으면 실행하지 말고 라벨 선택을 다시 요청합니다.
-- 승인된 command 옵션 실행은 `flow --approve <LABEL> --execute` 1회 호출을 기본으로 하며, `context --approve`와 `context --execute --ticket`를 턴/세션 사이로 분리하지 않습니다.
+- 위임 대상이 아닌 command 옵션은 `flow --approve <LABEL> --execute` 1회 호출을 기본으로 하며, `context --approve`와 `context --execute --ticket`를 턴/세션 사이로 분리하지 않습니다.
 - `matchedFeature.currentSubstateOwner="subagent"`이고 `agentOrchestration.subAgentHandoff.required=true`이며 `mode="command"`면 위임이 필수입니다. 먼저 `spawn_agent`를 호출하고, 해당 명령을 메인 에이전트에서 직접 실행하지 않습니다.
+- 그 delegated command가 handoff-only(`handoffOnly=true`, `advancesWorkflow=false`)라면 `--execute`는 handoff 준비까지만 의미합니다. 바로 delegated work를 이어서 수행하고 같은 라벨을 다시 승인 루프로 열지 마세요.
 - `autoRun.available`만으로 auto 루프 위임을 결정하지 않습니다. `agentOrchestration.subAgentHandoff.required=true`이고 `agentOrchestration.subAgentHandoff.mode="auto_run"`일 때만 auto 루프를 서브 에이전트에 위임합니다.
 - 위임 시에는 `agentOrchestration.subAgentHandoff`를 handoff SSOT로 사용하고, 최소 필드(`featureRef`, `category`, `cwd`, `cmd`)만 전달합니다.
 - 위임 실행 전 `subAgentHandoff.verify`의 검증 명령(`pwd`, `git rev-parse --show-toplevel`)을 세션당 1회만 실행하고(`verify.cacheKey` 기준), 불일치 시 즉시 중단/보고합니다. 상세 로그 수집은 불일치 시에만 수행합니다.

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

@@ -42,7 +42,8 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 - `AUTO_MANUAL_REQUIRED`는 실패가 아니라 자동화 경계(현재 instruction-only 구간)입니다. 즉시 오류로 단정하지 말고 현재 `context --json-compact`를 다시 확인한 뒤 승인 필요 여부(`approvalRequest.required`)를 보고합니다.
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 - 사용자 응답 포맷은 `agents.md`의 **"라벨 응답 계약 (SSOT)"** 을 따릅니다. 라벨 문구는 승인 대기 상태에서만 보여주고, CLI가 준 승인 문구를 임의로 바꾸지 않습니다.
-- 승인된 command 옵션 실행은 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용하고, `context --approve`와 `context --execute --ticket` 분리 실행은 지양합니다.
+- 위임 대상이 아닌 command 옵션 실행은 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용하고, `context --approve`와 `context --execute --ticket` 분리 실행은 지양합니다.
+- 현재 command가 delegated 상태(`matchedFeature.currentSubstateOwner="subagent"` + `agentOrchestration.subAgentHandoff.required=true` + `mode="command"`)라면 메인 에이전트에서 직접 실행하지 말고 먼저 `spawn_agent`를 호출해 handoff 계약을 넘기세요.
 - `flow/context --execute --json` 결과가 `approved_handoff_prepared`이면 같은 라벨을 다시 승인 루프로 열지 말고, 먼저 delegated work를 완료한 뒤 context를 새로 확인합니다.
 
 ### 3단계: 기록 및 반복 (Record & Loop)

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

@@ -64,6 +64,8 @@ npx lee-spec-kit status --write
 
 - PRD 문서(`docs/prd/*.md`)에 `PRD-FR-001` 같은 요구사항 ID를 부여하세요.
 - `tasks.md`의 각 태스크 라인에 `[PRD-FR-001]` 태그로 연결하세요. PRD와 무관한 태스크는 `[NON-PRD]`를 사용하세요.
+- `[NON-PRD]`는 refactor, 테스트 전용 작업, tooling, rename, cleanup 같은 내부 구현 작업에만 사용하세요.
+- 변경이 사용자 동작, acceptance criteria, 범위를 바꾸면 PRD를 먼저 갱신하고 태스크도 `[PRD-...]`로 다시 연결하세요.
 - 단, 태스크 문서에서 PRD ID를 임의 생성하지 않습니다. 먼저 PRD 원문에 정의하고, 레거시 문서는 원문 ID backfill 후 연결하세요.
 - 커버리지 리포트: `npx lee-spec-kit requirements` (alias: `npx lee-spec-kit prd`)
 
@@ -75,6 +77,10 @@ npx lee-spec-kit status --write
 
 - 변경은 **새 태스크로 추가**합니다. (`[DONE]` 태스크를 고치지 말고 새 태스크를 만드세요)
 - 변경 태스크에는 `[PRD-...]` 또는 `[NON-PRD]` 태그를 반드시 붙입니다. (권장: `[CHANGE]` 태그 추가)
+- 내부 검토로 시작했더라도, 최종적으로 사용자 요구/동작 변경이 되면 `[NON-PRD]`로 남기지 않습니다.
+  - `docs/prd/*.md`를 backfill/수정
+  - `spec.md`의 `PRD Refs` 갱신
+  - 태스크를 `[PRD-...]`로 재태깅하거나 대체 태스크 추가
 - 변경이 PRD/스펙/설계에 영향을 주면 아래도 함께 갱신합니다:
   - `docs/prd/*.md` (요구사항 ID 추가/수정/Deprecated)
   - `spec.md` (`PRD Refs`, 스코프/AC)

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

@@ -59,3 +59,4 @@
   - 이미 원문 요구사항 문서에 정의된 ID만 적으세요. `spec.md`나 `tasks.md`에서 임의로 PRD ID를 만들지 않습니다.
   - 레거시 요구사항 문서에 아직 PRD ID가 없다면, 먼저 원문에 ID를 backfill한 뒤 이 필드와 `tasks.md` 태스크 태그를 함께 갱신하세요.
   - 요구사항/스코프 변경 시 PRD 문서 + 이 필드 + `tasks.md` 태스크 태그를 함께 갱신하세요.
+  - 구현 중 더 나은 사용자 동작이 발견되어 최종 요구사항이 바뀌었다면, 이를 영구적인 `[NON-PRD]` 예외로 두지 말고 PRD 업데이트로 취급하세요.

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

@@ -10,6 +10,7 @@
 - **PRD 매핑(권장)**: 각 태스크 라인에 `[PRD-FR-001]` 같은 PRD 요구사항 ID 태그를 추가하거나, PRD와 무관한 태스크는 `[NON-PRD]`로 표시하세요.
   - 단, `tasks.md`에서 PRD ID를 임의로 만들지 마세요. `docs/prd` 또는 상위 요구사항 문서에 먼저 정의된 ID만 참조해야 합니다.
   - 레거시 문서에 아직 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 `spec.md`의 `PRD Refs`와 태스크 태그를 함께 맞추세요.
+  - `[NON-PRD]`는 내부 구현 작업 전용입니다. 사용자 동작, acceptance criteria, 범위가 바뀌는 태스크라면 PRD를 먼저 backfill하고 `[PRD-...]`로 태깅하세요.
 
 ---
 
@@ -60,6 +61,7 @@
 ```
 
 > 위 예시의 `PRD-FR-001`은 이미 PRD 원문에 존재하는 ID를 뜻합니다. 아직 정의되지 않았다면 태스크에 먼저 넣지 마세요.
+> 처음엔 탐색/내부 작업이었더라도 제품 요구사항 변경으로 이어졌다면, `NON-PRD`로 두지 말고 PRD를 먼저 갱신한 뒤 `[PRD-...]`로 재태깅하세요.
 
 (권장) 요구사항/범위 변경 태스크:
 
@@ -74,6 +76,8 @@
     - decisions.md (변경 사유 + Evidence)
 ```
 
+> `[NON-PRD][CHANGE]`는 내부 변경으로 끝날 때만 사용하세요. 사용자에게 보이는 요구사항 변경이면 PRD backfill이 먼저입니다.
+
 ---
 
 ## 완료 조건

package/templates/ko/common/ideas/README.md

@@ -8,31 +8,32 @@ Feature로 발전하기 전의 아이디어 / To-do / 실험 기록을 모아두
 
 ## 작성 규칙
 
-- 1 아이디어 = 1 파일 (kebab-case 권장)
-  - 예: `login-rate-limit.md`
-  - 예: `admin-dashboard-metrics.md`
+- 1 아이디어 = 1 파일
+  - CLI로 생성한 문서는 `I001-login-rate-limit.md` 같은 indexed 이름을 사용합니다
+  - 기존의 `login-rate-limit.md` 같은 자유 형식 파일도 유지할 수 있습니다
 - 상단에 최소한 아래 메타 정보를 둡니다:
+  - `Idea ID` (`I###` 형식의 indexed idea인 경우)
   - 목적/배경
   - 대략 범위(뭘 할지/안 할지)
   - PRD Refs(권장): `PRD-FR-001, PRD-US-002` (PRD와 무관하면 `NON-PRD` 명시)
   - 대상 컴포넌트(필요 시): `api` / `app` / `worker` / `all`
-  - 상태(권장): `Active | Converted | Dropped`
+  - 상태: `Active | Featureized | Dropped`
+  - Feature: 승격되면 `F###-slug`
 - `PRD Refs`에는 이미 원문 PRD/요구사항 문서에 정의된 ID만 적습니다. 아직 ID가 없다면 원문부터 backfill하세요.
 
 ---
 
 ## 승격/정리 규칙 (Idea → Feature)
 
-1. `npx lee-spec-kit feature <name>`로 Feature 폴더 생성
-2. 새 Feature에 아래를 모두 남깁니다
-   - `spec.md` 또는 `tasks.md`에 아이디어 문서 경로 (예: `docs/ideas/login-rate-limit.md`)
-   - `spec.md`의 `PRD Refs`(예: `PRD-FR-001, PRD-US-002`)
-   - `tasks.md` 태스크 라인에 `[PRD-FR-001]` 같은 PRD ID 태그 (PRD와 무관한 태스크는 `[NON-PRD]`)
-3. 아이디어 문서는 **목록에서 제거**합니다 (둘 중 하나 선택):
-   - **권장**: `docs/ideas/archive/`로 이동 후 상단에 `Status: Converted`, `Feature: F00X-...` 기록
-   - 또는: 완전히 삭제 (히스토리가 필요 없을 때만)
+1. 추적 가능한 intake가 필요하면 `npx lee-spec-kit idea <name>`로 아이디어 문서를 먼저 만듭니다
+2. Feature 승격 시 `npx lee-spec-kit feature <name> --idea I001`를 사용합니다
+3. `--idea`를 사용하면 새 Feature의 `spec.md`에 source idea 경로가 자동 기록됩니다
+4. 승격 후에도 다음은 직접 채워야 합니다
+   - `spec.md`의 `PRD Refs`
+   - `tasks.md` 태스크 라인의 PRD ID 태그(`[PRD-FR-001]` 등)
+5. 아이디어 문서는 삭제하지 말고 `Status: Featureized`, `Feature: F00X-...`로 남기는 것을 권장합니다
 
-> 💡 완전 삭제 대신 archive를 권장합니다: “왜 이 Feature가 생겼는지” 추적에 도움이 됩니다.
+> 💡 source idea 문서를 남겨두면 “왜 이 Feature가 생겼는지” 추적하기 쉽습니다.
 
 ---
 

package/templates/ko/common/ideas/idea.md

@@ -0,0 +1,36 @@
+# Idea: {idea-name}
+
+---
+
+## 개요
+
+- **Idea ID**: {idea-id}
+- **Idea Name**: {idea-name}
+- **Created**: {YYYY-MM-DD}
+- **Status**: Active
+  - 값: Active | Featureized | Dropped
+- **Feature**: -
+- **PRD Refs**: -
+- **Component**: {component}
+
+---
+
+## 배경
+
+{{description}}
+
+(왜 이 아이디어를 검토할 가치가 있는지)
+
+---
+
+## 대략 범위
+
+- In:
+- Out:
+
+---
+
+## 승격 메모
+
+- Feature가 되어도 유지되어야 할 점은 무엇인가?
+- 아직 남아 있는 리스크나 미해결 질문은 무엇인가?