lee-spec-kit 0.7.10 → 0.8.0

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

@@ -4,12 +4,12 @@
 
 - **Status**: `[TODO]` → `[DOING]` → `[DONE]`
 - **Task communication / confirmation**:
-  - `[TODO] → [DOING]`: share the task title first, then follow the latest `context --json-compact`
-  - `[DOING] → [DONE]`: share the result/verification first, then follow the latest `context --json-compact`
-  - If `approvalRequest.required=true`, wait for the exact CLI-provided label reply before changing task state.
-  - If `approvalRequest.required=false`, do not invent a separate `OK` approval step; update task state after real completion/verification.
+  - `[TODO] → [DOING]`: share the task title first, then update the task state in `tasks.md`
+  - `[DOING] → [DONE]`: share the result and verification first, then update `Acceptance` and `Checklist` in the same edit
+  - Ask for approval before changing task state only when the task crosses a documented review checkpoint or before remote/destructive actions.
+  - Do not invent a standalone `OK` approval step when the workflow does not require one.
   - `task-complete` rejects `[DONE]` while any item in that task's `Checklist` remains unchecked.
-- **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]`.
+- **PRD mapping (recommended)**: add an existing PRD requirement ID tag like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]` 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-...]`.
@@ -23,6 +23,9 @@
 - **Repo**: {{projectName}}-{component}
 - **Issue**: #{issue-number}
 - **Branch**: `feat/{issue-number}-{feature-name}`
+- **Pending Change Request**: -
+  - Temporary sync marker for a newly accepted user request during implementation
+  - Clear it after reflecting the request in `tasks.md` and related docs
 - **PR**: -
   - Example: `#123` or PR URL
 - **PR Status**: -
@@ -57,7 +60,7 @@
     - [ ] (subtask)
 ```
 
-> `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.
+> `PRD-FR-001` in the example is just one valid `PRD-*` key. If the key is not defined in the PRD source 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-...]`.
 
 ---
@@ -66,7 +69,7 @@
 
 > Add tasks below. **At least 1 task is required.**
 > Keep tasks as one ordered list. The list order itself is the execution priority.
-> To add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`. Add `--acceptance` and `--check` inline when you already know the concrete items.
+> To add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-*`. Use an existing PRD key such as `PRD-FR-001` or `PRD-SCOPE-V1-DESKTOP-EDITOR`. Add `--acceptance` and `--check` inline when you already know the concrete items.
 > Do not leave placeholder `Acceptance` / `Checklist` content in place. `task-run` will block execution until those items are concrete.
 > If you must edit manually, append it below the last existing task block in `Task List` instead of inserting it near the current task or right before `Completion Criteria`.
 
@@ -78,7 +81,7 @@
 
 - [ ] All tasks are `[DONE]`, and each task's `Acceptance` is verified and `Checklist` is checked
 - [ ] Tests executed and passing (record command/result below)
-- [ ] Final outcome shared and user confirmation recorded according to the current `context` approval state
+- [ ] Final outcome shared and any required user confirmation recorded at the documented workflow checkpoint
 
 ### Test Run Log (Latest by Command)
 

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

@@ -17,7 +17,7 @@ Typical flow: PRD defines the requirement, Idea explores or scopes the candidate
   - `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)
+  - PRD Refs (recommended): `PRD-FR-001, PRD-US-002` or `PRD-SCOPE-V1-DESKTOP-EDITOR` (use `NON-PRD` when not tied to PRD)
   - Target component (optional): `api` / `app` / `worker` / `all`
   - Status: `Active | Featureized | Dropped`
   - Feature: `F###-slug` when promoted
@@ -32,7 +32,7 @@ Typical flow: PRD defines the requirement, Idea explores or scopes the candidate
 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]`.
+- `tasks.md` still needs PRD mapping tags like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]`.
 4. Keep the idea doc for history and update it to `Status: Featureized`, `Feature: F00X-...`
 
 > Tip: keeping the source idea doc is usually better than deleting it for traceability (“why this feature exists”).

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

@@ -28,9 +28,9 @@ If work starts from a PRD item, keep the relationship visible through `PRD Refs`
 
 To let the CLI report “which PRD items are implemented”, assign **stable IDs** to PRD requirements.
 
-- Format: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003`
+- Use stable `PRD-*` keys. Numeric IDs like `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003` and semantic keys like `PRD-SCOPE-V1-DESKTOP-EDITOR` are all valid.
 - The ID only needs to appear on the same line (heading/bullet).
-- Reference it from a Feature `tasks.md` task line as a **bracket tag** like `[PRD-FR-001]`.
+- Reference it from a Feature `tasks.md` task line as a **bracket tag** like `[PRD-FR-001]` or `[PRD-SCOPE-V1-DESKTOP-EDITOR]`.
 - For non-PRD tasks, tag them as `[NON-PRD]`.
 - Important: do not invent PRD IDs in `tasks.md` or `spec.md`. Define them in this folder or the upstream requirements source first, then reference them.
 - For legacy PRD/requirements docs without IDs yet, backfill IDs in the source first, then align the Feature `PRD Refs` and task tags.

package/templates/ko/common/README.md

@@ -11,21 +11,23 @@ npx lee-spec-kit onboard --strict
 # 1) 프로젝트 감지
 npx lee-spec-kit detect --json
 
-# 2) 감지 성공 시 컨텍스트 조회
-npx lee-spec-kit context --json-compact
+# 2) 감지 성공 시 워크플로우 정책 조회
+npx lee-spec-kit docs get agents --json
 ```
 
 - `isLeeSpecKitProject: true`일 때만 lee-spec-kit 워크플로우를 적용합니다.
-- 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact`를 기준으로 판단합니다.
-- `approvalRequest.required=true`일 때만 `approvalPrompt`/`finalPrompt`를 그대로 사용자에게 보여주고 승인(`<LABEL>` 또는 `<LABEL> OK`)을 받은 뒤 실행합니다.
-- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 않습니다.
+- 기본 실행 경로는 workspace-scoped `AGENTS.md`, Codex 공식 hooks, 그리고 활성 feature 문서입니다.
+- 활성 feature를 정한 뒤에는 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`를 작업 SSOT로 사용합니다.
+- 사용자 승인 요청은 문서화된 workflow checkpoint와 원격/파괴적 작업 전에만 합니다.
+- staged된 docs 경로 검사가 필요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 코드나 feature 문서를 바꿨다면 종료 전 `npx lee-spec-kit workflow-audit --json`로 동기화 상태를 확인합니다.
 - `isLeeSpecKitProject: false`면 lee-spec-kit 전용 절차를 건너뛰고 일반 워크플로우로 진행합니다.
 
 ## 신규 프로젝트 시작 순서
 
 - 코드 프로젝트 스캐폴딩(예: Next.js/NestJS) 후 `lee-spec-kit init`을 실행하세요.
 - 그 다음 `docs/prd/`에 상위 요구사항을 정리하고, `idea`/`feature`로 작업 단위를 구체화하세요.
-- 이후 `detect --json`으로 감지 결과를 확인하고, `context` 순서로 진행하세요.
+- 이후 `detect --json`으로 감지 결과를 확인하고, `docs get agents --json`과 활성 feature 문서 기준으로 진행하세요.
 - 대부분의 경우(기본값: embedded) 위 순서만 따르면 됩니다.
 - docs를 코드 저장소와 분리해 운영할 때만 standalone을 선택하세요. 이때는 상위 워크스페이스 폴더(예: `workspace/docs`, `workspace/project`)에서 `init`을 실행해 docs/project 경로를 함께 지정하는 방식을 권장합니다. (예: `npx lee-spec-kit init --docs-repo standalone --dir ./docs --project-root ./project`)
 
@@ -53,17 +55,17 @@ npx lee-spec-kit context --json-compact
 
 - **PRD (`docs/prd/`)**: 요구사항 SSOT
   - 이 공간은 `init`이 만들어 주며, 별도 생성 명령 없이 여기에서 직접 PRD를 관리합니다.
-  - 요구사항마다 ID를 부여합니다: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003`
+  - 요구사항마다 안정적인 `PRD-*` ID를 부여합니다: `PRD-FR-001`, `PRD-US-002`, `PRD-NFR-003` 같은 numeric ID 또는 `PRD-SCOPE-V1-DESKTOP-EDITOR` 같은 semantic key
   - ID는 안정적으로 유지합니다. (삭제 대신 `Deprecated` 표기 권장, 재번호 부여 금지)
   - PRD ID는 PRD 원문에 먼저 정의합니다. Feature 문서에서 임의 생성하지 않습니다.
 - **Ideas (`docs/ideas/`)**: Feature 전 단계 SSOT (가설/실험/후보)
   - 가능하면 PRD에서 출발한 후보라는 점이 보이도록 `PRD Refs`를 유지합니다.
-  - Idea 문서 상단에 `PRD Refs:`를 기록합니다. (예: `PRD-FR-001, PRD-US-002`)
+  - Idea 문서 상단에 `PRD Refs:`를 기록합니다. (예: `PRD-FR-001, PRD-US-002` 또는 `PRD-SCOPE-V1-DESKTOP-EDITOR`)
   - Feature로 승격되면 SSOT는 `docs/features/`로 이동하고, Idea는 archive로 정리합니다.
 - **Features (`docs/features/`)**: 구현 범위/진행 SSOT
   - Feature는 PRD와 idea를 바탕으로 실제 구현을 진행하는 실행 단위입니다.
   - `spec.md`: 범위 정의 + `PRD Refs`(기능이 커버하는 PRD ID 목록)
-  - `tasks.md`: 태스크 단위로 PRD ID를 태그(`[PRD-FR-001]`)로 매핑하거나, PRD 무관 태스크는 `[NON-PRD]`로 표시
+  - `tasks.md`: 태스크 단위로 PRD ID를 태그(`[PRD-FR-001]`, `[PRD-SCOPE-V1-DESKTOP-EDITOR]`)로 매핑하거나, PRD 무관 태스크는 `[NON-PRD]`로 표시
     - `[NON-PRD]`는 refactor, rename, tooling, 테스트, cleanup 같은 내부 작업에만 사용합니다.
     - 태스크가 사용자 동작, acceptance criteria, 기능 범위를 바꾸게 되면 `[NON-PRD]`로 끝내지 말고 PRD를 backfill한 뒤 `[PRD-...]`로 연결합니다.
   - 레거시 문서에 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 Feature 문서를 연결합니다.
@@ -75,7 +77,7 @@ npx lee-spec-kit context --json-compact
 - **Unmanaged docs 엔트리**: canonical surface 밖의 모든 `docs/` 최상위 엔트리
   - 예: `docs/plans/`, `docs/superpowers/`, 또는 다른 스킬이 만든 폴더
   - 이 문서들은 활성 워크플로우 SSOT가 아니라 staging/reference 입력으로만 취급합니다
-  - Feature가 활성화된 상태에서는 `context`가 `docs_normalize` 단계를 먼저 요구할 수 있으며, 정규화 또는 allowlist 등록 전까지 구현 진행을 막을 수 있습니다
+  - commit 전에 정규화하거나 allowlist에 넣어야 하며, `commit-audit`는 staged된 비정규 docs 경로를 차단합니다
   - 아래처럼 feature-local 문서로 정규화하세요:
     - design/spec 산출물 → `spec.md`, `plan.md`, `decisions.md`
     - implementation plan 산출물 → `plan.md`, `tasks.md`
@@ -115,7 +117,9 @@ npx lee-spec-kit context --json-compact
 - `docsRepo` ("embedded" | "standalone"): Docs 관리 방식
 - `pushDocs` (boolean, optional): `docsRepo: "standalone"`일 때만 생성 (원격 push 여부)
 - `docsRemote` (string, optional): `pushDocs: true`일 때만 생성 (원격 레포 URL)
-- `approval` (object, optional): `context` 출력의 `[확인 필요]` / `requiresUserCheck` 정책 오버라이드
+- `approval` (object, optional): repo 정책/커스텀 validator용 승인 checkpoint 메타데이터
+  - 기본 Codex-native 경로는 여전히 문서화된 checkpoint와 원격/파괴적 작업을 우선 기준으로 승인 요청합니다.
+  - legacy runtime은 이 필드를 직접 소비했지만, 이제는 category 기반 checkpoint 메타데이터가 정말 필요할 때만 유지하세요.
   - 현재 기본값:
     - `mode: "category"`
     - `default: "skip"`

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

@@ -1,104 +1,51 @@
 # Agents Guide
 
 코드 어시스턴트/에이전트 운영 규칙입니다.
-이 문서는 **정책(강제 규칙)만** 다룹니다.
+이 문서는 커스텀 런타임이 아니라 워크플로우 정책만 정의합니다.
 
 ---
 
-## 🚨 사용자 승인 처리 규칙 (MUST)
+## 감지 게이트
 
-사용자 확인 필수 규칙입니다.
+- 항상 먼저 `npx lee-spec-kit detect --json`를 실행합니다.
+- `status === "ok"` 이고 `isLeeSpecKitProject === true`일 때만 lee-spec-kit 규칙을 적용합니다.
+- 감지 실패 또는 false면 lee-spec-kit 전용 규칙을 건너뛰고 일반 워크플로우로 진행합니다.
 
-> ⚠️ 액션 종류만 보고 승인 필요 여부를 판단하지 마세요. workflow 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact` 출력으로 결정합니다.
-> ✅ 승인 대기 상태에서는 응답 형식이 항상 `<라벨>` 또는 `<라벨> OK` 형식(예: `A`, `A OK`)입니다.
-> ℹ️ 기본 정책에서 주요 workflow 승인 경계는 `spec_approve`, `implementation_approve` 두 곳입니다. 프로젝트 config가 추가 경계를 둘 수 있습니다.
-> ℹ️ 일부 원격 helper 명령은 `--confirm OK` 같은 명시 확인을 별도로 요구합니다. 이 command-level confirm은 라벨 기반 workflow 승인과 별개입니다.
+## 기본 실행 경로
 
-현재 액션이 승인 대기 상태라면, 실행 전에 해당 내용을 공유하세요:
+- 기본 실행은 workspace-scoped `AGENTS.md`와 Codex 공식 hooks를 우선 사용합니다.
+- 사용자가 "규칙에 따라 다음 feature를 진행해라"처럼 일반적으로 말해도 이 워크플로우로 자동 해석합니다.
 
-| 현재 액션 예시 | 공유 내용 |
-| --- | --- |
-| spec / plan / tasks 검토 | 검토 대상 문서 또는 정확한 섹션 |
-| 태스크 완료 / 최종 체크리스트 | 결과와 검증 근거 |
-| 커밋 / push / merge | 커밋 메시지, 포함 파일, 브랜치 |
-| 이슈 생성 | `npx lee-spec-kit github issue <featureRef> --create` 전 |
-| PR 생성 | `npx lee-spec-kit github pr <featureRef> --create` 전 |
-| Assignee 변경 | 대상 사용자명 |
-
-확인 절차:
-1. 작업 내용을 먼저 공유
-2. 최신 `context --json-compact` 기준으로 승인 대기 여부(`approvalRequest.required`) 확인
-3. 승인 대기 상태면 CLI가 준 승인 문구 그대로 라벨 응답을 기다리고, 비승인 상태면 별도 승인 문구를 만들지 않음
-4. 승인 후 실행 (명령 실행은 기본적으로 `npx lee-spec-kit flow <featureRef> --approve <LABEL> --execute`를 사용)
-
-금지:
-- 사용자 응답 없이 임의 진행
-
----
-
-## 🧾 라벨 응답 계약 (SSOT)
-
-- 승인 대기 상태를 별도 상태로 취급합니다. 승인 대기란 `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_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`를 덧붙이지 않습니다. 현재 옵션을 사용자가 직접 물었을 때만 예외입니다.
-- 관련 없는 질문에 먼저 답한 뒤에도 승인이 여전히 필요하면, 답변 후 CLI가 준 승인 문구(`approvalRequest.userFacingLines`, 또는 전체 `--json`의 `actionOptions[*].approvalPrompt` + `approvalRequest.finalPrompt`)를 다시 제시합니다.
-- 사용자 입력에 유효 라벨이 없으면 실행하지 말고 라벨 선택을 다시 요청합니다.
-- 위임 대상이 아닌 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` 기준), 불일치 시 즉시 중단/보고합니다. 상세 로그 수집은 불일치 시에만 수행합니다.
-- 메인 에이전트 fallback은 서브 에이전트 실행이 불가능한 경우(예: 도구 미지원, spawn 실패, 명령 실행 전 서브 에이전트 실패)에만 허용합니다.
-- fallback을 사용할 때는 메인 실행 전에 fallback 사유를 사용자에게 한 줄로 먼저 알립니다.
-
-승인 대기 상태 출력은 CLI가 제공한 승인 문구를 그대로 재사용해야 합니다. CLI가 주지 않은 `현재 상태:` / `선택 가능:` 같은 래퍼 문구를 에이전트가 임의로 만들어 붙이지 마세요.
-
----
-
-## 📚 내장 문서 조회 규칙 (MUST)
+## 문서가 SSOT
 
-- `docs get`은 세션 시작(또는 context 압축/리셋 직후) 기준으로 1회 확인합니다.
-- 같은 세션에서 이미 읽은 동일 문서는 다시 읽지 않습니다.
-- 현재 액션의 `requiredDocs[*].command` 중 이번 세션에 아직 읽지 않은 문서만 추가 조회합니다.
-- 아래 경우에는 예외적으로 재조회할 수 있습니다:
-  - 사용자가 정책 새로고침을 요청한 경우
-  - `update` 실행 등으로 정책/설정이 변경된 경우
-  - 세션이 새로 시작되었거나 context 압축/리셋이 발생한 경우
+- 세션 시작 시점이나 context 리셋 직후 `npx lee-spec-kit docs get agents --json`를 1회 읽습니다.
+- 응답의 `requiredDocs[*].command` 중 아직 읽지 않은 문서를 모두 확인합니다.
+- 활성 feature를 정한 뒤에는 해당 feature 폴더를 작업 SSOT로 사용합니다.
+- 최소 기준 문서는 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`입니다.
+- GitHub 워크플로우가 얽히면 `issue.md`, `pr.md`도 함께 봅니다.
 
----
+## 실행 규칙
 
-## 필수 참조
+- lee-spec-kit은 문서 구조, workflow 단계, validator를 담당합니다.
+- Codex는 실행 루프, 도구 사용, hook lifecycle을 담당합니다.
+- 동작이나 범위가 바뀌는 코드 변경이 있으면 같은 턴 안에서 feature 문서를 같이 동기화합니다.
+- staged된 docs 경로 검사가 필요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 기본 docs sync 검사는 `npx lee-spec-kit workflow-audit --json`를 사용합니다.
 
-- 최우선 규칙: `/docs/agents/custom.md`
-- 프로젝트 원칙: `/docs/agents/constitution.md`
-- 루트 가이드: `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-doc --json`
-- PR 절차/문서: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-doc --json`
-
----
+## 승인 규칙
 
-## 범위 분리
+사용자 확인 필수 규칙을 항상 먼저 적용합니다.
 
-- docs 구조/경로 규칙: `docs/README.md`를 SSOT로 사용
-- canonical docs surface는 `docs/README.md`에 정의된 `docs/` 최상위 엔트리만을 의미합니다. allowlist에 없는 추가 `docs/*` 최상위 엔트리는 unmanaged docs로 취급합니다.
-- `docs/plans/*`, `docs/superpowers/*`, 또는 다른 스킬이 만든 docs 폴더 같은 unmanaged docs는 staging/reference 입력으로만 취급합니다. Feature가 활성화되어 있으면 해당 내용을 Feature 문서로 흡수하고, 최종 SSOT는 Feature 폴더로 봅니다.
-- `context`에 `docs_normalize` action/category가 나타나면, 구현이나 다른 workflow action보다 먼저 그 정규화 단계를 완료하세요.
-- ADR 작성 형식: `docs/features/.../decisions.md` 템플릿을 SSOT로 사용
-- 이슈/PR 실행 상태: 각 Feature의 `issue.md`, `pr.md`를 SSOT로 사용
+| 현재 액션 예시 | 공유 내용 |
+| --- | --- |
+| 이슈 생성 | `npx lee-spec-kit github issue <featureRef> --create` 전 |
+| PR 생성 | `npx lee-spec-kit github pr <featureRef> --create` 전 |
 
----
+- 문서화된 workflow checkpoint와 원격/파괴적 작업 전에만 사용자 승인을 요청합니다.
+- GitHub 원격 작업 전에는 올릴 artifact나 계획을 먼저 공유합니다.
 
-## 언어/표기 규칙
+## 표기 규칙
 
 - 답변: 한국어
 - 코드/파일명: 영어
-- 주석/커밋메시지: 한국어
-- 날짜/시간: 사용자 PC 시스템 시간 사용
+- 날짜/시간: 사용자 로컬 시스템 시간

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

@@ -1,62 +1,34 @@
-# 기능 구현 프로세스: CLI 주도형
+# 기능 구현 프로세스: Docs-first
 
-이 문서는 새 기능(Feature)을 추가할 때 따르는 **유일한 규칙**입니다.
-에이전트는 자신의 판단을 신뢰하지 않고, 오직 **CLI 도구의 지시**에 따라 행동합니다.
+이 가이드는 Codex-native lee-spec-kit 경로에서 feature를 시작하거나 이어갈 때 따르는 기준입니다.
 
 ---
 
-## 🔄 The Loop (무한 반복)
-
-Feature 구현이 완료될 때까지(문서 커밋까지) 다음 과정을 **계속 반복**하세요.
-
-### 1단계: 상태 확인
-
-작업을 시작하거나 한 단계를 마칠 때마다 **반드시** 아래 명령어를 실행합니다.
-
-```bash
-npx lee-spec-kit context
-```
-
-### 2단계: 지시 수행 (Next Options)
-
-CLI가 출력하는 **`👉 Next Options (Atomic)` 목록에서 단 하나의 옵션(A/B/C)을 선택**해 수행합니다.
-승인이 필요한 작업은 사용자에게 공유한 뒤 **`<라벨>` 또는 `<라벨> OK` 응답(예: `A`, `A OK`)**을 받은 옵션만 실행합니다.
-
-- **승인 대기(Review)** 상태라면 사용자에게 공유하고 멈춥니다.
-- CLI가 파일 작성을 지시하면 해당 파일을 작성합니다.
-- CLI가 이슈 생성을 지시하면 이슈를 생성합니다.
-- CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
-- 승인 요청 시 라벨 옵션은 `A: ...` 형식으로 **CLI가 출력한 원문(detail/cmd) 그대로** 공유합니다. 요약/의역하지 않습니다.
-- 승인된 command 옵션을 실행할 때는 세션 불일치 방지를 위해 `npx lee-spec-kit flow <slug|F001|F001-slug> --approve <LABEL> --execute`를 기본으로 사용합니다.
-
-### 3단계: 반복
-
-지시된 행동을 완료했다면, **즉시 1단계로 돌아가** 다시 `context`를 확인합니다.
-
----
-
-## 🛑 절대 금지 사항 (Strict Rules)
-
-1. **앞서가지 않기**: CLI가 "Spec 작성"을 지시했는데 "Plan 작성"까지 한 번에 하지 마세요.
-2. **건너뛰지 않기**: "이슈 생성" 단계를 귀찮아서 생략하거나 가짜 번호를 넣지 마세요.
-3. **스스로 판단 금지**: "이 정도면 됐겠지?"라고 생각하지 말고 CLI에게 물어보세요.
-
-> 참고: 워크플로우 단계는 변경될 수 있으므로, “단계 번호”를 외우지 마세요.
-> **항상 `context` 출력만**을 SSOT로 따르세요.
-
----
-
-## 시작하기
-
-아직 기능 폴더가 없다면, 먼저 폴더를 생성하고 루프를 시작하세요:
-
-- 사용자의 요청에 `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 "<설명>"
-
-# 2. 루프 진입
-npx lee-spec-kit context
-```
+## 시작
+
+1. `npx lee-spec-kit detect --json`를 실행합니다.
+2. 감지되면 `npx lee-spec-kit docs get agents --json`과 아직 읽지 않은 후속 문서를 확인합니다.
+3. 아직 feature 폴더가 없다면:
+   - 사용자가 실제로 `I001`, `I001-slug`, `docs/ideas/...` 같은 explicit Idea ref를 말한 경우에만 그 ref를 유지합니다
+   - 그럴 때만 `npx lee-spec-kit feature <name> --idea <ref>`를 사용합니다
+   - 그 외에는 `npx lee-spec-kit feature <name> -d "<설명>"`으로 생성합니다
+4. 활성 feature를 정하고 `spec.md`, `plan.md`, `tasks.md`, `decisions.md`를 읽습니다.
+
+## 작업 규칙
+
+- 문서가 SSOT입니다. 활성 feature 문서를 직접 따라갑니다.
+- 문서 단계는 직접 따라갑니다:
+  - `spec.md`는 범위와 리뷰 상태를 정의합니다
+  - `plan.md`는 구현 접근을 정의합니다
+  - `tasks.md`는 실제 실행 순서를 정의합니다
+  - `issue.md`, `pr.md`는 GitHub 단계에 도달했을 때만 사용합니다
+- 범위나 동작이 바뀌면 같은 턴 안에서 활성 feature 문서를 같이 업데이트합니다.
+- 사용자 승인은 문서화된 review checkpoint와 원격/파괴적 작업 전에만 요청합니다.
+- docs 경로 검사가 중요하면 `git commit` 전에 `npx lee-spec-kit commit-audit --json`를 사용합니다.
+- 코드나 feature 문서를 바꿨다면 종료 전에 `npx lee-spec-kit workflow-audit --json`로 동기화 상태를 확인합니다.
+
+## 절대 규칙
+
+1. 이슈/PR 번호나 상태를 임의로 만들지 않습니다.
+2. 범위, 동작, evidence가 바뀌었는데 필요한 문서 업데이트를 건너뛰지 않습니다.
+3. unmanaged docs 산출물은 feature 폴더로 정규화하거나 allowlist하기 전까지 active workflow SSOT로 취급하지 않습니다.

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

@@ -8,7 +8,7 @@ GitHub Issue를 생성할 때 따르는 가이드입니다.
 ## 사전 조건
 
 - [ ] `spec.md` 작성 완료
-- [ ] 최신 `context --json-compact` 확인
+- [ ] 활성 feature 문서 검토
 
 ---
 
@@ -38,9 +38,7 @@ npx lee-spec-kit github issue F001 --json
 | 라벨   | `enhancement`, `bug`, `documentation` 등 |
 | 담당자 | `@me` (기본값)                           |
 
-### 2. `Ready` 전환 (context가 요구할 때만 승인 요청)
-
-> ⚠️ **workflow 라벨 승인은 조건부입니다**
+### 2. `Ready` 전환
 
 `issue.md` 초안 기준으로 다음 내용을 공유하세요:
 
@@ -48,16 +46,13 @@ npx lee-spec-kit github issue F001 --json
 - 본문 전체 초안 (`issue.md` 기준)
 - 라벨
 
-그 다음 최신 `npx lee-spec-kit context --json-compact`를 다시 확인합니다.
-
-- `approvalRequest.required=true`이면 CLI가 준 승인 문구를 그대로 보여주고 라벨 응답(`A` 또는 `A OK`)을 기다린 뒤 계속 진행합니다.
-- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 말고, 초안을 다듬은 뒤 `issue.md` 상태를 `Ready`로 변경합니다.
+초안을 다듬은 뒤 `issue.md` 상태를 `Ready`로 변경합니다.
 
 ### 3. 이슈 생성 (`issue.md`가 `Ready`일 때)
 
 원격 이슈 생성은 반드시 lee-spec-kit helper로만 실행합니다.
 `gh issue create`를 직접 호출하거나 raw `issue.md`를 그대로 `--body-file`에 넘기지 마세요.
-workflow 라벨 승인과 별개로, 원격 생성 command 자체의 명시 확인은 계속 필요합니다.
+원격 생성 command 자체의 명시 확인은 항상 필요합니다.
 
 - 최종 제목/본문/라벨을 사용자에게 공유하고
 - 그 다음 `--confirm OK`를 붙여 helper를 실행하세요
@@ -76,6 +71,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 ...` 사용
-- **workflow 승인 규칙**: `approvalRequest.required=true`일 때만 라벨 승인을 기다립니다
+- **workflow 승인 규칙**: 원격 issue 생성 전에는 항상 사용자 승인을 받습니다
 - **원격 확인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/issue.md`

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

@@ -22,7 +22,7 @@ Pre-PR 리뷰에서 항상 수행하는 최소 기준입니다. 가능한 경우
 2. 회귀/예외 처리, 크리티컬·보안 리스크, 사이드 이펙트, 사용자 흐름 영향, 배포 준비도를 점검합니다.
 3. 유지보수성을 점검합니다: 큰 함수/파일은 필요 시 분리하고, 기존 코드 재사용·통합 가능성을 확인하며, 불필요해진 코드를 정리합니다.
 4. 현재 구현이 `spec.md` / `plan.md` / `tasks.md`에 기록된 feature 의도와 범위에 실제로 맞는지 평가합니다.
-5. `workflow.prePrReview.evidenceMode=path_required`(기본)일 때는 리뷰 에이전트를 먼저 실행해 `review-trace.json`을 만든 뒤 `npx lee-spec-kit pre-pr-review <feature-ref> --evidence review-trace.json`을 실행합니다. `evidenceMode=any`에서는 실행 증거 강제가 없는 한 `--evidence` 없이 직접 기록하는 경로도 허용됩니다.
+5. `workflow.prePrReview.evidenceMode=path_required`(기본)일 때는 승인 전에 `review-trace.json` 같은 실제 리뷰 산출물을 남깁니다. `evidenceMode=any`에서는 실행 증거 강제가 없는 한 별도 산출물 없이 직접 기록하는 경로도 허용됩니다.
 6. `PR 전 리뷰 Evidence`는 설정된 evidence 정책을 따라야 합니다. `path_required`일 때는 실제 존재하는 문서 경로를 사용합니다.
 7. `Summary`, `Feature Intent Summary`, `Implementation Fit`, `Missing Cases`, `Spec Alignment Checked`, `Finding Count`, `Blocking Findings`, `Findings`, `Residual Risks`를 placeholder 없이 기록합니다.
 8. 리뷰 중에 audit/타깃 검증 명령을 실제로 실행했다면 그때만 `commandsExecuted`에 기록합니다.
@@ -145,9 +145,7 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 - PR 본문에 Mermaid **`sequenceDiagram`**을 작성하고, 생성된 본문 템플릿 형식과 일치하게 유지합니다.
 - 이 기준은 프론트/백엔드 구분이 아니라 변경 유형(로직/구조) 기준으로 적용합니다.
 
-### 4. `Ready` 전환 (context가 요구할 때만 승인 요청)
-
-> ⚠️ **workflow 라벨 승인은 조건부입니다**
+### 4. `Ready` 전환
 
 PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하세요:
 
@@ -155,18 +153,13 @@ PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하
 - 본문 전체 템플릿 (`pr.md` 기준)
 - 라벨(최소 1개, 비워둘 수 없음)
 
-그 다음 최신 `npx lee-spec-kit context --json-compact`를 다시 확인합니다.
-
-- `approvalRequest.required=true`이면 CLI가 준 `<라벨>` 또는 `<라벨> OK` 응답을 기다립니다.
-- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 않습니다.
-
 이후 `pr.md`의 변경 사항/테스트 섹션을 실제 작업 기준으로 보완하고 `Ready`로 변경하세요.
 
 ### 5. PR 생성 (`pr.md`가 `Ready`일 때)
 
 원격 PR 생성은 반드시 lee-spec-kit helper로만 실행합니다.
 `gh pr create`를 직접 호출하거나 raw `pr.md`를 그대로 `--body-file`에 넘기지 마세요.
-workflow 라벨 승인과 별개로, 원격 생성 command 자체의 명시 확인은 계속 필요합니다.
+원격 생성 command 자체의 명시 확인은 항상 필요합니다.
 
 - 최종 제목/본문/라벨을 사용자에게 공유하고
 - 그 다음 `--confirm OK`를 붙여 helper를 실행하세요
@@ -221,6 +214,6 @@ PR 본문의 파일 링크는 **현재 브랜치명**을 사용:
 
 - **본문 템플릿 생성기**: `npx lee-spec-kit github pr <feature-name>`
 - **원격 생성 규칙**: 반드시 `npx lee-spec-kit github pr <feature-name> --create --confirm OK --labels ...` 사용
-- **workflow 승인 규칙**: `approvalRequest.required=true`일 때만 라벨 승인을 기다립니다
+- **workflow 승인 규칙**: 원격 PR 생성 또는 merge 전에 사용자 승인을 받습니다
 - **원격 확인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/pr.md`