lee-spec-kit 0.2.3 → 0.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.2.3",
+  "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/constitution.md

@@ -44,33 +44,19 @@ All development decisions are based on this document.
 
 ## Architecture Principles
 
-### 1. Feature-Centric Management
-
-- Manage new features in `docs/features/F00X/` structure
-- Develop by **feature unit** (FE/BE separate)
-- spec → plan → tasks → decisions workflow
-
-### 2. (Additional Principles)
-
-(Write project-specific architecture principles here)
+> (Write project-specific architecture principles here. e.g., layer structure, dependency rules)
 
 ---
 
 ## Code Quality Standards
 
-- TypeScript strict mode required
-- ESLint + Prettier required
-- Major business logic test coverage **80%+**
-- Components follow **Single Responsibility Principle**
-- Minimize code duplication
+> (Write project code quality standards here. e.g., test coverage, lint rules)
 
 ---
 
 ## Security Principles
 
-- Manage secrets via environment variables (no repo commits)
-- **Minimal data collection** for user data
-- CORS only for allowed origins
+> (Write project security principles here. e.g., authentication method, data encryption)
 
 ---
 

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,94 +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    |
-| ------------------- | -------------------- |
-| On start            | `[TODO]` → `[DOING]` |
-| After user approval | `[DOING]` → `[DONE]` |
-
-> ⚠️ Even after work is complete, **stay in `[DOING]` until user approval**
-
-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/constitution.md

@@ -44,33 +44,19 @@
 
 ## 아키텍처 원칙
 
-### 1. Feature 중심 관리
-
-- 새 기능은 `docs/features/F00X/` 구조로 관리
-- FE/BE 분리하여 **기능 단위**로 개발
-- spec → plan → tasks → decisions 워크플로우
-
-### 2. (추가 원칙)
-
-(프로젝트별 아키텍처 원칙을 작성하세요)
+> (프로젝트별 아키텍처 원칙을 작성하세요. 예: 레이어 구조, 의존성 규칙 등)
 
 ---
 
 ## 코드 품질 기준
 
-- TypeScript strict mode 필수
-- ESLint + Prettier 필수
-- 주요 비즈니스 로직 테스트 커버리지 **80%+**
-- 컴포넌트는 **단일 책임 원칙**
-- 중복 코드 최소화
+> (프로젝트의 코드 품질 기준을 작성하세요. 예: 테스트 커버리지, 린트 규칙 등)
 
 ---
 
 ## 보안 원칙
 
-- 환경 변수로 시크릿 관리 (저장소 커밋 금지)
-- 사용자 데이터 **최소 수집**
-- CORS는 허용 오리진만 설정
+> (프로젝트의 보안 원칙을 작성하세요. 예: 인증 방식, 데이터 암호화 등)
 
 ---