lee-spec-kit 0.7.8 → 0.7.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.7.8",
+  "version": "0.7.9",
   "description": "Agent-guided development harness CLI for spec-driven projects",
   "type": "module",
   "bin": {

package/templates/en/common/README.md

@@ -16,7 +16,9 @@ npx lee-spec-kit context --json-compact
 ```
 
 - Apply lee-spec-kit workflow only when `isLeeSpecKitProject: true`.
-- When `actionOptions` exist, show `approvalPrompt`/`finalPrompt` exactly as provided and wait for user approval (`<LABEL>` or `<LABEL> OK`) before execution.
+- Determine approval waiting only from the latest `context --json-compact` / `flow --json-compact`.
+- When `approvalRequest.required=true`, show `approvalPrompt`/`finalPrompt` exactly as provided and wait for user approval (`<LABEL>` or `<LABEL> OK`) before execution.
+- When `approvalRequest.required=false`, do not invent a separate label approval prompt.
 - If `isLeeSpecKitProject: false`, skip lee-spec-kit-specific flow and continue with normal workflow.
 
 ## New Project Start Order
@@ -113,7 +115,13 @@ When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs ro
 - `docsRepo` ("embedded" | "standalone"): How docs are managed
 - `pushDocs` (boolean, optional): Only written when `docsRepo: "standalone"` (whether to push to remote)
 - `docsRemote` (string, optional): Only written when `pushDocs: true` (remote repo URL)
-- `approval` (object, optional): Override `[CHECK required]` / `requiresUserCheck` policy in `context` output (approval token: `A`, accepted: `A`/`A OK`)
+- `approval` (object, optional): Override `[CHECK required]` / `requiresUserCheck` policy in `context` output
+  - Current default:
+    - `mode: "category"`
+    - `default: "skip"`
+    - `requireCheckCategories: ["spec_approve", "implementation_approve"]`
+  - Approval token: `A`
+  - Accepted replies: `A`, `A OK`
 - `allowedDocsEntries` (object, optional): Allowlist non-standard top-level docs entries so they are not treated as unmanaged docs
   - `dirs` (string[]): extra allowed directories directly under `docs/`
   - `files` (string[]): extra allowed files directly under `docs/`
@@ -130,7 +138,11 @@ When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs ro
   "allowedDocsEntries": {
     "dirs": ["plans"]
   },
-  "approval": { "mode": "builtin" }
+  "approval": {
+    "mode": "category",
+    "default": "skip",
+    "requireCheckCategories": ["spec_approve", "implementation_approve"]
+  }
 }
 ```
 
@@ -143,6 +155,10 @@ When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs ro
   "docsRepo": "standalone",
   "pushDocs": true,
   "docsRemote": "git@github.com:org/{{projectName}}-docs.git",
-  "approval": { "mode": "builtin" }
+  "approval": {
+    "mode": "category",
+    "default": "skip",
+    "requireCheckCategories": ["spec_approve", "implementation_approve"]
+  }
 }
 ```

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

@@ -5,20 +5,22 @@ This document covers **policy only**.
 
 ---
 
-## 🚨 User Approval Required (MUST)
+## 🚨 User Approval Handling (MUST)
 
-> ⚠️ The actions below require explicit user approval when they are at an approval boundary.
+> ⚠️ Do not decide approval only from the action type. Workflow approval-waiting is determined by the latest `context --json-compact` / `flow --json-compact` output.
 > ✅ In approval-waiting state, replies must be in `<label>` or `<label> OK` format (e.g. `A`, `A OK`).
-
-| Action | When to confirm | What to share |
-| --- | --- | --- |
-| 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 `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 |
+> ℹ️ Under the default policy, the main workflow approval boundaries are `spec_approve` and `implementation_approve`. Project config may add more.
+> ℹ️ Some direct remote helper commands still require explicit command confirmation such as `--confirm OK`; that command-level confirm is separate from label-gated workflow approval.
+
+If the current action is approval-waiting, share the matching details before execution:
+
+| Current action (examples) | What to share |
+| --- | --- |
+| Spec / plan / tasks review | The document or the exact section being reviewed |
+| Task completion / final checklist | Outcome and verification evidence |
+| Commit / push / merge | Commit message, included files, branch |
+| Issue / PR creation | Title, body, labels |
+| Assignee change | Target username |
 
 Approval flow:
 1. Share details first

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

@@ -8,7 +8,7 @@ Execution-state SSOT is the feature-local `issue.md`.
 ## Prerequisites
 
 - [ ] `spec.md` completed
-- [ ] User approval received
+- [ ] Latest `context --json-compact` checked
 
 ---
 
@@ -38,22 +38,29 @@ Use `issue.md` status (`Draft | Ready`) as the actual workflow state.
 | Labels   | `enhancement`, `bug`, `documentation`, etc. |
 | Assignee | `@me` (default)                             |
 
-### 2. Request User Approval + Move to `Ready`
+### 2. Move to `Ready` (request approval only when context requires it)
 
-> 🚨 **User Approval Required**
+> ⚠️ **Workflow label approval is conditional**
 
-Share the `issue.md` draft and wait for label approval (`A` or `A OK`):
+Share the `issue.md` draft:
 
 - Title
 - Full body draft (from `issue.md`)
 - Labels
 
-After approval, set `issue.md` status to `Ready`.
+Then re-check the latest `npx lee-spec-kit context --json-compact`.
+
+- If `approvalRequest.required=true`, show the exact CLI-provided approval lines and wait for a label reply (`A` or `A OK`) before continuing.
+- If `approvalRequest.required=false`, do not invent a separate label prompt; refine the draft and set `issue.md` status to `Ready`.
 
 ### 3. Create Issue (when `issue.md` is `Ready`)
 
 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`.
+Command-level remote confirmation is still required even when workflow label approval is not:
+
+- share the final title/body/labels with the user
+- then run the helper with `--confirm OK`
 
 ```bash
 npx lee-spec-kit github issue F001 --create --confirm OK --labels enhancement
@@ -69,5 +76,6 @@ After creation:
 
 - **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`
+- **Workflow approval rule**: only wait for label approval when `approvalRequest.required=true`
+- **Remote confirm 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

@@ -145,23 +145,31 @@ 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.
 - Apply this rule based on change type (logic/structure), not by frontend/backend classification.
 
-### 4. Request User Approval + Move to `Ready`
+### 4. Move to `Ready` (request approval only when context requires it)
 
-> 🚨 **User Approval Required**
+> ⚠️ **Workflow label approval is conditional**
 
-Before creating the PR, share the following **in a code block** and, if approval is currently required, wait for the CLI-provided `<LABEL>` or `<LABEL> OK` reply:
+Before creating the PR, share the following **in a code block**:
 
 - Title
 - Full body template (from `pr.md`)
 - Labels (at least 1; cannot be empty)
 
-Before approval/create, refine `pr.md` Changes/Tests sections based on actual work.
-After approval, set `pr.md` status to `Ready`.
+Then re-check the latest `npx lee-spec-kit context --json-compact`.
+
+- If `approvalRequest.required=true`, wait for the exact CLI-provided `<LABEL>` or `<LABEL> OK` reply.
+- If `approvalRequest.required=false`, do not invent a separate label prompt.
+
+Before moving on, refine `pr.md` Changes/Tests sections based on actual work and 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`.
+Command-level remote confirmation is still required even when workflow label approval is not:
+
+- share the final title/body/labels with the user
+- then run the helper with `--confirm OK`
 
 ```bash
 npx lee-spec-kit github pr F001 --create --confirm OK --labels enhancement
@@ -213,5 +221,6 @@ Use **current branch name** for file links in PR body:
 
 - **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`
+- **Workflow approval rule**: only wait for label approval when `approvalRequest.required=true`
+- **Remote confirm 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

@@ -53,7 +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, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`.
+- If you need to add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001 --acceptance "..." --check "..."`.
+- Do not leave placeholder `Acceptance` / `Checklist` items in a newly added task. `task-run` will block until those fields contain concrete execution/verification items.
 - If manual editing is unavoidable, append the new task directly below the last existing task block in the `Task List` section.
 - Do not insert it near the current task or right before `Completion Criteria` / the next `##` heading.
 
@@ -87,10 +88,10 @@ Use the feature’s `decisions.md` template format as final SSOT. (Context/Const
 ### 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, mark the task `[DONE]` (and update any checklist items). If approval is required (`approvalRequest.required=true`), reuse the exact CLI-provided approval lines and wait for a `<LABEL>` or `<LABEL> OK` reply first. If approval is not required, do not invent a separate approval prompt before marking `[DONE]`.
+- After you share the outcome/verification, mark the task `[DONE]` and update the task-local checklist items in the same edit. `task-complete` will reject `[DONE]` if unchecked checklist boxes remain. If approval is required (`approvalRequest.required=true`), reuse the exact CLI-provided approval lines and wait for a `<LABEL>` or `<LABEL> OK` reply first. If approval is not required, do not invent a separate approval prompt before marking `[DONE]`.
 - 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 the latest CLI-provided label reply** before running the commands.
-- Once all tasks are `[DONE]`, share the "Completion Criteria" checklist with the user. If that point is approval-waiting, get a `<LABEL>` or `<LABEL> OK` reply before checking it; otherwise get a normal confirmation reply. (especially the **Final user approval received** item).
+- Once all tasks are `[DONE]`, share the "Completion Criteria" checklist with the user. If that point is approval-waiting, get a `<LABEL>` or `<LABEL> OK` reply before checking it; otherwise get a normal confirmation reply. (especially the final outcome/user confirmation item).
   - Note: both progress approval and final approval must follow the current `approvalRequest.required` state. When approval is label-gated, always use label replies instead of standalone `OK` as the approval token.
 
 ### Step 4: Repeat

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

@@ -3,9 +3,12 @@
 ## Task Rules
 
 - **Status**: `[TODO]` → `[DOING]` → `[DONE]`
-- **Approvals**:
-  - `[TODO] → [DOING]`: share task title first + user approval (OK)
-  - `[DOING] → [DONE]`: share result/verification first + user approval (OK)
+- **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.
+  - `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]`.
   - 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.
@@ -63,7 +66,8 @@
 
 > 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`.
+> To add a new task, prefer `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001 --acceptance "..." --check "..."`.
+> 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`.
 
 ---
@@ -74,7 +78,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 user approval (OK) received (review the outcome)
+- [ ] Final outcome shared and user confirmation recorded according to the current `context` approval state
 
 ### Test Run Log (Latest by Command)
 

package/templates/ko/common/README.md

@@ -16,7 +16,9 @@ npx lee-spec-kit context --json-compact
 ```
 
 - `isLeeSpecKitProject: true`일 때만 lee-spec-kit 워크플로우를 적용합니다.
-- `actionOptions`가 있으면 `approvalPrompt`/`finalPrompt`를 그대로 사용자에게 보여주고 승인(`<LABEL>` 또는 `<LABEL> OK`)을 받은 뒤 실행합니다.
+- 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact`를 기준으로 판단합니다.
+- `approvalRequest.required=true`일 때만 `approvalPrompt`/`finalPrompt`를 그대로 사용자에게 보여주고 승인(`<LABEL>` 또는 `<LABEL> OK`)을 받은 뒤 실행합니다.
+- `approvalRequest.required=false`이면 별도 라벨 승인 문구를 만들지 않습니다.
 - `isLeeSpecKitProject: false`면 lee-spec-kit 전용 절차를 건너뛰고 일반 워크플로우로 진행합니다.
 
 ## 신규 프로젝트 시작 순서
@@ -113,7 +115,13 @@ 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` 정책 오버라이드 (승인 토큰: `A`, 허용: `A`/`A OK`)
+- `approval` (object, optional): `context` 출력의 `[확인 필요]` / `requiresUserCheck` 정책 오버라이드
+  - 현재 기본값:
+    - `mode: "category"`
+    - `default: "skip"`
+    - `requireCheckCategories: ["spec_approve", "implementation_approve"]`
+  - 승인 토큰: `A`
+  - 허용 응답: `A`, `A OK`
 - `allowedDocsEntries` (object, optional): 비표준 `docs/` top-level 엔트리를 unmanaged docs로 보지 않도록 허용 목록에 추가
   - `dirs` (string[]): `docs/` 바로 아래에 추가 허용할 디렉터리
   - `files` (string[]): `docs/` 바로 아래에 추가 허용할 파일
@@ -130,7 +138,11 @@ npx lee-spec-kit context --json-compact
   "allowedDocsEntries": {
     "dirs": ["plans"]
   },
-  "approval": { "mode": "builtin" }
+  "approval": {
+    "mode": "category",
+    "default": "skip",
+    "requireCheckCategories": ["spec_approve", "implementation_approve"]
+  }
 }
 ```
 
@@ -143,6 +155,10 @@ npx lee-spec-kit context --json-compact
   "docsRepo": "standalone",
   "pushDocs": true,
   "docsRemote": "git@github.com:org/{{projectName}}-docs.git",
-  "approval": { "mode": "builtin" }
+  "approval": {
+    "mode": "category",
+    "default": "skip",
+    "requireCheckCategories": ["spec_approve", "implementation_approve"]
+  }
 }
 ```

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

@@ -5,20 +5,22 @@
 
 ---
 
-## 🚨 사용자 확인 필수 규칙 (MUST)
+## 🚨 사용자 승인 처리 규칙 (MUST)
 
-> ⚠️ 아래 작업은 사용자 승인 경계에 해당하면 반드시 명시 승인 후에만 진행합니다.
+> ⚠️ 액션 종류만 보고 승인 필요 여부를 판단하지 마세요. workflow 승인 대기 여부는 항상 최신 `context --json-compact` / `flow --json-compact` 출력으로 결정합니다.
 > ✅ 승인 대기 상태에서는 응답 형식이 항상 `<라벨>` 또는 `<라벨> OK` 형식(예: `A`, `A OK`)입니다.
-
-| 작업 | 확인 시점 | 공유 내용 |
-| --- | --- | --- |
-| 스펙 작성 | `spec.md` 작성 후 | 스펙 내용 전문 |
-| 태스크 실행 | 각 태스크 시작 전 | 태스크 제목 |
-| 커밋 생성 | `git commit` 전 | 커밋 메시지, 포함 파일 목록 |
-| 이슈 생성 | `npx lee-spec-kit github issue <featureRef> --create` 전 | 제목, 본문, 라벨 |
-| PR 생성 | `npx lee-spec-kit github pr <featureRef> --create` 전 | 제목, 본문, 라벨 |
-| Assignee 변경 | 본인 외 지정 시 | 대상 사용자명 |
-| Git 원격 작업 | `push`, `merge` 전 (머지 커밋 포함) | 브랜치, 변경 사항 |
+> ℹ️ 기본 정책에서 주요 workflow 승인 경계는 `spec_approve`, `implementation_approve` 두 곳입니다. 프로젝트 config가 추가 경계를 둘 수 있습니다.
+> ℹ️ 일부 원격 helper 명령은 `--confirm OK` 같은 명시 확인을 별도로 요구합니다. 이 command-level confirm은 라벨 기반 workflow 승인과 별개입니다.
+
+현재 액션이 승인 대기 상태라면, 실행 전에 해당 내용을 공유하세요:
+
+| 현재 액션 예시 | 공유 내용 |
+| --- | --- |
+| spec / plan / tasks 검토 | 검토 대상 문서 또는 정확한 섹션 |
+| 태스크 완료 / 최종 체크리스트 | 결과와 검증 근거 |
+| 커밋 / push / merge | 커밋 메시지, 포함 파일, 브랜치 |
+| 이슈 / PR 생성 | 제목, 본문, 라벨 |
+| Assignee 변경 | 대상 사용자명 |
 
 확인 절차:
 1. 작업 내용을 먼저 공유

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

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

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

@@ -145,23 +145,31 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 - PR 본문에 Mermaid **`sequenceDiagram`**을 작성하고, 생성된 본문 템플릿 형식과 일치하게 유지합니다.
 - 이 기준은 프론트/백엔드 구분이 아니라 변경 유형(로직/구조) 기준으로 적용합니다.
 
-### 4. 사용자 확인 요청 + `Ready` 전환
+### 4. `Ready` 전환 (context가 요구할 때만 승인 요청)
 
-> 🚨 **사용자 확인 필수**
+> ⚠️ **workflow 라벨 승인은 조건부입니다**
 
-PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하고, 승인 대기 상태면 CLI가 준 `<라벨>` 또는 `<라벨> OK` 응답을 기다리세요:
+PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하세요:
 
 - 제목
 - 본문 전체 템플릿 (`pr.md` 기준)
 - 라벨(최소 1개, 비워둘 수 없음)
 
-승인/생성 전에 `pr.md`의 변경 사항/테스트 섹션을 실제 작업 기준으로 보완하세요.
-승인 후 `pr.md` 상태를 `Ready`로 변경하세요.
+그 다음 최신 `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 자체의 명시 확인은 계속 필요합니다.
+
+- 최종 제목/본문/라벨을 사용자에게 공유하고
+- 그 다음 `--confirm OK`를 붙여 helper를 실행하세요
 
 ```bash
 npx lee-spec-kit github pr F001 --create --confirm OK --labels enhancement
@@ -213,5 +221,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` 실행
+- **workflow 승인 규칙**: `approvalRequest.required=true`일 때만 라벨 승인을 기다립니다
+- **원격 확인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행
 - **실행 상태 SSOT**: `docs/features/.../<feature>/pr.md`

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

@@ -49,7 +49,8 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 
 ### 3단계: 기록 및 반복 (Record & Loop)
 
-- 새 태스크를 추가해야 한다면 우선 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`를 사용하세요.
+- 새 태스크를 추가해야 한다면 우선 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001 --acceptance "..." --check "..."`를 사용하세요.
+- 새로 추가한 태스크에 placeholder `Acceptance` / `Checklist`를 남기지 마세요. concrete item이 아니면 `task-run`이 실행을 막습니다.
 - 수동 편집이 꼭 필요할 때만 `태스크 목록` 섹션의 마지막 기존 태스크 block 바로 아래에 append 하세요.
 - 현재 작업 중인 태스크 근처나 `완료 조건`/다음 `##` 헤더 앞에 끼워 넣지 마세요.
 
@@ -82,12 +83,12 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 
 #### 3-2) 태스크/체크리스트 업데이트 + 커밋
 
-1. 작업이 끝나면 결과/검증을 공유합니다. 승인 대기(`approvalRequest.required=true`) 상태라면 CLI가 준 승인 문구를 그대로 제시하고 사용자의 `<라벨>` 또는 `<라벨> OK` 응답을 받은 뒤 `[DONE]`으로 변경합니다. 비승인 상태면 별도 승인 문구 없이 `[DONE]`과 `Acceptance/Checklist`를 갱신합니다.
+1. 작업이 끝나면 결과/검증을 공유합니다. `[DONE]`으로 바꿀 때는 같은 수정에서 task-local `Checklist`도 함께 갱신해야 하며, unchecked box가 남아 있으면 `task-complete`가 `[DONE]` 전환을 거부합니다. 승인 대기(`approvalRequest.required=true`) 상태라면 CLI가 준 승인 문구를 그대로 제시하고 사용자의 `<라벨>` 또는 `<라벨> OK` 응답을 받은 뒤 `[DONE]`으로 변경합니다. 비승인 상태면 별도 승인 문구 없이 `[DONE]`과 `Acceptance/Checklist`를 갱신합니다.
 2. **한 번에 하나의 태스크만** `[DONE]` 처리합니다. (태스크 2개 이상을 한 번에 완료/커밋으로 묶지 않기)
 3. `tasks.md`의 테스트 실행 기록은 명령어별 1개 행만 유지하고, 같은 명령어 재실행 시 날짜/결과를 갱신합니다. (중복 누적 금지, 날짜 형식: 로컬 `YYYY-MM-DD`)
 4. 커밋을 생성합니다 (코드 커밋 + 문서 커밋). 태스크 단위로 커밋이 남아야 합니다.
    - `context`에 `[확인 필요]`가 보이면, **커밋/푸시 같은 원격 작업은 사용자에게 커밋 메시지/포함 파일을 공유한 뒤 최신 CLI 승인 문구의 라벨 응답을 받은 후** 실행합니다.
-5. 모든 태스크가 `[DONE]`가 되면, "완료 조건" 체크리스트를 사용자에게 공유합니다. 이 시점이 승인 대기 상태면 `<라벨>` 또는 `<라벨> OK` 응답을 받은 뒤 체크하고, 비승인 상태면 일반 확인 응답을 받은 뒤 체크합니다. (특히 **최종 사용자 승인 완료** 항목)
+5. 모든 태스크가 `[DONE]`가 되면, "완료 조건" 체크리스트를 사용자에게 공유합니다. 이 시점이 승인 대기 상태면 `<라벨>` 또는 `<라벨> OK` 응답을 받은 뒤 체크하고, 비승인 상태면 일반 확인 응답을 받은 뒤 체크합니다. (특히 최종 결과/사용자 확인 항목)
    - 참고: 진행 승인/최종 승인은 모두 현재 `approvalRequest.required` 상태를 기준으로 판단합니다. 라벨 승인 상태면 항상 라벨 응답을 사용하고, 비승인 상태면 standalone `OK`를 승인 토큰처럼 강제하지 않습니다.
 6. **즉시 1단계로 돌아가** 다음 할 일을 CLI에게 물어봅니다.
 

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

@@ -3,9 +3,12 @@
 ## 태스크 규칙
 
 - **상태**: `[TODO]` → `[DOING]` → `[DONE]`
-- **승인**:
-  - `[TODO] → [DOING]`: 시작 전 태스크 제목 공유 + 사용자 승인(OK)
-  - `[DOING] → [DONE]`: 완료 전 결과/검증 공유 + 사용자 승인(OK)
+- **태스크 공유 / 확인**:
+  - `[TODO] → [DOING]`: 시작 전 태스크 제목을 공유하고 최신 `context --json-compact` 기준을 따릅니다
+  - `[DOING] → [DONE]`: 완료 전 결과/검증을 공유하고 최신 `context --json-compact` 기준을 따릅니다
+  - `approvalRequest.required=true`이면 CLI가 제공한 라벨 응답을 받은 뒤에만 태스크 상태를 변경합니다.
+  - `approvalRequest.required=false`이면 별도 `OK` 승인 단계를 만들지 말고, 실제 완료/검증 후 상태를 갱신합니다.
+  - 해당 태스크의 `Checklist`에 unchecked 항목이 남아 있으면 `task-complete`는 `[DONE]` 전환을 거부합니다.
 - **PRD 매핑(권장)**: 각 태스크 라인에 `[PRD-FR-001]` 같은 PRD 요구사항 ID 태그를 추가하거나, PRD와 무관한 태스크는 `[NON-PRD]`로 표시하세요.
   - 단, `tasks.md`에서 PRD ID를 임의로 만들지 마세요. `docs/prd` 또는 상위 요구사항 문서에 먼저 정의된 ID만 참조해야 합니다.
   - 레거시 문서에 아직 PRD ID가 없다면, 먼저 원문 요구사항 문서에 ID를 backfill한 뒤 `spec.md`의 `PRD Refs`와 태스크 태그를 함께 맞추세요.
@@ -63,7 +66,8 @@
 
 > 아래에 태스크를 추가하세요. **최소 1개가 필요**합니다.
 > 태스크는 하나의 순차 리스트로 유지하고, 위에서 아래 순서 자체를 실행 우선순위로 취급하세요.
-> 새 태스크는 가급적 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001`로 추가하세요.
+> 새 태스크는 가급적 `npx lee-spec-kit task add <feature-ref> --title "..." --ref NON-PRD|PRD-FR-001 --acceptance "..." --check "..."`로 추가하세요.
+> placeholder 상태의 `Acceptance` / `Checklist`를 그대로 두지 마세요. concrete item이 아니면 `task-run`이 실행을 막습니다.
 > 수동 편집이 필요하면 현재 태스크 근처가 아니라 `태스크 목록`의 마지막 기존 태스크 block 아래에만 append 하세요.
 
 ---
@@ -74,7 +78,7 @@
 
 - [ ] 모든 태스크가 `[DONE]`이며, 각 태스크의 `Acceptance` 검증 및 `Checklist` 체크 완료
 - [ ] 테스트 실행 및 통과 (아래에 명령어/결과 기록)
-- [ ] 최종 사용자 승인(OK) 완료 (결과물 확인)
+- [ ] 최종 결과를 공유했고, 현재 `context` 승인 상태에 맞는 사용자 확인을 기록함
 
 ### 테스트 실행 기록