lee-spec-kit 0.6.7 → 0.6.9

package/package.json

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

package/templates/en/{single → common}/README.md

@@ -4,13 +4,13 @@ This documentation is organized by feature to help agents quickly understand the
 
 ## Directory Structure
 
-| Path             | Purpose               | Key Documents                                                 |
-| ---------------- | --------------------- | ------------------------------------------------------------- |
-| `docs/agents/`   | Agent operating rules | `custom.md`, `constitution.md` (engine-managed guides are fetched via `npx lee-spec-kit docs get <doc-id> --json`) |
-| `docs/prd/`      | Product requirements  | Project-specific                                              |
-| `docs/designs/`  | Design references     | `README.md` (links/guidelines/references)                     |
-| `docs/ideas/`    | Ideas / to-dos         | `README.md` (Idea → Feature promotion rules)                  |
-| `docs/features/` | Feature documentation | `{feature-id}/spec.md`, `plan.md`, `tasks.md`, `decisions.md` |
+| Path              | Purpose               | Key Documents |
+| ----------------- | --------------------- | ------------- |
+| `docs/agents/`    | Agent operating rules | `custom.md`, `constitution.md` (engine-managed guides are fetched via `npx lee-spec-kit docs get <doc-id> --json`) |
+| `docs/prd/`       | Product requirements  | Project-specific |
+| `docs/designs/`   | Design references     | `README.md` (links/guidelines/references) |
+| `docs/ideas/`     | Ideas / to-dos        | `README.md` (Idea → Feature promotion rules) |
+| `{{featurePath}}` | Feature documentation | `{feature-id}/spec.md`, `plan.md`, `tasks.md`, `decisions.md` |
 
 ---
 
@@ -24,7 +24,7 @@ When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs ro
 ### Fields
 
 - `projectName` (string): Project name
-- `projectType` ("single" | "fullstack"): Project type
+- `projectType` ("single" | "multi"): Project type
 - `lang` ("ko" | "en"): Docs language
 - `createdAt` (string, YYYY-MM-DD): Creation date
 - `docsRepo` ("embedded" | "standalone"): How docs are managed
@@ -37,7 +37,7 @@ When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs ro
 ```json
 {
   "projectName": "{{projectName}}",
-  "projectType": "single",
+  "projectType": "{{projectType}}",
   "lang": "en",
   "createdAt": "{{date}}",
   "docsRepo": "embedded",
@@ -48,7 +48,7 @@ When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs ro
 ```json
 {
   "projectName": "{{projectName}}",
-  "projectType": "single",
+  "projectType": "{{projectType}}",
   "lang": "en",
   "createdAt": "{{date}}",
   "docsRepo": "standalone",

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

@@ -0,0 +1,77 @@
+# Agents Guide
+
+Operating rules for AI code assistants.
+This document covers **policy only**.
+
+---
+
+## 🚨 User Approval Required (MUST)
+
+> ⚠️ The actions below require explicit user approval (OK) before execution.
+> ✅ Approval 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 `gh issue create` | Title, body, labels |
+| PR creation | Before `gh pr create` | Title, body, labels |
+| Assignee change | When assigning someone else | Target username |
+| Remote Git operations | Before `push`, `merge` (including merge commits) | Branch, changes |
+
+Approval flow:
+1. Share details first
+2. Wait for explicit approval (OK)
+3. Execute after approval
+
+Prohibited:
+- Proceeding without user response
+
+---
+
+## 🧾 Label Response Contract (SSOT)
+
+- End **every user-facing reply** with current status + available labels.
+- Use the latest `npx lee-spec-kit context --json` (or `flow --json`) as source.
+- Use `actionOptions[].detail` or command `cmd` **verbatim**. Do not paraphrase.
+- Even when the user asks something else, append the same label block at the end if executable labels exist.
+- If no executable labels exist, print `Available labels: none` and guide re-check with `npx lee-spec-kit context`.
+- If user input does not contain a valid label, do not execute; request label selection again.
+
+Output format:
+
+```text
+Current status: <reasonCode or brief state>
+Available labels:
+A: <detail>
+B: <detail>
+Reply format: "<LABEL>" or "<LABEL> OK"
+```
+
+---
+
+## Required References
+
+- Highest-priority custom rules: `/docs/agents/custom.md`
+- Project principles: `/docs/agents/constitution.md`
+- Root guide: `npx lee-spec-kit docs get agents --json`
+- Git workflow: `npx lee-spec-kit docs get git-workflow --json`
+- Task execution: `npx lee-spec-kit docs get execute-task --json`
+- Issue procedure/template: `npx lee-spec-kit docs get create-issue --json` → `npx lee-spec-kit docs get issue-template --json`
+- PR procedure/template: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-template --json`
+
+---
+
+## Scope Split
+
+- Docs structure/path rules: use `docs/README.md` as SSOT
+- ADR format: use feature `decisions.md` template as SSOT
+
+---
+
+## Language / Formatting Rules
+
+- Replies: English (or project language policy in `custom.md`)
+- Code/file names: English
+- Date/time: use user's local system time

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

@@ -58,8 +58,8 @@ In GitHub Issues, use different link formats **based on file location**:
    > Format: `- **{Label}**: \`{path}\``
 
    ```markdown
-   - **Spec**: `docs/features/{be|fe}/F001-feature-name/spec.md`
-   - **Tasks**: `docs/features/{be|fe}/F001-feature-name/tasks.md`
+   - **Spec**: `docs/features/{component}/F001-feature-name/spec.md`
+   - **Tasks**: `docs/features/{component}/F001-feature-name/tasks.md`
    ```
 
 > ⚠️ Local documents are not clickable on GitHub, so use **bold label + code block path** format instead of markdown links.
@@ -85,7 +85,7 @@ In GitHub Issues, use different link formats **based on file location**:
 
 ## Related Documents
 
-- **Spec**: `docs/features/{be|fe}/F{number}-{feature-name}/spec.md`
+- **Spec**: `docs/features/{component}/F{number}-{feature-name}/spec.md`
 
 ## Labels
 

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

@@ -25,6 +25,7 @@ For gated actions, proceed only after the user replies in **`<label>` or `<label
 - If the CLI indicates **Review**, share the document with the user and stop.
 - If the CLI asks for writing a file, write that file and follow the format.
 - If the CLI prints a command, **copy/paste and run it exactly**. (It may include repo-safe `git -C ...` commands and scopes like `project` vs `docs`.)
+- When requesting approval, present labels as `A: ...` using the exact CLI detail/cmd text. Do not paraphrase command options.
 
 ### Step 3: Repeat
 

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

@@ -15,16 +15,16 @@ Guide for creating Pull Requests.
 
 ## Steps
 
-### 1. Prepare PR Draft
+### 1. Prepare PR Body Template
 
-> 📖 **Read procedure/template via `docs get` first, then generate a draft and treat it as the source of truth.**
+> 📖 **Read procedure/template via `docs get` first, then generate a body template and treat it as the source of truth.**
 
 ```bash
 # 1) Read procedure + template policy
 npx lee-spec-kit docs get create-pr --json
 npx lee-spec-kit docs get pr-template --json
 
-# 2) Generate draft body (no remote action)
+# 2) Generate body template (no remote action)
 npx lee-spec-kit github pr F001 --json
 # - Force screenshots section: --screenshots on
 # - Force Mermaid section: --mermaid on
@@ -32,7 +32,7 @@ npx lee-spec-kit github pr F001 --json
 ```
 
 Use `docs get pr-template --json` output as the section policy,
-and `github pr --json` output `body` as the first PR draft body.
+and `github pr --json` output `body` as the first PR body template.
 If needed, use `bodyFile` as the filesystem source.
 
 | Item     | Format                             |
@@ -50,7 +50,7 @@ If needed, use `bodyFile` as the filesystem source.
 
 1. Run relevant test commands (e.g., `npm test`, `pnpm test`); if no tests exist, request them from the user
 2. Check results (PASS/FAIL)
-3. In the PR body "Tests" section, keep only what you actually ran in the generated draft body
+3. In the PR body "Tests" section, keep only what you actually ran in the generated body template
 4. If you didn’t run any tests, request/confirm with the user before creating the PR
 
 ### 3. Prepare Screenshots / Diagrams (Include in PR Body)
@@ -122,7 +122,7 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 
 #### Logic/structure changes (Backend PR)
 
-- Write a Mermaid **`sequenceDiagram`** in the PR body and keep it aligned with the generated draft format.
+- Write a Mermaid **`sequenceDiagram`** in the PR body and keep it aligned with the generated body template format.
 
 ### 4. Request User Approval
 
@@ -131,10 +131,10 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 Before creating PR, share the following **in a code block** and wait for **explicit approval (OK)**:
 
 - Title
-- Full body draft (from `body`)
+- Full body template (from `body`)
 - Labels (at least 1; cannot be empty)
 
-Before approval/create, refine the generated draft's Changes/Tests sections based on actual work.
+Before approval/create, refine the generated body template's Changes/Tests sections based on actual work.
 
 ### 5. Create PR
 
@@ -189,5 +189,5 @@ Use **current branch name** for file links in PR body:
 
 ## Reference Documents
 
-- **Draft generator**: `npx lee-spec-kit github pr <feature-name>`
+- **Body template generator**: `npx lee-spec-kit github pr <feature-name>`
 - **Approval rule**: share title/body/labels first, then run `--create --confirm OK`

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

@@ -22,6 +22,7 @@ Execute exactly one option from `👉 Next Options (Atomic)` as printed by the C
 - If the CLI points to an active task, focus on that task only.
 - Treat the task state/approval rules in `tasks.md` **"Task Rules"** as SSOT (e.g. when OK is required for `[TODO]→[DOING]`, `[DOING]→[DONE]`).
 - If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
+- Follow user-facing response format (including the final status/label block in every reply) from `agents.md` **"Label Response Contract (SSOT)"**.
 
 ### Step 3: Update tasks.md (only what you did)
 

package/templates/en/{fullstack → common}/features/README.md

@@ -1,13 +1,12 @@
 # Features Guide
 
 Folder for managing feature specs, plans, and tasks.
-**FE/BE repos are separated, so Features are also managed separately.**
 
 ---
 
 ## Folder Structure
 
-```
+```text
 features/
 ├── README.md           # This file
 ├── feature-base/       # Shared template (edit in one place)
@@ -15,24 +14,20 @@ features/
 │   ├── plan.md
 │   ├── tasks.md
 │   └── decisions.md
-├── be/                 # Backend Features
-│   └── F00X-{name}/
-└── fe/                 # Frontend Features
-    └── F00X-{name}/
+├── (single) F00X-{name}/
+└── (multi)  {component}/F00X-{name}/
 ```
 
 ---
 
 ## Creating New Features
 
-### Using CLI (Recommended)
-
 ```bash
-# Backend Feature
-npx lee-spec-kit feature --repo be user-auth
+# Single project
+npx lee-spec-kit feature user-auth
 
-# Frontend Feature
-npx lee-spec-kit feature --repo fe user-profile
+# Multi project
+npx lee-spec-kit feature --component app user-profile
 ```
 
 > 💡 CLI copies templates from `feature-base/` and auto-assigns IDs.
@@ -45,15 +40,12 @@ npx lee-spec-kit feature --repo fe user-profile
 - Minimum **3-digit padding** for numbers (001, 002, ...)
 - Expands to **4+ digits** beyond 999 (F1000, F1001, ...)
 - Feature names in kebab-case
-- **IDs are globally unique** across BE/FE (no duplicates)
-- **Feature = Issue**: Each Feature corresponds to one GitHub Issue
+- **Feature = Issue**: Each Feature corresponds to one GitHub Issue.
 
 ---
 
 ## Status Check
 
-Check feature progress with CLI:
-
 ```bash
 npx lee-spec-kit status
 ```

package/templates/en/{fullstack → common}/features/feature-base/decisions.md

@@ -2,6 +2,9 @@
 
 Record technical decisions and their rationale.
 
+> 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.
+
 > Format: `D{number}: {Decision Title} ({YYYY-MM-DD})`
 
 ---

package/templates/en/{fullstack → common}/features/feature-base/plan.md

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

package/templates/en/{fullstack → common}/features/feature-base/spec.md

@@ -8,7 +8,7 @@
 
 - **Feature ID**: F{number}
 - **Feature Name**: {feature-name}
-- **Target Repo**: {{projectName}}-{be|fe}
+- **Target Repo**: {{projectName}}-{component}
 - **Issue Number**: #{issue-number}
 - **Created**: {YYYY-MM-DD}
 - **Status**: Review | Approved

package/templates/en/{fullstack → common}/features/feature-base/tasks.md

@@ -13,7 +13,7 @@
 ## GitHub Issue
 
 - **Doc Status**: Review | Approved
-- **Repo**: {{projectName}}-{be|fe}
+- **Repo**: {{projectName}}-{component}
 - **Issue**: #{issue-number}
 - **Branch**: `feat/{issue-number}-{feature-name}`
 - **PR**: -

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

@@ -14,7 +14,7 @@ Core rule: once an idea becomes a Feature, the SSOT moves to `docs/features/`.
 - Put at least these at the top:
   - Goal / context
   - Rough scope (what’s in/out)
-  - Target repo (optional): `be` / `fe` / `both`
+  - Target component (optional): `api` / `app` / `worker` / `all`
 
 ---
 

package/templates/ko/{single → common}/README.md

@@ -4,13 +4,13 @@
 
 ## 상위 구조 요약
 
-| 경로             | 목적               | 핵심 문서/역할                                                |
-| ---------------- | ------------------ | ------------------------------------------------------------- |
+| 경로             | 목적               | 핵심 문서/역할 |
+| ---------------- | ------------------ | -------------- |
 | `docs/agents/`   | 에이전트 운영 규칙 | `custom.md`, `constitution.md` (엔진 종속 가이드는 `npx lee-spec-kit docs get <doc-id> --json`으로 조회) |
-| `docs/prd/`      | 제품 요구사항      | 프로젝트별 작성                                               |
-| `docs/designs/`  | 디자인 참고 자료   | `README.md` (링크/가이드/레퍼런스)                            |
-| `docs/ideas/`    | 아이디어/To-do      | `README.md` (Idea → Feature 승격 규칙)                        |
-| `docs/features/` | 기능별 문서        | `{feature-id}/spec.md`, `plan.md`, `tasks.md`, `decisions.md` |
+| `docs/prd/`      | 제품 요구사항      | 프로젝트별 작성 |
+| `docs/designs/`  | 디자인 참고 자료   | `README.md` (링크/가이드/레퍼런스) |
+| `docs/ideas/`    | 아이디어/To-do     | `README.md` (Idea → Feature 승격 규칙) |
+| `{{featurePath}}` | 기능별 문서        | `{feature-id}/spec.md`, `plan.md`, `tasks.md`, `decisions.md` |
 
 ---
 
@@ -24,7 +24,7 @@
 ### 필드
 
 - `projectName` (string): 프로젝트 이름
-- `projectType` ("single" | "fullstack"): 프로젝트 타입
+- `projectType` ("single" | "multi"): 프로젝트 타입
 - `lang` ("ko" | "en"): 문서 언어
 - `createdAt` (string, YYYY-MM-DD): 생성 날짜
 - `docsRepo` ("embedded" | "standalone"): Docs 관리 방식
@@ -37,7 +37,7 @@
 ```json
 {
   "projectName": "{{projectName}}",
-  "projectType": "single",
+  "projectType": "{{projectType}}",
   "lang": "ko",
   "createdAt": "{{date}}",
   "docsRepo": "embedded",
@@ -48,7 +48,7 @@
 ```json
 {
   "projectName": "{{projectName}}",
-  "projectType": "single",
+  "projectType": "{{projectType}}",
   "lang": "ko",
   "createdAt": "{{date}}",
   "docsRepo": "standalone",

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

@@ -0,0 +1,78 @@
+# Agents Guide
+
+코드 어시스턴트/에이전트 운영 규칙입니다.
+이 문서는 **정책(강제 규칙)만** 다룹니다.
+
+---
+
+## 🚨 사용자 확인 필수 규칙 (MUST)
+
+> ⚠️ 아래 작업은 반드시 사용자 명시 승인(OK) 후에만 진행합니다.
+> ✅ 승인 응답은 `<라벨>` 또는 `<라벨> OK` 형식(예: `A`, `A OK`)입니다.
+
+| 작업 | 확인 시점 | 공유 내용 |
+| --- | --- | --- |
+| 스펙 작성 | `spec.md` 작성 후 | 스펙 내용 전문 |
+| 태스크 실행 | 각 태스크 시작 전 | 태스크 제목 |
+| 커밋 생성 | `git commit` 전 | 커밋 메시지, 포함 파일 목록 |
+| 이슈 생성 | `gh issue create` 전 | 제목, 본문, 라벨 |
+| PR 생성 | `gh pr create` 전 | 제목, 본문, 라벨 |
+| Assignee 변경 | 본인 외 지정 시 | 대상 사용자명 |
+| Git 원격 작업 | `push`, `merge` 전 (머지 커밋 포함) | 브랜치, 변경 사항 |
+
+확인 절차:
+1. 작업 내용을 먼저 공유
+2. 명시적 승인(OK) 대기
+3. 승인 후 실행
+
+금지:
+- 사용자 응답 없이 임의 진행
+
+---
+
+## 🧾 라벨 응답 계약 (SSOT)
+
+- 사용자에게 보내는 **모든 응답의 마지막**에 현재 상태 + 선택 가능한 라벨을 표시합니다.
+- 기준 데이터는 최신 `npx lee-spec-kit context --json`(또는 `flow --json`)입니다.
+- 라벨 설명은 `actionOptions[].detail` 또는 command `cmd`를 **원문 그대로** 사용합니다. (요약/의역 금지)
+- 사용자가 다른 질문을 하더라도, 실행 가능한 라벨이 있으면 응답 마지막에 동일 블록을 다시 표시합니다.
+- 실행 가능한 라벨이 없으면 `선택 가능: 없음` + `npx lee-spec-kit context` 재확인을 안내합니다.
+- 사용자 입력에 유효 라벨이 없으면 실행하지 말고 라벨 선택을 다시 요청합니다.
+
+출력 형식:
+
+```text
+현재 상태: <reasonCode 또는 상태 요약>
+선택 가능:
+A: <detail>
+B: <detail>
+응답 형식: "<LABEL>" 또는 "<LABEL> OK"
+```
+
+---
+
+## 필수 참조
+
+- 최우선 규칙: `/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-template --json`
+- PR 절차/템플릿: `npx lee-spec-kit docs get create-pr --json` → `npx lee-spec-kit docs get pr-template --json`
+
+---
+
+## 범위 분리
+
+- docs 구조/경로 규칙: `docs/README.md`를 SSOT로 사용
+- ADR 작성 형식: `docs/features/.../decisions.md` 템플릿을 SSOT로 사용
+
+---
+
+## 언어/표기 규칙
+
+- 답변: 한국어
+- 코드/파일명: 영어
+- 주석/커밋메시지: 한국어
+- 날짜/시간: 사용자 PC 시스템 시간 사용

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

@@ -42,8 +42,8 @@ GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
    > 형식: `- **{레이블}**: \`{경로}\``
 
    ```markdown
-   - **Spec**: `docs/features/{be|fe}/F001-feature-name/spec.md`
-   - **Tasks**: `docs/features/{be|fe}/F001-feature-name/tasks.md`
+   - **Spec**: `docs/features/{component}/F001-feature-name/spec.md`
+   - **Tasks**: `docs/features/{component}/F001-feature-name/tasks.md`
    ```
 
 > ⚠️ 로컬 문서는 GitHub에서 클릭되지 않으므로, 마크다운 링크 대신 **볼드 레이블 + 코드블록 경로** 형식을 사용합니다.
@@ -69,7 +69,7 @@ GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
 
 ## 관련 문서
 
-- **Spec**: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
+- **Spec**: `docs/features/{component}/F{번호}-{기능명}/spec.md`
 
 ## 라벨
 

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

@@ -26,6 +26,7 @@ CLI가 출력하는 **`👉 Next Options (Atomic)` 목록에서 단 하나의
 - CLI가 파일 작성을 지시하면 해당 파일을 작성합니다.
 - CLI가 이슈 생성을 지시하면 이슈를 생성합니다.
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
+- 승인 요청 시 라벨 옵션은 `A: ...` 형식으로 **CLI가 출력한 원문(detail/cmd) 그대로** 공유합니다. 요약/의역하지 않습니다.
 
 ### 3단계: 반복
 

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

@@ -15,16 +15,16 @@ Pull Request를 생성할 때 따르는 가이드입니다.
 
 ## 단계
 
-### 1. PR 초안 작성
+### 1. PR 본문 템플릿 준비
 
-> 📖 **먼저 `docs get`으로 절차/템플릿을 읽고, 초안을 생성해 기준으로 사용하세요.**
+> 📖 **먼저 `docs get`으로 절차/템플릿을 읽고, 본문 템플릿을 생성해 기준으로 사용하세요.**
 
 ```bash
 # 1) 절차/템플릿 정책 확인
 npx lee-spec-kit docs get create-pr --json
 npx lee-spec-kit docs get pr-template --json
 
-# 2) 초안 본문 생성 (원격 작업 아님)
+# 2) 본문 템플릿 생성 (원격 작업 아님)
 npx lee-spec-kit github pr F001 --json
 # - 스크린샷 강제 포함: --screenshots on
 # - Mermaid 강제 포함: --mermaid on
@@ -32,7 +32,7 @@ npx lee-spec-kit github pr F001 --json
 ```
 
 `docs get pr-template --json` 출력은 섹션 정책으로 보고,
-`github pr --json`의 `body`를 우선 PR 초안 본문으로 사용하세요.
+`github pr --json`의 `body`를 우선 PR 본문 템플릿으로 사용하세요.
 필요하면 `bodyFile` 경로 파일을 함께 참고하세요.
 
 | 항목   | 형식                               |
@@ -50,7 +50,7 @@ npx lee-spec-kit github pr F001 --json
 
 1. 작업과 관련된 테스트 명령어 실행 (예: `npm test`, `pnpm test`), 테스트가 없는 경우 사용자에게 요청
 2. 결과 확인 (PASS/FAIL)
-3. PR 본문 "테스트" 섹션은 생성된 초안 기준으로, 실제 실행한 테스트만 반영합니다.
+3. PR 본문 "테스트" 섹션은 생성된 본문 템플릿 기준으로, 실제 실행한 테스트만 반영합니다.
 4. 테스트를 실행하지 않았다면, PR 생성 전에 사용자에게 요청/확인합니다.
 
 ### 3. 스크린샷/다이어그램 작성 (PR 본문에 포함)
@@ -122,7 +122,7 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 
 #### 로직/구조 변경 (백엔드 PR)
 
-- PR 본문에 Mermaid **`sequenceDiagram`**을 작성하고, 생성된 초안 형식과 일치하게 유지합니다.
+- PR 본문에 Mermaid **`sequenceDiagram`**을 작성하고, 생성된 본문 템플릿 형식과 일치하게 유지합니다.
 
 ### 4. 사용자 확인 요청
 
@@ -131,10 +131,10 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하고 **명시적 승인(OK)** 대기:
 
 - 제목
-- 본문 전체 초안 (`body` 기준)
+- 본문 전체 템플릿 (`body` 기준)
 - 라벨(최소 1개, 비워둘 수 없음)
 
-승인/생성 전에 생성된 초안의 변경 사항/테스트 섹션을 실제 작업 기준으로 보완하세요.
+승인/생성 전에 생성된 본문 템플릿의 변경 사항/테스트 섹션을 실제 작업 기준으로 보완하세요.
 
 ### 5. PR 생성
 
@@ -189,5 +189,5 @@ PR 본문의 파일 링크는 **현재 브랜치명**을 사용:
 
 ## 참조 문서
 
-- **초안 생성기**: `npx lee-spec-kit github pr <feature-name>`
+- **본문 템플릿 생성기**: `npx lee-spec-kit github pr <feature-name>`
 - **승인 규칙**: 제목/본문/라벨 공유 후 `--create --confirm OK` 실행

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

@@ -24,6 +24,7 @@ CLI가 가리키는 **Active Task** 또는 **`👉 Next Options (Atomic)`의 단
 - **[DOING] 상태인 태스크가 있다면**: 해당 태스크를 최우선으로 완료하세요.
 - 태스크 상태 전환/승인 규칙은 `tasks.md`의 **"태스크 규칙"** 섹션을 SSOT로 따릅니다. (예: `[TODO]→[DOING]`, `[DOING]→[DONE]` 시점의 OK)
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
+- 사용자 응답 포맷(매 응답 말미의 상태/라벨 표시 포함)은 `agents.md`의 **"라벨 응답 계약 (SSOT)"** 을 따릅니다.
 
 ### 3단계: 기록 및 반복 (Record & Loop)