lee-spec-kit 0.2.4 → 0.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.2.4",
+  "version": "0.3.0",
   "description": "Project documentation structure generator for AI-assisted development",
   "type": "module",
   "bin": {
@@ -12,13 +12,6 @@
     "dist",
     "templates"
   ],
-  "scripts": {
-    "build": "tsup",
-    "dev": "tsup --watch",
-    "lint": "eslint src",
-    "format": "prettier --write .",
-    "prepublishOnly": "pnpm build"
-  },
   "keywords": [
     "docs",
     "template",
@@ -45,6 +38,7 @@
     "prompts": "^2.4.2"
   },
   "devDependencies": {
+    "@eslint/js": "^9.39.2",
     "@types/fs-extra": "^11.0.4",
     "@types/node": "^25.0.3",
     "@types/prompts": "^2.4.9",
@@ -56,5 +50,10 @@
     "tsup": "^8.5.1",
     "typescript": "^5.9.3"
   },
-  "packageManager": "pnpm@10.7.0"
-}
+  "scripts": {
+    "build": "tsup",
+    "dev": "tsup --watch",
+    "lint": "eslint src",
+    "format": "prettier --write ."
+  }
+}

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

@@ -1,75 +1,69 @@
-# New Feature Creation Process
+# Feature Implementation Process: CLI-driven
 
-Step-by-step guide for adding a new Feature.
+This document defines the **only rule** for adding a new Feature.
+As an agent, do not trust your own judgment—follow the **CLI output** only.
 
 ---
 
-## Steps
+## 🔄 The Loop (repeat forever)
 
-### 1. Create Feature Folder
+Repeat this loop until the Feature is complete (docs committed).
 
-```bash
-npx lee-spec-kit feature <name> -d "<description>"
-```
+### Step 1: Check context
 
-- `<name>`: Feature name (lowercase, hyphens allowed)
-- `-d`: Feature description (auto-filled in spec.md)
-
-**Example:**
+Run this command whenever you start work or finish a step:
 
 ```bash
-npx lee-spec-kit feature user-auth -d "User authentication and session management"
+npx lee-spec-kit context
 ```
 
-### 2. Write spec.md
-
-- **What**: Clearly describe what the feature does
-- **Why**: Explain why this feature is needed
-- ❌ Do NOT include tech stack (covered in plan.md)
+### Step 2: Do exactly what the CLI says
 
-### 3. Request User Approval
+Read the `👉 Next Action` output and execute **only that instruction**.
 
-> 🚨 **User Approval Required**
+- 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`.)
 
-Share full spec.md content with user and wait for **explicit approval (OK)**
+### Step 3: Repeat
 
-### 4. Create GitHub Issue
+After completing the action, go back to Step 1 and run `context` again.
 
-→ See `skills/create-issue.md`
+---
 
-### 5. Create Branch
+## 🛑 Strict rules
 
-```bash
-git checkout -b feat/{issue-number}-{feature-name}
-```
+1. **Do not jump ahead**: Never do “Plan” when the CLI says “Spec”.
+2. **Do not skip**: Do not fake issue numbers/statuses to advance steps.
+3. **No self-judgment**: If unsure, run `context` again.
 
-> ⚠️ **Do NOT work on main branch.** Always create a branch after issue creation.
+---
 
-### 6. Pre-Commit Checklist
+## Reference: the 10-step workflow (reference only)
 
-> ⚠️ **Before committing, verify:**
+> ⚠️ Do NOT execute these from memory. Always follow the CLI.
 
-- [ ] Issue number in spec.md (`- **Issue Number**: #{issue}`)
-- [ ] Issue number in tasks.md (`- **Issue**: #{issue}`)
-- [ ] Branch name in tasks.md (`feat/{issue-number}-{feature-name}`)
+1. Feature folder created
+2. Write `spec.md`
+3. Get `spec.md` approved
+4. Create GitHub Issue and record `#`
+5. Create feature branch
+6. Write `plan.md`
+7. Get `plan.md` approved
+8. Write/execute `tasks.md`
+9. Pre-commit verification
+10. Commit docs
 
-### 7. Commit Documents
+---
 
-> 🚨 **User Approval Required**
+## Getting started
 
-After spec/plan/tasks approval, commit the **entire Feature folder**:
+If the Feature folder does not exist yet:
 
 ```bash
-git add docs/features/{be|fe}/F{number}-{feature-name}/
-git commit -m "docs(#{issue}): F{number} planning complete"
-```
-
-> 📁 **Included files**: spec.md, plan.md, tasks.md, decisions.md (include even if empty)
-> ⚠️ **Standalone mode**: Switch to Docs repo before committing.
-
----
-
-## Reference Documents
+# 1) Create the folder
+npx lee-spec-kit feature <name> -d "<description>"
 
-- **Feature Template**: `features/feature-base/`
-- **Issue Creation Guide**: `skills/create-issue.md`
+# 2) Enter the loop
+npx lee-spec-kit context
+```

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

@@ -7,6 +7,7 @@ Guide for creating Pull Requests.
 ## Prerequisites
 
 - [ ] All tasks in `[DONE]` state
+- [ ] All checkboxes in `tasks.md` "Completion Criteria" are checked
 - [ ] Changes committed
 - [ ] Branch pushed
 

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

@@ -1,95 +1,43 @@
-# Task Execution Process
+# Task Execution Process: CLI-driven
 
-Guide for executing tasks from tasks.md.
+This document defines the **only rule** for executing tasks.
+As an agent, follow `npx lee-spec-kit context` as the single source of truth.
 
 ---
 
-## Steps
+## 🔄 The Loop (repeat forever)
 
-### 1. Check Task
+Repeat this loop until the Feature is complete.
 
-- Find next task in `tasks.md`
-- Select task with `[TODO]` status
-- ⚠️ **Verify current branch matches Feature branch** (`feat/{issue-number}-{feature-name}`)
-
-### 2. Share Execution Plan
-
-> 🚨 **User Approval Required**
-
-Share execution plan with user before starting and wait for approval
-
-### 3. Update Status
-
-| Timing              | Status Transition    | Checkbox          |
-| ------------------- | -------------------- | ----------------- |
-| On start            | `[TODO]` → `[DOING]` | `[ ]` (No change) |
-| After user approval | `[DOING]` → `[DONE]` | **`[x]` (Check)** |
-
-> ⚠️ Even after work is complete, **stay in `[DOING]` until user approval**
-> ⚠️ When switching to `[DONE]`, **must also check the checkbox**.
-
-Record date (YYYY-MM-DD) with each status change
-
-### 4. Commit After Task Completion (Docs Sync)
-
-> 🚨 **User Approval Required**
-
-Before committing, share and wait for approval:
-
-- Commit message (Applicable repositories)
-- Files to be included
+### Step 1: Check context
 
 ```bash
-# 1. Project Commit (If code changed)
-git add .
-git commit -m "{type}(#{issue}): {task description}"
-
-# 2. Docs Commit (If docs changed)
-# For Standalone mode, move to docs repo
-git add .
-git commit -m "docs(#{issue}): {task description} update docs"
+npx lee-spec-kit context
 ```
 
----
-
-## Handling Requests Outside tasks.md
-
-When user requests work not in tasks.md:
-
-1. Ask if it should be added to tasks.md
-2. If approved: Add to tasks.md then execute
-3. If declined: Proceed as temporary work (still included in commit)
+### Step 2: Do the next action only
 
----
-
-## 🚨 Never Modify Completed Tasks
-
-> ⚠️ **Tasks in `[DONE]` status must NEVER be modified.**
+Execute the `👉 Next Action` exactly as printed by the CLI.
 
-### Principle
+- If the CLI points to an active task, focus on that task only.
+- If there is no active task, pick the next `[TODO]` task, switch it to `[DOING]`, and start.
+- If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
 
-- Completed tasks are preserved for **history/record purposes**
-- If modifications are needed, **add a new task**
+### Step 3: Update tasks.md (only what you did)
 
-### When Modifications Are Needed
+Keep `tasks.md` aligned with reality.
 
-1. Keep the existing task as-is
-2. Add new task: `T{next-number}: {modification description}`
-3. Perform changes in the new task
+- 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.
 
-**Example:**
+### Step 4: Repeat
 
-```markdown
-## Tasks
-
-- [DONE] T001: Implement user authentication (2026-01-05)
-- [DONE] T002: Create login page (2026-01-06)
-- [TODO] T003: Fix T002 - Add password validation ← New task for modifications
-```
+After finishing a meaningful chunk of work, run `context` again.
 
 ---
 
-## Reference Documents
+## 🛑 Strict rules
 
-- **Git Workflow**: `git-workflow.md`
-- **Commit Convention**: `git-workflow.md` > "Commit Convention" section
+1. **No skipping**: Never “finish” tasks by editing status only.
+2. **No jumping ahead**: If the CLI is waiting for approvals, stop and ask the user.
+3. **No rewriting history**: Do not modify `[DONE]` tasks; add a new one.

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

@@ -0,0 +1,29 @@
+# Designs
+
+Store design references used by the project.
+
+(e.g., Figma links, screenshots, design system rules, UI guidelines)
+
+---
+
+## What belongs here
+
+- Screen/flow references (Figma, images, links)
+- Component/pattern guidelines (buttons, forms, navigation, etc.)
+- UI rules (brand, typography, colors/tokens)
+
+---
+
+## Conventions
+
+- For external references, keep the **source URL + a short summary (or a snapshot)**.
+- Use kebab-case filenames (e.g., `auth-flow.md`, `design-system.md`).
+- If you need images/files, create and use an `assets/` folder.
+
+---
+
+## How to reference
+
+Prefer **project-root paths** over relative links in feature docs:
+
+- Example: `docs/designs/auth-flow.md`

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

@@ -0,0 +1,30 @@
+# Ideas
+
+A place for pre-feature ideas / to-dos / experiments.
+
+Core rule: once an idea becomes a Feature, the SSOT moves to `docs/features/`.
+
+---
+
+## Conventions
+
+- 1 idea = 1 file (kebab-case recommended)
+  - Example: `login-rate-limit.md`
+  - Example: `admin-dashboard-metrics.md`
+- Put at least these at the top:
+  - Goal / context
+  - Rough scope (what’s in/out)
+  - Target repo (optional): `be` / `fe` / `both`
+
+---
+
+## Promotion / Cleanup (Idea → Feature)
+
+1. Create a Feature folder with `npx lee-spec-kit feature <name>`
+2. Add the idea doc path to the new Feature’s `spec.md` or `tasks.md`
+   - Example: `docs/ideas/login-rate-limit.md`
+3. Remove the idea from the active list (choose one):
+   - **Recommended**: move to `docs/ideas/archive/` and add `Status: Converted`, `Feature: F00X-...` on top
+   - Or: delete it (only if you don’t need history)
+
+> Tip: archiving is usually better than deleting for traceability (“why this feature exists”).

package/templates/en/fullstack/README.md

@@ -8,5 +8,50 @@ This documentation is organized by feature to help agents quickly understand the
 | ------------------- | --------------------- | ------------------------------------------------------------- |
 | `docs/agents/`      | Agent operating rules | `agents.md`, `constitution.md`, `git-workflow.md`             |
 | `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/be/` | Backend features      | `{feature-id}/spec.md`, `plan.md`, `tasks.md`, `decisions.md` |
 | `docs/features/fe/` | Frontend features     | `{feature-id}/spec.md`, `plan.md`, `tasks.md`, `decisions.md` |
+
+---
+
+## CLI Config (`.lee-spec-kit.json`)
+
+When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs root (default: `docs/`).
+
+- Used by `lee-spec-kit feature`, `status`, and `update` to detect docs location / project type / language.
+- `docsRepo`, `pushDocs`, `docsRemote` are metadata for the **Docs Push rules** in `/docs/agents/git-workflow.md` (the CLI does not auto-push).
+
+### Fields
+
+- `projectName` (string): Project name
+- `projectType` ("single" | "fullstack"): Project type
+- `lang` ("ko" | "en"): Docs language
+- `createdAt` (string, YYYY-MM-DD): Creation date
+- `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)
+
+### Examples
+
+```json
+{
+  "projectName": "{{projectName}}",
+  "projectType": "fullstack",
+  "lang": "en",
+  "createdAt": "{{date}}",
+  "docsRepo": "embedded"
+}
+```
+
+```json
+{
+  "projectName": "{{projectName}}",
+  "projectType": "fullstack",
+  "lang": "en",
+  "createdAt": "{{date}}",
+  "docsRepo": "standalone",
+  "pushDocs": true,
+  "docsRemote": "git@github.com:org/{{projectName}}-docs.git"
+}
+```

package/templates/en/fullstack/agents/agents.md

@@ -33,6 +33,8 @@ Operating rules for AI code assistants to perform consistent code generation and
 
 ### Core Documents
 
+> 🚨 **You MUST read and understand all core documents before proceeding.**
+
 > ⚠️ **Rules in `custom.md` take precedence over all other rules.**
 
 - **🔴 Custom Rules (Highest Priority)**: `/docs/agents/custom.md`
@@ -70,6 +72,8 @@ docs/
 │       ├── create-pr.md
 │       └── execute-task.md
 ├── prd/                # Product requirements
+├── designs/            # Design references
+├── ideas/              # Pre-feature ideas / to-dos
 ├── features/           # Feature documentation
 │   ├── be/             # Backend Features
 │   └── fe/             # Frontend Features

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

@@ -29,5 +29,12 @@
 
 ## Completion Criteria
 
-- [ ] All tasks [DONE]
-- [ ] All tests passing
+> ⚠️ This is a **final verification checklist**. Only check after you actually verified.
+
+- [ ] All tasks are `[DONE]`, and each task's `Acceptance` is verified and `Checklist` is checked
+- [ ] Tests executed and passing (record command/result below)
+
+### Test Run Log
+
+- Command: `{test command you ran}`
+- Result: `{PASS/FAIL summary}`

package/templates/en/single/README.md

@@ -8,4 +8,49 @@ This documentation is organized by feature to help agents quickly understand the
 | ---------------- | --------------------- | ------------------------------------------------------------- |
 | `docs/agents/`   | Agent operating rules | `agents.md`, `constitution.md`, `git-workflow.md`             |
 | `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` |
+
+---
+
+## CLI Config (`.lee-spec-kit.json`)
+
+When you run `lee-spec-kit init`, it creates `.lee-spec-kit.json` in the docs root (default: `docs/`).
+
+- Used by `lee-spec-kit feature`, `status`, and `update` to detect docs location / project type / language.
+- `docsRepo`, `pushDocs`, `docsRemote` are metadata for the **Docs Push rules** in `/docs/agents/git-workflow.md` (the CLI does not auto-push).
+
+### Fields
+
+- `projectName` (string): Project name
+- `projectType` ("single" | "fullstack"): Project type
+- `lang` ("ko" | "en"): Docs language
+- `createdAt` (string, YYYY-MM-DD): Creation date
+- `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)
+
+### Examples
+
+```json
+{
+  "projectName": "{{projectName}}",
+  "projectType": "single",
+  "lang": "en",
+  "createdAt": "{{date}}",
+  "docsRepo": "embedded"
+}
+```
+
+```json
+{
+  "projectName": "{{projectName}}",
+  "projectType": "single",
+  "lang": "en",
+  "createdAt": "{{date}}",
+  "docsRepo": "standalone",
+  "pushDocs": true,
+  "docsRemote": "git@github.com:org/{{projectName}}-docs.git"
+}
+```

package/templates/en/single/agents/agents.md

@@ -33,6 +33,8 @@ Operating rules for AI code assistants to perform consistent code generation and
 
 ### Core Documents
 
+> 🚨 **You MUST read and understand all core documents before proceeding.**
+
 > ⚠️ **Rules in `custom.md` take precedence over all other rules.**
 
 - **🔴 Custom Rules (Highest Priority)**: `/docs/agents/custom.md`
@@ -65,6 +67,8 @@ docs/
 │       ├── create-pr.md
 │       └── execute-task.md
 ├── prd/                # Product requirements
+├── designs/            # Design references
+├── ideas/              # Pre-feature ideas / to-dos
 ├── features/           # Feature documentation
 │   ├── feature-base/   # Template
 │   └── F00X-{name}/

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

@@ -29,5 +29,12 @@
 
 ## Completion Criteria
 
-- [ ] All tasks [DONE]
-- [ ] All tests passing
+> ⚠️ This is a **final verification checklist**. Only check after you actually verified.
+
+- [ ] All tasks are `[DONE]`, and each task's `Acceptance` is verified and `Checklist` is checked
+- [ ] Tests executed and passing (record command/result below)
+
+### Test Run Log
+
+- Command: `{test command you ran}`
+- Result: `{PASS/FAIL summary}`

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

@@ -1,75 +1,70 @@
-# 새 기능 추가 프로세스
+# 기능 구현 프로세스: CLI 주도형
 
-새 기능(Feature)을 추가할 때 따르는 단계별 가이드입니다.
+이 문서는 새 기능(Feature)을 추가할 때 따르는 **유일한 규칙**입니다.
+에이전트는 자신의 판단을 신뢰하지 않고, 오직 **CLI 도구의 지시**에 따라 행동합니다.
 
 ---
 
-## 단계
+## 🔄 The Loop (무한 반복)
 
-### 1. Feature 폴더 생성
+Feature 구현이 완료될 때까지(문서 커밋까지) 다음 과정을 **계속 반복**하세요.
 
-```bash
-npx lee-spec-kit feature <name> -d "<설명>"
-```
+### 1단계: 상태 확인
 
-- `<name>`: 기능 이름 (영문, 하이픈 사용)
-- `-d`: 기능 설명 (spec.md에 자동 반영)
-
-**예시:**
+작업을 시작하거나 한 단계를 마칠 때마다 **반드시** 아래 명령어를 실행합니다.
 
 ```bash
-npx lee-spec-kit feature user-auth -d "사용자 인증 및 세션 관리"
+npx lee-spec-kit context
 ```
 
-### 2. spec.md 작성
-
-- **무엇을**: 기능이 무엇인지 명확히 기술
-- **왜**: 이 기능이 필요한 이유
-- ❌ 기술 스택은 작성하지 않음 (plan.md에서 다룸)
+### 2단계: 지시 수행 (Next Action)
 
-### 3. 사용자 확인 요청
+CLI가 출력하는 **`👉 Next Action` 메시지를 읽고, 그 지시만 정확히 수행**합니다.
 
-> 🚨 **사용자 확인 필수**
+- **승인 대기(Review)** 상태라면 사용자에게 공유하고 멈춥니다.
+- CLI가 파일 작성을 지시하면 해당 파일을 작성합니다.
+- CLI가 이슈 생성을 지시하면 이슈를 생성합니다.
+- CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 
-spec.md 전문을 사용자에게 공유하고 **명시적 승인(OK)** 대기
+### 3단계: 반복
 
-### 4. GitHub Issue 생성
+지시된 행동을 완료했다면, **즉시 1단계로 돌아가** 다시 `context`를 확인합니다.
 
-→ `skills/create-issue.md` 참조
+---
 
-### 5. 브랜치 생성
+## 🛑 절대 금지 사항 (Strict Rules)
 
-```bash
-git checkout -b feat/{이슈번호}-{기능명}
-```
+1. **앞서가지 않기**: CLI가 "Spec 작성"을 지시했는데 "Plan 작성"까지 한 번에 하지 마세요.
+2. **건너뛰지 않기**: "이슈 생성" 단계를 귀찮아서 생략하거나 가짜 번호를 넣지 마세요.
+3. **스스로 판단 금지**: "이 정도면 됐겠지?"라고 생각하지 말고 CLI에게 물어보세요.
 
-> ⚠️ **main 브랜치에서 작업하지 마세요.** Issue 생성 후 반드시 브랜치를 생성합니다.
+---
 
-### 6. 문서 커밋 전 확인
+## 참조: CLI가 안내하는 10단계 (참조용)
 
-> ⚠️ **커밋 전 체크리스트**
+> ⚠️ 이 단계를 외워서 실행하지 마세요. **참조용**일 뿐입니다. 항상 CLI를 믿으세요.
 
-- [ ] spec.md에 이슈번호 반영 (`- **이슈 번호**: #{이슈번호}`)
-- [ ] tasks.md에 이슈번호 반영 (`- **Issue**: #{이슈번호}`)
-- [ ] tasks.md에 브랜치명 반영 (`feat/{이슈번호}-{기능명}`)
+1. **Feature 폴더 생성**: `npx lee-spec-kit feature ...`
+2. **spec.md 작성**: 기능 정의 (Status: Draft)
+3. **spec.md 승인**: 사용자 검토 및 승인 (Status: Approved)
+4. **GitHub Issue 생성**: 이슈 번호 발급
+5. **브랜치 생성**: `git checkout -b feat/...`
+6. **plan.md 작성**: 구현 계획 (Status: Draft)
+7. **plan.md 승인**: 사용자 검토 및 승인 (Status: Approved)
+8. **tasks.md 작성/실행**: 태스크 분해 및 진행
+9. **문서 커밋 전 확인**: 최종 점검
+10. **문서 커밋**: Docs Sync
 
-### 7. 문서 커밋
+---
 
-> 🚨 **사용자 확인 필수**
+## 시작하기
 
-spec/plan/tasks 승인 후 **Feature 폴더 전체**를 커밋:
+아직 기능 폴더가 없다면, 먼저 폴더를 생성하고 루프를 시작하세요:
 
 ```bash
-git add docs/features/{be|fe}/F{번호}-{기능명}/
-git commit -m "docs(#{이슈번호}): F{번호} 계획 완료"
-```
-
-> 📁 **포함 파일**: spec.md, plan.md, tasks.md, decisions.md (비어있어도 포함)
-> ⚠️ **Standalone 모드**: Docs 레포로 이동 후 커밋하세요.
-
----
-
-## 참조 문서
+# 1. 생성
+npx lee-spec-kit feature <name> -d "<설명>"
 
-- **Feature 템플릿**: `features/feature-base/`
-- **Issue 생성 가이드**: `skills/create-issue.md`
+# 2. 루프 진입
+npx lee-spec-kit context
+```

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

@@ -7,6 +7,7 @@ Pull Request를 생성할 때 따르는 가이드입니다.
 ## 사전 조건
 
 - [ ] 모든 태스크 `[DONE]` 상태
+- [ ] `tasks.md`의 "완료 조건" 체크리스트 모두 체크
 - [ ] 변경 사항 커밋 완료
 - [ ] 브랜치 푸시 완료