lee-spec-kit 0.1.8 → 0.2.1

package/templates/en/{single → common}/agents/issue-template.md

@@ -36,12 +36,17 @@ In GitHub Issues, use different link formats **based on file location**:
    [react-i18next](https://react.i18next.com/)
    ```
 
-3. **External/local documents** (no URL available): Use **relative path as text only**
-   ```text
-   ../docs/features/F001-feature-name/spec.md
+3. **Local documents** (no URL available): **Path from project root**
+
+   > 📁 Local documents use paths **from project root**.
+   > Format: `- **{Label}**: \`{path}\``
+
+   ```markdown
+   - **Spec**: `{{featurePath}}/F001-feature-name/spec.md`
+   - **Tasks**: `{{featurePath}}/F001-feature-name/tasks.md`
    ```
 
-> ⚠️ Local documents are not clickable on GitHub, so provide path text only.
+> ⚠️ Local documents are not clickable on GitHub, so use **bold label + code block path** format instead of markdown links.
 
 ---
 
@@ -64,7 +69,7 @@ In GitHub Issues, use different link formats **based on file location**:
 
 ## Related Documents
 
-- Spec: `docs/features/F{number}-{feature-name}/spec.md`
+- **Spec**: `{{featurePath}}/F{number}-{feature-name}/spec.md`
 
 ## Labels
 

package/templates/en/{single → common}/agents/pr-template.md

@@ -42,17 +42,24 @@ For file links within the repo in PR body, **always use current branch name**:
 
 ## Tests
 
+> ⚠️ **Check only after running tests. Do NOT check items that were not executed.**
+
 - [ ] Unit tests passed
 - [ ] Integration tests completed
 
+### Execution Results
+
+- Command: `{test command executed}`
+- Result: `{PASS/FAIL summary}`
+
 ## Screenshots (for UI changes)
 
 {Attach if applicable}
 
 ## Related Documents
 
-- Spec: `docs/features/F{number}-{feature-name}/spec.md`
-- Tasks: `docs/features/F{number}-{feature-name}/tasks.md`
+- **Spec**: `{{featurePath}}/F{number}-{feature-name}/spec.md`
+- **Tasks**: `{{featurePath}}/F{number}-{feature-name}/tasks.md`
 
 Closes #{issue-number}
 ```

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

@@ -0,0 +1,53 @@
+# New Feature Creation Process
+
+Step-by-step guide for adding a new Feature.
+
+---
+
+## Steps
+
+### 1. Create Feature Folder
+
+```bash
+npx lee-spec-kit feature <name> -d "<description>"
+```
+
+- `<name>`: Feature name (lowercase, hyphens allowed)
+- `-d`: Feature description (auto-filled in spec.md)
+
+**Example:**
+
+```bash
+npx lee-spec-kit feature user-auth -d "User authentication and session management"
+```
+
+### 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)
+
+### 3. Request User Approval
+
+> 🚨 **User Approval Required**
+
+Share full spec.md content with user and wait for **explicit approval (OK)**
+
+### 4. Create GitHub Issue
+
+→ See `skills/create-issue.md`
+
+### 5. Pre-Commit Checklist
+
+> ⚠️ **Before committing, verify:**
+
+- [ ] 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}`)
+
+---
+
+## Reference Documents
+
+- **Feature Template**: `features/feature-base/`
+- **Issue Creation Guide**: `skills/create-issue.md`

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

@@ -0,0 +1,52 @@
+# GitHub Issue Creation Process
+
+Guide for creating GitHub Issues.
+
+---
+
+## Prerequisites
+
+- [ ] `spec.md` completed
+- [ ] User approval received
+
+---
+
+## Steps
+
+### 1. Prepare Issue Content
+
+> 📖 **Always refer to `issue-template.md`**
+
+| Item     | Format                                      |
+| -------- | ------------------------------------------- |
+| Title    | `F{number}: {feature-name} ({description})` |
+| Body     | Overview, Goals, Criteria, Related docs     |
+| Labels   | `enhancement`, `bug`, `documentation`, etc. |
+| Assignee | `@me` (default)                             |
+
+### 2. Request User Approval
+
+> 🚨 **User Approval Required**
+
+Before creating issue, share and wait for approval:
+
+- Title
+- Body
+- Labels
+
+### 3. Create Issue
+
+```bash
+gh issue create \
+  --title "F{number}: {feature-name} ({description})" \
+  --body-file /tmp/issue-body.md \
+  --assignee @me \
+  --label enhancement
+```
+
+---
+
+## Reference Documents
+
+- **Issue Template**: `issue-template.md`
+- **Link Format Rules**: `issue-template.md` > "Link Format" section

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

@@ -0,0 +1,97 @@
+# Pull Request Creation Process
+
+Guide for creating Pull Requests.
+
+---
+
+## Prerequisites
+
+- [ ] All tasks in `[DONE]` state
+- [ ] Changes committed
+- [ ] Branch pushed
+
+---
+
+## Steps
+
+### 1. Prepare PR Content
+
+> 📖 **Always refer to `pr-template.md`**
+
+| Item     | Format                             |
+| -------- | ---------------------------------- |
+| Title    | `feat(#{issue-number}): {feature}` |
+| Body     | Overview, Changes, Tests, Docs     |
+| Labels   | Appropriate labels                 |
+| Assignee | `@me` (default)                    |
+
+### 2. Test Verification
+
+> 🚨 **Cannot create PR if tests fail**
+
+1. Run related test commands (e.g., `npm test`, `pnpm test`)
+2. Check results (PASS/FAIL)
+3. Record **execution results** in PR body "Tests" section
+4. Check boxes **only for items that actually passed**
+
+### 3. Request User Approval
+
+> 🚨 **User Approval Required**
+
+Before creating PR, share and wait for approval:
+
+- Title
+- Body (including test results)
+- Labels
+
+### 4. Create PR
+
+```bash
+gh pr create \
+  --title "feat(#{issue-number}): {feature}" \
+  --body-file /tmp/pr-body.md \
+  --assignee @me \
+  --base main
+```
+
+---
+
+## Important Notes
+
+### Link Format
+
+Use **current branch name** for file links in PR body:
+
+```markdown
+[filename](https://github.com/{owner}/{repo}/blob/{branch-name}/path/to/file)
+```
+
+> ⚠️ `main` branch links will return 404 until merged!
+
+---
+
+## Code Review Modification Guidelines
+
+> 📋 **Criteria for deciding whether to add a task when modifications are needed from review feedback**
+
+### No task needed (Minor changes)
+
+- Typo/code style fixes
+- Variable/function name changes
+- Comment additions/modifications
+- Lint error fixes
+
+### Task needed (Major changes)
+
+- Logic/algorithm changes
+- New file/function additions
+- API signature changes
+- Test case additions
+- Requires changes to spec.md or plan.md
+
+---
+
+## Reference Documents
+
+- **PR Template**: `pr-template.md`
+- **Git Workflow**: `git-workflow.md`

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

@@ -0,0 +1,86 @@
+# Task Execution Process
+
+Guide for executing tasks from tasks.md.
+
+---
+
+## Steps
+
+### 1. Check Task
+
+- 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]` |
+| On complete | `[DOING]` → `[DONE]` |
+
+Record date (YYYY-MM-DD) with each status change
+
+### 4. Commit After Task Completion
+
+> 🚨 **User Approval Required**
+
+Before committing, share and wait for approval:
+
+- Commit message
+- Files to be included
+
+```bash
+git add .
+git commit -m "{type}(#{issue-number}): {task description}"
+```
+
+---
+
+## 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)
+
+---
+
+## 🚨 Never Modify Completed Tasks
+
+> ⚠️ **Tasks in `[DONE]` status must NEVER be modified.**
+
+### Principle
+
+- Completed tasks are preserved for **history/record purposes**
+- If modifications are needed, **add a new task**
+
+### When Modifications Are Needed
+
+1. Keep the existing task as-is
+2. Add new task: `T{next-number}: {modification description}`
+3. Perform changes in the new task
+
+**Example:**
+
+```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
+```
+
+---
+
+## Reference Documents
+
+- **Git Workflow**: `git-workflow.md`
+- **Commit Convention**: `git-workflow.md` > "Commit Convention" section

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

@@ -75,35 +75,20 @@ docs/
 
 ## Request Type Processes
 
-### 1. New Feature Request
+> 📖 Refer to `skills/` folder for detailed process guides.
 
-1. Identify target repo (BE or FE)
-2. Create feature folder: `npx lee-spec-kit feature <name>`
-3. Write `spec.md` - what and why (no tech stack)
-4. Request spec review from user
-5. Create GitHub Issue
+| Process        | Guide                      |
+| -------------- | -------------------------- |
+| New Feature    | `skills/create-feature.md` |
+| GitHub Issue   | `skills/create-issue.md`   |
+| Pull Request   | `skills/create-pr.md`      |
+| Task Execution | `skills/execute-task.md`   |
 
-### 2. Spec to Plan
+### Additional Rules (Fullstack)
 
-1. Verify spec is clear
-2. Write `plan.md` - tech stack, architecture, file structure
-3. **Record key decisions in `decisions.md`** (required)
-4. Decompose into tasks after user approval
-
-### 3. Task Execution
-
-1. Write tasks in `tasks.md`
-2. Execute after user approval
-3. Transition status: `[TODO]` → `[DOING]` → `[DONE]`
-4. Commit immediately after task completion
-
-### 4. Handling Requests Outside Tasks
-
-> When user requests **work not in tasks.md**:
-
-1. Ask user if this 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)
+- **Identify target repo**: Determine BE or FE before feature creation
+- **Write plan.md**: Tech stack and architecture decisions after spec approval
+- **Record in decisions.md**: Document all major technical decisions
 
 ---
 

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

@@ -70,27 +70,14 @@ docs/
 
 ## Request Type Processes
 
-### 1. New Feature Request
-
-1. Create feature folder: `npx lee-spec-kit feature <name>`
-2. Write `spec.md` - what and why
-3. Request spec review
-4. Create GitHub Issue
-
-### 2. Task Execution
-
-1. Write tasks in `tasks.md`
-2. Execute after approval
-3. Status transition: `[TODO]` → `[DOING]` → `[DONE]`
-4. Commit on task completion
-
-### 3. Handling Requests Outside Tasks
-
-> When user requests **work not in tasks.md**:
-
-1. Ask user if this 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)
+> 📖 Refer to `skills/` folder for detailed process guides.
+
+| Process        | Guide                      |
+| -------------- | -------------------------- |
+| New Feature    | `skills/create-feature.md` |
+| GitHub Issue   | `skills/create-issue.md`   |
+| Pull Request   | `skills/create-pr.md`      |
+| Task Execution | `skills/execute-task.md`   |
 
 ---
 

package/templates/ko/{fullstack → common}/agents/git-workflow.md

@@ -70,89 +70,54 @@ main
 
 ## 자동화 워크플로우
 
-### 1. Feature 시작
+> 📖 단계별 상세 가이드는 `skills/` 폴더를 참조하세요.
 
-```bash
-# 1. GitHub Issue 생성 (Feature = Issue)
-# 2. 브랜치 생성
-git checkout -b feat/{issue-number}-{feature-name}
-```
-
-> `gh`로 이슈/PR 생성·수정 시 작성할 제목/본문/라벨을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
-
-### 2. 문서 커밋 (docs 레포)
-
-> 📌 docs 폴더는 별도 git으로 관리되므로 프로젝트와 분리된 커밋 전략을 사용합니다.
-
-| #   | 커밋 시점                                  | 포함 문서                     | 커밋 메시지 예시                     |
-| --- | ------------------------------------------ | ----------------------------- | ------------------------------------ |
-| 1   | **계획 완료 시** (spec+plan+tasks 승인 후) | spec.md, plan.md, tasks.md    | `docs(#123): spec, plan, tasks 작성` |
-| 2   | **Feature 완료 시** (모든 태스크 완료 후)  | tasks.md (상태), decisions.md | `docs(#123): Feature 완료`           |
-
-> ⚠️ **Feature 폴더 생성 시점**에는 커밋하지 않습니다.
-
-### 3. 태스크 완료 시 자동 커밋
-
-태스크 하나가 완료되면:
-
-```bash
-git add .
-git commit -m "{type}(#{issue}): {task-description}"
-```
-
-> `git commit` 실행 전 커밋 메시지와 포함될 파일 목록을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
+| 워크플로우   | 가이드                     |
+| ------------ | -------------------------- |
+| Feature 시작 | `skills/create-feature.md` |
+| Issue 생성   | `skills/create-issue.md`   |
+| 태스크 실행  | `skills/execute-task.md`   |
+| PR 생성      | `skills/create-pr.md`      |
 
-### 4. Feature 완료 시 PR 생성
-
-모든 태스크 완료 시:
+### 브랜치 생성
 
 ```bash
-git push origin feat/{issue-number}-{feature-name}
-gh pr create --title "feat(#{issue}): {feature-title}" \
-  --body "Closes #{issue}" \
-  --base main
+git checkout -b feat/{issue-number}-{feature-name}
 ```
 
-### 5. 머지
+### 문서 커밋 시점 (docs 레포)
 
-모든 리뷰 해결 시:
+| 커밋 시점                              | 포함 내용                          | 커밋 메시지 예시                               |
+| -------------------------------------- | ---------------------------------- | ---------------------------------------------- |
+| 계획 완료 시 (spec+plan+tasks 승인 후) | `F{번호}-{기능명}/` 폴더 전체      | `docs(#{이슈번호}): F{번호} spec, plan, tasks` |
+| Feature 완료 시 (모든 태스크 완료 후)  | `F{번호}-{기능명}/` 폴더 변경 사항 | `docs(#{이슈번호}): F{번호} Feature 완료`      |
 
-```bash
-# 머지 전 main 최신화
-git checkout main
-git pull
+> ⚠️ Feature 폴더 생성 시점에는 커밋하지 않습니다.
 
-# Squash and Merge
-gh pr merge --squash --delete-branch
+### 머지 전략
 
-# 머지 후 main 최신화
-git pull
-```
+| 상황         | 머지 방식        |
+| ------------ | ---------------- |
+| 일반 Feature | Squash and Merge |
+| 긴급 Hotfix  | Squash and Merge |
 
 ---
 
-## 에이전트 자동화 규칙
+## Docs Push 규칙
 
-### 태스크 완료 시
+> `.lee-spec-kit.json`의 `docsRepo` 설정을 참조합니다.
 
-```
-1. 코드 변경 완료
-2. tasks.md 상태 [DOING] → [DONE] 업데이트 (docs)
-3. git add .
-4. git commit -m "{type}(#{issue}): {description}"
-5. 다음 태스크 진행
-```
+| 설정                                         | 동작                              |
+| -------------------------------------------- | --------------------------------- |
+| `docsRepo: "embedded"`                       | 프로젝트 push 시 docs도 함께 포함 |
+| `docsRepo: "standalone"` + `pushDocs: false` | docs는 커밋만, push 안 함         |
+| `docsRepo: "standalone"` + `pushDocs: true`  | docs 변경 시 별도 push 진행       |
 
-### Feature 완료 시
+### Standalone 모드 주의사항
 
-```
-1. 모든 태스크 [DONE] 확인
-2. git push origin {branch}
-3. gh pr create
-4. 리뷰 대기
-5. 리뷰 코멘트 수정
-6. gh pr merge --squash
-```
+- `pushDocs: false`인 경우 docs 변경사항은 **로컬에만 커밋**
+- `pushDocs: true`인 경우 docs 변경 후 **별도로 push** 필요
+- 프로젝트 레포와 docs 레포가 분리되어 있으므로 **각각 관리**
 
 ---
 

package/templates/ko/{fullstack → common}/agents/issue-template.md

@@ -36,12 +36,17 @@ GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
    [react-i18next](https://react.i18next.com/)
    ```
 
-3. **외부/로컬 문서** (docs 레포 등, URL 없음): **상대 경로 텍스트로만 표기**
-   ```text
-   ../docs/features/F001-feature-name/spec.md
+3. **로컬 문서** (docs 레포 등, URL 없음): **프로젝트 루트 기준 경로**
+
+   > 📁 로컬 문서는 **프로젝트 루트 기준** 경로로 작성합니다.
+   > 형식: `- **{레이블}**: \`{경로}\``
+
+   ```markdown
+   - **Spec**: `{{featurePath}}/F001-feature-name/spec.md`
+   - **Tasks**: `{{featurePath}}/F001-feature-name/tasks.md`
    ```
 
-> ⚠️ 로컬 문서는 GitHub에서 클릭되지 않으므로, 링크 대신 경로 텍스트만 제공합니다.
+> ⚠️ 로컬 문서는 GitHub에서 클릭되지 않으므로, 마크다운 링크 대신 **볼드 레이블 + 코드블록 경로** 형식을 사용합니다.
 
 ---
 
@@ -64,7 +69,7 @@ GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
 
 ## 관련 문서
 
-- Spec: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
+- **Spec**: `{{featurePath}}/F{번호}-{기능명}/spec.md`
 
 ## 라벨
 

package/templates/ko/{fullstack → common}/agents/pr-template.md

@@ -40,17 +40,24 @@ PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을
 
 ## 테스트
 
+> ⚠️ **실제 테스트 실행 후 체크하세요. 미실행 항목은 체크하지 마세요.**
+
 - [ ] 유닛 테스트 통과
 - [ ] 통합 테스트 완료
 
+### 실행 결과
+
+- 명령어: `{실행한 테스트 명령어}`
+- 결과: `{PASS/FAIL 요약}`
+
 ## 스크린샷 (UI 변경 시)
 
 {있으면 첨부}
 
 ## 관련 문서
 
-- Spec: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
-- Tasks: `docs/features/{be|fe}/F{번호}-{기능명}/tasks.md`
+- **Spec**: `{{featurePath}}/F{번호}-{기능명}/spec.md`
+- **Tasks**: `{{featurePath}}/F{번호}-{기능명}/tasks.md`
 
 Closes #{이슈번호}
 ```

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

@@ -0,0 +1,53 @@
+# 새 기능 추가 프로세스
+
+새 기능(Feature)을 추가할 때 따르는 단계별 가이드입니다.
+
+---
+
+## 단계
+
+### 1. Feature 폴더 생성
+
+```bash
+npx lee-spec-kit feature <name> -d "<설명>"
+```
+
+- `<name>`: 기능 이름 (영문, 하이픈 사용)
+- `-d`: 기능 설명 (spec.md에 자동 반영)
+
+**예시:**
+
+```bash
+npx lee-spec-kit feature user-auth -d "사용자 인증 및 세션 관리"
+```
+
+### 2. spec.md 작성
+
+- **무엇을**: 기능이 무엇인지 명확히 기술
+- **왜**: 이 기능이 필요한 이유
+- ❌ 기술 스택은 작성하지 않음 (plan.md에서 다룸)
+
+### 3. 사용자 확인 요청
+
+> 🚨 **사용자 확인 필수**
+
+spec.md 전문을 사용자에게 공유하고 **명시적 승인(OK)** 대기
+
+### 4. GitHub Issue 생성
+
+→ `skills/create-issue.md` 참조
+
+### 5. 문서 커밋 전 확인
+
+> ⚠️ **커밋 전 체크리스트**
+
+- [ ] spec.md에 이슈번호 반영 (`- **이슈 번호**: #{이슈번호}`)
+- [ ] tasks.md에 이슈번호 반영 (`- **Issue**: #{이슈번호}`)
+- [ ] tasks.md에 브랜치명 반영 (`feat/{이슈번호}-{기능명}`)
+
+---
+
+## 참조 문서
+
+- **Feature 템플릿**: `features/feature-base/`
+- **Issue 생성 가이드**: `skills/create-issue.md`