lee-spec-kit 0.7.2 → 0.7.3

package/package.json

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

package/templates/en/common/README.md

@@ -56,6 +56,12 @@ To avoid ambiguity, treat the following as the single source of truth (SSOT).
     - 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
+- **Shared planning artifacts (`docs/plans/`, `docs/superpowers/specs/`, `docs/superpowers/plans/`)**: staging/reference docs
+  - These may be created by external agent workflows such as `superpowers`.
+  - Once a feature is active, these artifacts are inputs only. The final SSOT stays in the feature folder.
+  - Normalize them into feature-local docs:
+    - design/spec artifact → `spec.md`, `plan.md`, `decisions.md`
+    - implementation plan artifact → `plan.md`, `tasks.md`
 
 ## Change Protocol (When Requirements/Scope Change Mid-Work)
 
@@ -70,6 +76,7 @@ When requirements/scope change, the “what to update” must be explicit in doc
      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)
+   - If shared planning artifacts exist (`docs/plans/*`, `docs/superpowers/specs/*`, `docs/superpowers/plans/*`), absorb them into the feature docs before treating them as part of the active workflow.
    - `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

@@ -15,8 +15,8 @@ This document covers **policy only**.
 | Spec writing | After writing `spec.md` | Full spec content |
 | Task execution | Before each task | Task title |
 | Commit creation | Before `git commit` | Commit message, included files |
-| Issue creation | Before `gh issue create` | Title, body, labels |
-| PR creation | Before `gh pr create` | Title, body, labels |
+| Issue creation | Before `npx lee-spec-kit github issue <featureRef> --create` | Title, body, labels |
+| PR creation | Before `npx lee-spec-kit github pr <featureRef> --create` | Title, body, labels |
 | Assignee change | When assigning someone else | Target username |
 | Remote Git operations | Before `push`, `merge` (including merge commits) | Branch, changes |
 
@@ -35,7 +35,8 @@ Prohibited:
 - Treat approval-waiting as a separate state. Approval-waiting means `context --json-compact` (or `context --json`) exposes executable `actionOptions[]` and you are explicitly waiting for user approval.
 - Use the latest `npx lee-spec-kit context --json-compact` as the default source (fallback: `context --json` or `flow --json` when full detail is required; prefer `flow --json-compact` for default flow output).
 - When using auto results from `flow --json-compact` (or `flow --json`), treat `autoRun.resume.flowCommand` as SSOT for resume (including after context compression/reset).
-- Treat `AUTO_MANUAL_REQUIRED` as an automation boundary, not an immediate failure. Re-check `context --json-compact`, then decide stop/report by `approvalRequest.required` (`context --json` only for full-detail debugging fields).
+- Treat `AUTO_DELEGATED_HANDOFF` as a delegated pause, not a failure. Continue or resume the delegated run path and do not reopen the same approval label.
+- Treat `AUTO_MANUAL_REQUIRED` as an instruction-only automation boundary, not an immediate failure. Re-check `context --json-compact`, then decide stop/report by `approvalRequest.required` (`context --json` only for full-detail debugging fields).
 - In approval-waiting state, prefer `approvalRequest.userFacingLines` from `context --json-compact`. If full `--json` is used, fall back to `actionOptions[*].approvalPrompt` plus `approvalRequest.finalPrompt`. Do not add your own rewritten label summary before or between those lines.
 - Prefer `matchedFeature.currentSubstateOwner` plus `agentOrchestration.subAgentHandoff` as the delegation SSOT.
 - In non-approval state, do not append labels or `approvalRequest.finalPrompt` unless the user explicitly asked for current options.
@@ -81,6 +82,7 @@ Approval-waiting output must reuse the exact CLI-provided prompt lines. Do not i
 ## Scope Split
 
 - Docs structure/path rules: use `docs/README.md` as SSOT
+- Shared planning artifacts (`docs/plans/*`, `docs/superpowers/specs/*`, `docs/superpowers/plans/*`) are staging/reference inputs only. When a feature is active, normalize them into feature-local docs and treat the feature folder as the final 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

@@ -120,11 +120,7 @@ In GitHub Issues, use different link formats **based on file location**:
 
 - Default: Self-assign (`--assignee @me`)
 - When assigning others, **confirm with user** first
-- Examples:
-  ```bash
-  gh issue create --assignee @me ...
-  gh issue create --assignee username ...
-  ```
+- Remote creation must use `npx lee-spec-kit github issue <featureRef> --create --confirm OK --labels ...`.
 
 ---
 

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

@@ -102,13 +102,7 @@ Closes #{issue-number}
 ## PR Creation Command
 
 ```bash
-# Check current branch name
-BRANCH=$(git branch --show-current)
-
-gh pr create \
-  --title "feat(#{issue}): {feature-name} ({short description})" \
-  --body-file /tmp/pr-body.md \
-  --base main
+npx lee-spec-kit github pr <featureRef> --create --confirm OK --labels enhancement
 ```
 
 ---
@@ -156,10 +150,7 @@ git pull
 
 - Default: Self-assign (`--assignee @me`)
 - Use `--reviewer` option to specify reviewers
-- Examples:
-  ```bash
-  gh pr create --assignee @me --reviewer reviewer-username ...
-  ```
+- Remote creation must use `npx lee-spec-kit github pr <featureRef> --create --confirm OK --labels ...`.
 
 ---
 

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

@@ -49,6 +49,9 @@ After completing the action, go back to Step 1 and run `context` again.
 
 If the Feature folder does not exist yet:
 
+- If the user's request includes an explicit Idea ref such as `I001`, `I001-slug`, or `docs/ideas/...`, preserve that ref and create the feature with `npx lee-spec-kit feature <name> --idea <ref>`.
+- Do not infer an Idea ref. Use `--idea` only when the request explicitly names one.
+
 ```bash
 # 1) Create the folder
 npx lee-spec-kit feature <name> -d "<description>"

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

@@ -52,14 +52,10 @@ After approval, set `issue.md` status to `Ready`.
 
 ### 3. Create Issue (when `issue.md` is `Ready`)
 
-```bash
-gh issue create \
-  --title "{feature-name} ({description})" \
-  --body-file /tmp/issue-body.md \
-  --assignee @me \
-  --label enhancement
+Remote issue creation must use the lee-spec-kit helper.
+Do not call `gh issue create` directly or pass raw `issue.md` to `--body-file`.
 
-# Or via lee-spec-kit helper (requires explicit confirmation)
+```bash
 npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 ```
 
@@ -72,5 +68,6 @@ After creation:
 ## Reference Documents
 
 - **Draft generator**: `npx lee-spec-kit github issue <feature-name>`
+- **Remote creation rule**: must use `npx lee-spec-kit github issue <feature-name> --create --confirm OK --labels ...`
 - **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

@@ -160,15 +160,10 @@ After approval, set `pr.md` status to `Ready`.
 
 ### 5. Create PR (when `pr.md` is `Ready`)
 
+Remote PR creation must use the lee-spec-kit helper.
+Do not call `gh pr create` directly or pass raw `pr.md` to `--body-file`.
+
 ```bash
-gh pr create \
-  --title "feat(#{issue-number}): {feature} ({short description})" \
-  --body-file /tmp/pr-body.md \
-  --label "{label1,label2}" \
-  --assignee @me \
-  --base main
-
-# Or via lee-spec-kit helper (requires explicit confirmation)
 npx lee-spec-kit github pr F001 --create --confirm OK --labels enhancement
 ```
 
@@ -217,5 +212,6 @@ Use **current branch name** for file links in PR body:
 ## Reference Documents
 
 - **Body template generator**: `npx lee-spec-kit github pr <feature-name>`
+- **Remote creation rule**: must use `npx lee-spec-kit github pr <feature-name> --create --confirm OK --labels ...`
 - **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

@@ -39,6 +39,7 @@ Execute exactly one option from `👉 Next Options (Atomic)` as printed by the C
 - If `autoRun.policyEligible=true` but `autoRun.executableNow=false`, handle `autoRun.manualBoundary` first instead of starting an auto loop.
 - For long-running auto execution, start with `flow <feature> --auto-... --start-auto --json-compact` and prefer `autoRun.run.resumeCommand` (`flow --resume <RUN_ID>`) after interruption/compression (`--json` only when full-detail debugging fields are required).
 - If auto execution stops, treat `autoRun.resume` from `flow --json-compact` (or `flow --json`) as SSOT. After interruption/compression, resume with `autoRun.resume.flowCommand`; if needed, check current state first with `autoRun.resume.contextCommand`.
+- Treat `AUTO_DELEGATED_HANDOFF` as a delegated pause, not a crash. Reuse the delegated run path and continue the delegated work before asking for a fresh approval label.
 - 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.
@@ -52,6 +53,8 @@ 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.
+- If you need to add a new task, append it directly below the last existing task block in the `Task List` section.
+- Do not insert it near the current task, in the middle of the same phase, or right before `Completion Criteria` / the next `##` heading.
 
 ### Step 3.25: Record decisions (strongly recommended, effectively required)
 

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

@@ -89,6 +89,25 @@ When things change mid-work, it must be explicit what was updated.
 
 ---
 
+## Shared Planning Artifacts (`superpowers`, etc.)
+
+External agent workflows may create shared design/plan docs such as:
+
+- `docs/plans/*.md`
+- `docs/superpowers/specs/*.md`
+- `docs/superpowers/plans/*.md`
+
+When a feature is already in progress, treat those files as staging/reference artifacts, not the active workflow SSOT.
+
+- Move user-facing scope and acceptance criteria into `spec.md`
+- Move architecture/file structure/test strategy into `plan.md`
+- Move executable work items into `tasks.md`
+- Move trade-offs, rejected options, and rationale into `decisions.md`
+
+Keeping the shared artifact for history is fine, but when it conflicts with feature-local docs, the feature folder wins.
+
+---
+
 ## Status Glossary
 
 | Scope | Field | Values |

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

@@ -1,6 +1,7 @@
 # Decisions Log
 
 Record technical decisions and their rationale.
+If a shared design/spec artifact exists (`docs/plans/*` or `docs/superpowers/specs/*`), capture the accepted trade-offs and rationale here so the active feature keeps its own decision trail.
 
 > ADR (Architecture Decision Record) captures important technical or architectural choices made during implementation.
 > Write ADRs so the team can trace why a choice was made and revisit trade-offs later.

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

@@ -1,6 +1,7 @@
 # Implementation Plan: {feature-name}
 
 > Write after spec is approved.
+> If a shared planning artifact exists (`docs/plans/*` or `docs/superpowers/plans/*`), absorb its architecture/file/test content here and treat this file as the final feature-local SSOT.
 
 ---
 

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

@@ -66,6 +66,7 @@
 (Recommended) Requirement/scope change task:
 
 Record mid-work changes as **new tasks**, and explicitly list which docs need updating via `Impact Docs`.
+When adding a new task, append it below the last existing task block in `Task List` instead of inserting it near the current task or in the middle of a phase.
 
 ```markdown
 - [TODO][P1][PRD-FR-001][CHANGE] T-F{number}-02 {Task Title} (requirement/scope change)

package/templates/ko/common/README.md

@@ -56,6 +56,12 @@ npx lee-spec-kit context --json-compact
     - 태스크가 사용자 동작, acceptance criteria, 기능 범위를 바꾸게 되면 `[NON-PRD]`로 끝내지 말고 PRD를 backfill한 뒤 `[PRD-...]`로 연결합니다.
   - 레거시 문서에 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 Feature 문서를 연결합니다.
   - `decisions.md`: 변경/트레이드오프/요구사항 변경(왜 바뀌었는지) 기록 + Evidence 링크
+- **공용 계획 산출물 (`docs/plans/`, `docs/superpowers/specs/`, `docs/superpowers/plans/`)**: staging/reference 문서
+  - `superpowers` 같은 외부 에이전트 워크플로우가 이 위치에 문서를 만들 수 있습니다.
+  - Feature가 활성화된 뒤에는 이 문서들이 입력 자료일 뿐이며, 최종 SSOT는 Feature 폴더에 남습니다.
+  - 아래처럼 feature-local 문서로 정규화하세요:
+    - design/spec 산출물 → `spec.md`, `plan.md`, `decisions.md`
+    - implementation plan 산출물 → `plan.md`, `tasks.md`
 
 ## 변경 프로토콜 (중간에 요구사항/기능이 추가·변경될 때)
 
@@ -70,6 +76,7 @@ npx lee-spec-kit context --json-compact
      1. `docs/prd/*.md` backfill/수정
      2. `spec.md`의 `PRD Refs` 갱신
      3. 해당 태스크를 `[PRD-...]`로 재태깅 (필요하면 대체 태스크 추가)
+   - `docs/plans/*`, `docs/superpowers/specs/*`, `docs/superpowers/plans/*` 같은 공용 계획 문서가 있으면, 활성 워크플로우에 넣기 전에 먼저 Feature 문서로 흡수합니다.
    - `docs/features/.../spec.md`: `PRD Refs` 갱신 + 스코프 변경 요약 반영
    - `docs/features/.../tasks.md`: 변경을 반영하는 새 태스크 추가 + 각 태스크에 `[PRD-...]` 또는 `[NON-PRD]` 태그 부여
    - `docs/features/.../plan.md`: 아키텍처/테스트 전략이 바뀌면 함께 갱신

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

@@ -15,8 +15,8 @@
 | 스펙 작성 | `spec.md` 작성 후 | 스펙 내용 전문 |
 | 태스크 실행 | 각 태스크 시작 전 | 태스크 제목 |
 | 커밋 생성 | `git commit` 전 | 커밋 메시지, 포함 파일 목록 |
-| 이슈 생성 | `gh issue create` 전 | 제목, 본문, 라벨 |
-| PR 생성 | `gh pr create` 전 | 제목, 본문, 라벨 |
+| 이슈 생성 | `npx lee-spec-kit github issue <featureRef> --create` 전 | 제목, 본문, 라벨 |
+| PR 생성 | `npx lee-spec-kit github pr <featureRef> --create` 전 | 제목, 본문, 라벨 |
 | Assignee 변경 | 본인 외 지정 시 | 대상 사용자명 |
 | Git 원격 작업 | `push`, `merge` 전 (머지 커밋 포함) | 브랜치, 변경 사항 |
 
@@ -35,7 +35,8 @@
 - 승인 대기 상태를 별도 상태로 취급합니다. 승인 대기란 `context --json-compact`(또는 `context --json`)에 실행 가능한 `actionOptions[]`가 있고, 현재 사용자의 승인을 기다리는 경우를 의미합니다.
 - 기준 데이터는 최신 `npx lee-spec-kit context --json-compact`를 기본으로 사용하고, 상세 필드가 필요할 때만 `context --json` 또는 `flow --json`을 사용합니다. (`flow`는 기본적으로 `--json-compact` 우선)
 - `flow --json-compact`(또는 `flow --json`)의 auto 결과를 사용할 때는 `autoRun.resume.flowCommand`를 재개 SSOT로 사용합니다. (컨텍스트 압축/리셋 후 동일 규칙 적용)
-- `AUTO_MANUAL_REQUIRED`는 자동화 경계 상태이며 실패 단정 신호가 아닙니다. `context --json-compact` 재확인 후 `approvalRequest.required` 기준으로 멈춤/보고를 판단합니다. (상세 디버깅 필드가 필요할 때만 `context --json`)
+- `AUTO_DELEGATED_HANDOFF`는 delegated run 일시정지 상태이며 실패가 아닙니다. 같은 승인 라벨을 다시 열지 말고 delegated 경로를 이어서 진행하거나 재개합니다.
+- `AUTO_MANUAL_REQUIRED`는 instruction-only 자동화 경계 상태이며 실패 단정 신호가 아닙니다. `context --json-compact` 재확인 후 `approvalRequest.required` 기준으로 멈춤/보고를 판단합니다. (상세 디버깅 필드가 필요할 때만 `context --json`)
 - 승인 대기 상태에서는 `context --json-compact`의 `approvalRequest.userFacingLines`를 우선 그대로 보여주세요. 전체 `--json`을 쓸 때만 `actionOptions[*].approvalPrompt`와 `approvalRequest.finalPrompt` 조합으로 폴백합니다. 이 사이에 에이전트가 임의로 다시 쓴 라벨 요약을 끼워 넣지 않습니다.
 - 위임 판단 SSOT는 `matchedFeature.currentSubstateOwner`와 `agentOrchestration.subAgentHandoff`를 우선 사용하세요.
 - 비승인 상태의 진행 보고/분석/일반 답변에서는 라벨 블록이나 `approvalRequest.finalPrompt`를 덧붙이지 않습니다. 현재 옵션을 사용자가 직접 물었을 때만 예외입니다.
@@ -81,6 +82,7 @@
 ## 범위 분리
 
 - docs 구조/경로 규칙: `docs/README.md`를 SSOT로 사용
+- `docs/plans/*`, `docs/superpowers/specs/*`, `docs/superpowers/plans/*` 같은 공용 계획 산출물은 staging/reference 입력으로만 취급합니다. Feature가 활성화되어 있으면 해당 내용을 Feature 문서로 흡수하고, 최종 SSOT는 Feature 폴더로 봅니다.
 - ADR 작성 형식: `docs/features/.../decisions.md` 템플릿을 SSOT로 사용
 - 이슈/PR 실행 상태: 각 Feature의 `issue.md`, `pr.md`를 SSOT로 사용
 

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

@@ -104,11 +104,7 @@ GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
 
 - 기본값: 본인 할당 (`--assignee @me`)
 - 다른 담당자 지정 시 **사용자에게 확인** 후 진행
-- 예시:
-  ```bash
-  gh issue create --assignee @me ...
-  gh issue create --assignee username ...
-  ```
+- 원격 생성은 반드시 `npx lee-spec-kit github issue <featureRef> --create --confirm OK --labels ...`를 사용합니다.
 
 ---
 

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

@@ -100,13 +100,7 @@ Closes #{이슈번호}
 ## PR 생성 명령어
 
 ```bash
-# 현재 브랜치명 확인
-BRANCH=$(git branch --show-current)
-
-gh pr create \
-  --title "feat(#{issue}): {기능명} ({짧은 설명})" \
-  --body-file /tmp/pr-body.md \
-  --base main
+npx lee-spec-kit github pr <featureRef> --create --confirm OK --labels enhancement
 ```
 
 ---
@@ -154,10 +148,7 @@ git pull
 
 - 기본값: 본인 할당 (`--assignee @me`)
 - 리뷰어 지정 시 `--reviewer` 옵션 사용
-- 예시:
-  ```bash
-  gh pr create --assignee @me --reviewer reviewer-username ...
-  ```
+- 원격 생성은 반드시 `npx lee-spec-kit github pr <featureRef> --create --confirm OK --labels ...`를 사용합니다.
 
 ---
 

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

@@ -50,6 +50,9 @@ CLI가 출력하는 **`👉 Next Options (Atomic)` 목록에서 단 하나의
 
 아직 기능 폴더가 없다면, 먼저 폴더를 생성하고 루프를 시작하세요:
 
+- 사용자의 요청에 `I001`, `I001-slug`, `docs/ideas/...` 같은 **명시적 Idea ref**가 있으면, 일반 생성 대신 해당 ref를 유지해서 `npx lee-spec-kit feature <name> --idea <ref>`를 사용합니다.
+- 이 경우 Idea를 추정하지 않습니다. 요청에 명시된 ref가 있을 때만 `--idea`를 붙입니다.
+
 ```bash
 # 1. 생성
 npx lee-spec-kit feature <name> -d "<설명>"

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

@@ -52,14 +52,10 @@ npx lee-spec-kit github issue F001 --json
 
 ### 3. 이슈 생성 (`issue.md`가 `Ready`일 때)
 
-```bash
-gh issue create \
-  --title "{기능명} ({짧은 설명})" \
-  --body-file /tmp/issue-body.md \
-  --assignee @me \
-  --label enhancement
+원격 이슈 생성은 반드시 lee-spec-kit helper로만 실행합니다.
+`gh issue create`를 직접 호출하거나 raw `issue.md`를 그대로 `--body-file`에 넘기지 마세요.
 
-# 또는 lee-spec-kit helper 사용 (명시적 승인 필요)
+```bash
 npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 ```
 
@@ -72,5 +68,6 @@ npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
 ## 참조 문서
 
 - **초안 생성기**: `npx lee-spec-kit github issue <feature-name>`
+- **원격 생성 규칙**: 반드시 `npx lee-spec-kit github issue <feature-name> --create --confirm OK --labels ...` 사용
 - **승인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/issue.md`

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

@@ -160,15 +160,10 @@ PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하
 
 ### 5. PR 생성 (`pr.md`가 `Ready`일 때)
 
+원격 PR 생성은 반드시 lee-spec-kit helper로만 실행합니다.
+`gh pr create`를 직접 호출하거나 raw `pr.md`를 그대로 `--body-file`에 넘기지 마세요.
+
 ```bash
-gh pr create \
-  --title "feat(#{이슈번호}): {기능명} ({짧은 설명})" \
-  --body-file /tmp/pr-body.md \
-  --label "{라벨1,라벨2}" \
-  --assignee @me \
-  --base main
-
-# 또는 lee-spec-kit helper 사용 (명시적 승인 필요)
 npx lee-spec-kit github pr F001 --create --confirm OK --labels enhancement
 ```
 
@@ -217,5 +212,6 @@ PR 본문의 파일 링크는 **현재 브랜치명**을 사용:
 ## 참조 문서
 
 - **본문 템플릿 생성기**: `npx lee-spec-kit github pr <feature-name>`
+- **원격 생성 규칙**: 반드시 `npx lee-spec-kit github pr <feature-name> --create --confirm OK --labels ...` 사용
 - **승인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/pr.md`

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

@@ -39,6 +39,7 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 - `autoRun.policyEligible=true`이지만 `autoRun.executableNow=false`이면 auto 루프를 시작하지 말고 `autoRun.manualBoundary`를 먼저 처리합니다.
 - 장시간 자동 실행이 필요하면 `flow <feature> --auto-... --start-auto --json-compact`으로 run id를 생성하고, 중단/압축 후에는 `autoRun.run.resumeCommand`(`flow --resume <RUN_ID>`)를 우선 사용해 재개합니다. (상세 디버깅 필드가 필요할 때만 `--json`)
 - auto 실행이 중단되면 `flow --json-compact`(또는 `flow --json`)의 `autoRun.resume`를 SSOT로 따릅니다. 컨텍스트 압축/리셋 후에는 `autoRun.resume.flowCommand`로 재개하고, 필요 시 `autoRun.resume.contextCommand`로 상태를 먼저 확인합니다.
+- `AUTO_DELEGATED_HANDOFF`는 실패가 아니라 delegated run 일시정지입니다. 새 승인 라벨을 다시 열기 전에 delegated 경로를 재사용해 작업을 이어갑니다.
 - `AUTO_MANUAL_REQUIRED`는 실패가 아니라 자동화 경계(현재 instruction-only 구간)입니다. 즉시 오류로 단정하지 말고 현재 `context --json-compact`를 다시 확인한 뒤 승인 필요 여부(`approvalRequest.required`)를 보고합니다.
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 - 사용자 응답 포맷은 `agents.md`의 **"라벨 응답 계약 (SSOT)"** 을 따릅니다. 라벨 문구는 승인 대기 상태에서만 보여주고, CLI가 준 승인 문구를 임의로 바꾸지 않습니다.
@@ -48,6 +49,9 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 
 ### 3단계: 기록 및 반복 (Record & Loop)
 
+- 새 태스크를 추가해야 한다면 `태스크 목록` 섹션의 마지막 기존 태스크 block 바로 아래에만 append 하세요.
+- 현재 작업 중인 태스크 근처, 같은 Phase 중간, `완료 조건`/다음 `##` 헤더 앞에 끼워 넣지 마세요.
+
 #### 3-1) Decision 기록 (매우 권장, 사실상 필수)
 
 에이전트가 “왜 이렇게 구현했지?” 라는 질문에 답할 수 있도록, **비직관적이거나 선택의 여지가 있었던 구현**이 들어갔다면 `decisions.md`에 반드시 기록합니다.

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

@@ -89,6 +89,25 @@ npx lee-spec-kit status --write
 
 ---
 
+## 공용 계획 산출물 (`superpowers` 등)
+
+외부 에이전트 워크플로우는 아래 같은 공용 설계/계획 문서를 만들 수 있습니다.
+
+- `docs/plans/*.md`
+- `docs/superpowers/specs/*.md`
+- `docs/superpowers/plans/*.md`
+
+Feature가 이미 진행 중이라면, 이 파일들은 활성 워크플로우 SSOT가 아니라 staging/reference 산출물로 취급합니다.
+
+- 사용자 요구/범위/Acceptance Criteria는 `spec.md`로 옮깁니다
+- 아키텍처/파일 구조/테스트 전략은 `plan.md`로 옮깁니다
+- 실제 실행할 작업 항목은 `tasks.md`로 옮깁니다
+- 대안 비교, 선택 이유, 트레이드오프는 `decisions.md`로 옮깁니다
+
+공용 산출물을 기록용으로 남겨두는 것은 괜찮지만, feature-local 문서와 충돌하면 Feature 폴더 문서를 기준으로 봅니다.
+
+---
+
 ## 상태 용어 정리
 
 | 구분 | 필드 | 값 |

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

@@ -1,6 +1,7 @@
 # Decisions Log
 
 기술 결정과 그 이유를 기록합니다.
+`docs/plans/*` 또는 `docs/superpowers/specs/*` 같은 공용 설계 문서가 있더라도, 실제로 채택한 대안과 선택 이유는 이 파일에 다시 남겨 Feature의 결정 이력을 유지합니다.
 
 > ADR(Architecture Decision Record)은 구현 중 내린 중요한 기술/구조 결정을 남기는 기록입니다.
 > 나중에 "왜 이렇게 만들었는지"를 추적하고, 팀 합의를 재확인하기 위해 작성합니다.

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

@@ -1,6 +1,7 @@
 # Implementation Plan: {기능명}
 
 > 스펙이 승인된 후 작성합니다.
+> `docs/plans/*` 또는 `docs/superpowers/plans/*` 같은 공용 계획 문서가 있더라도, 아키텍처/파일/테스트 내용은 이 파일로 흡수하고 최종 SSOT는 여기로 유지합니다.
 
 ---
 

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

@@ -66,6 +66,7 @@
 (권장) 요구사항/범위 변경 태스크:
 
 중간 변경은 **새 태스크로 추가**하고, 어떤 문서를 함께 업데이트해야 하는지 `Impact Docs`로 명시합니다.
+새 태스크를 추가할 때는 현재 태스크 근처나 Phase 중간에 끼워 넣지 말고, `태스크 목록`의 마지막 기존 태스크 block 아래에 append 하세요.
 
 ```markdown
 - [TODO][P1][PRD-FR-001][CHANGE] T-F{번호}-02 {태스크 제목} (요구사항/범위 변경)