lee-spec-kit 0.1.8 → 0.2.0

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,36 @@ 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) 후 진행합니다.
-
-### 4. Feature 완료 시 PR 생성
+| 워크플로우   | 가이드                     |
+| ------------ | -------------------------- |
+| Feature 시작 | `skills/create-feature.md` |
+| Issue 생성   | `skills/create-issue.md`   |
+| 태스크 실행  | `skills/execute-task.md`   |
+| PR 생성      | `skills/create-pr.md`      |
 
-모든 태스크 완료 시:
+### 브랜치 생성
 
 ```bash
-git push origin feat/{issue-number}-{feature-name}
-gh pr create --title "feat(#{issue}): {feature-title}" \
-  --body "Closes #{issue}" \
-  --base main
-```
-
-### 5. 머지
-
-모든 리뷰 해결 시:
-
-```bash
-# 머지 전 main 최신화
-git checkout main
-git pull
-
-# Squash and Merge
-gh pr merge --squash --delete-branch
-
-# 머지 후 main 최신화
-git pull
+git checkout -b feat/{issue-number}-{feature-name}
 ```
 
----
+### 문서 커밋 시점 (docs 레포)
 
-## 에이전트 자동화 규칙
+| 커밋 시점                              | 포함 내용                          | 커밋 메시지 예시                               |
+| -------------------------------------- | ---------------------------------- | ---------------------------------------------- |
+| 계획 완료 시 (spec+plan+tasks 승인 후) | `F{번호}-{기능명}/` 폴더 전체      | `docs(#{이슈번호}): F{번호} spec, plan, tasks` |
+| Feature 완료 시 (모든 태스크 완료 후)  | `F{번호}-{기능명}/` 폴더 변경 사항 | `docs(#{이슈번호}): F{번호} Feature 완료`      |
 
-### 태스크 완료 시
+> ⚠️ Feature 폴더 생성 시점에는 커밋하지 않습니다.
 
-```
-1. 코드 변경 완료
-2. tasks.md 상태 [DOING] → [DONE] 업데이트 (docs)
-3. git add .
-4. git commit -m "{type}(#{issue}): {description}"
-5. 다음 태스크 진행
-```
+### 머지 전략
 
-### Feature 완료 시
-
-```
-1. 모든 태스크 [DONE] 확인
-2. git push origin {branch}
-3. gh pr create
-4. 리뷰 대기
-5. 리뷰 코멘트 수정
-6. gh pr merge --squash
-```
+| 상황         | 머지 방식        |
+| ------------ | ---------------- |
+| 일반 Feature | Squash and Merge |
+| 긴급 Hotfix  | Squash and Merge |
 
 ---
 

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`

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

@@ -0,0 +1,52 @@
+# GitHub Issue 생성 프로세스
+
+GitHub Issue를 생성할 때 따르는 가이드입니다.
+
+---
+
+## 사전 조건
+
+- [ ] `spec.md` 작성 완료
+- [ ] 사용자 승인 완료
+
+---
+
+## 단계
+
+### 1. 이슈 내용 작성
+
+> 📖 **`issue-template.md`를 반드시 참조하세요.**
+
+| 항목   | 형식                                     |
+| ------ | ---------------------------------------- |
+| 제목   | `F{번호}: {기능명} ({짧은 설명})`        |
+| 본문   | 개요, 목표, 완료 조건, 관련 문서         |
+| 라벨   | `enhancement`, `bug`, `documentation` 등 |
+| 담당자 | `@me` (기본값)                           |
+
+### 2. 사용자 확인 요청
+
+> 🚨 **사용자 확인 필수**
+
+이슈 생성 전 다음 내용을 공유하고 승인 대기:
+
+- 제목
+- 본문
+- 라벨
+
+### 3. 이슈 생성
+
+```bash
+gh issue create \
+  --title "F{번호}: {기능명} ({짧은 설명})" \
+  --body-file /tmp/issue-body.md \
+  --assignee @me \
+  --label enhancement
+```
+
+---
+
+## 참조 문서
+
+- **이슈 템플릿**: `issue-template.md`
+- **링크 형식 규칙**: `issue-template.md` > "링크 형식" 섹션

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

@@ -0,0 +1,97 @@
+# Pull Request 생성 프로세스
+
+Pull Request를 생성할 때 따르는 가이드입니다.
+
+---
+
+## 사전 조건
+
+- [ ] 모든 태스크 `[DONE]` 상태
+- [ ] 변경 사항 커밋 완료
+- [ ] 브랜치 푸시 완료
+
+---
+
+## 단계
+
+### 1. PR 내용 작성
+
+> 📖 **`pr-template.md`를 반드시 참조하세요.**
+
+| 항목   | 형식                               |
+| ------ | ---------------------------------- |
+| 제목   | `feat(#{이슈번호}): {기능명}`      |
+| 본문   | 개요, 변경 사항, 테스트, 관련 문서 |
+| 라벨   | 적절한 라벨 지정                   |
+| 담당자 | `@me` (기본값)                     |
+
+### 2. 테스트 검증
+
+> 🚨 **테스트 미통과 시 PR 생성 불가**
+
+1. 관련 테스트 명령어 실행 (예: `npm test`, `pnpm test`)
+2. 결과 확인 (PASS/FAIL)
+3. PR 본문 "테스트" 섹션에 **실행 결과** 기록
+4. 체크박스는 **실제 통과한 항목만** 체크
+
+### 3. 사용자 확인 요청
+
+> 🚨 **사용자 확인 필수**
+
+PR 생성 전 다음 내용을 공유하고 승인 대기:
+
+- 제목
+- 본문 (테스트 결과 포함)
+- 라벨
+
+### 4. PR 생성
+
+```bash
+gh pr create \
+  --title "feat(#{이슈번호}): {기능명}" \
+  --body-file /tmp/pr-body.md \
+  --assignee @me \
+  --base main
+```
+
+---
+
+## 주의사항
+
+### 링크 형식
+
+PR 본문의 파일 링크는 **현재 브랜치명**을 사용:
+
+```markdown
+[파일명](https://github.com/{owner}/{repo}/blob/{브랜치명}/path/to/file)
+```
+
+> ⚠️ `main` 브랜치 링크는 머지 전까지 404 발생!
+
+---
+
+## 코드리뷰 수정 기준
+
+> 📋 **리뷰 피드백으로 수정이 필요할 때 task 추가 여부 판단 기준**
+
+### task 추가 불필요 (사소한 수정)
+
+- 오타/코드 스타일 수정
+- 변수명/함수명 변경
+- 주석 추가/수정
+- 린트 오류 수정
+
+### task 추가 필요 (중요한 수정)
+
+- 로직/알고리즘 변경
+- 새 파일/함수 추가
+- API 시그니처 변경
+- 테스트 케이스 추가
+- spec.md 또는 plan.md 변경이 필요한 경우
+
+---
+
+## 참조 문서
+
+- **PR 템플릿**: `pr-template.md`
+- **Git 워크플로우**: `git-workflow.md`

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

@@ -0,0 +1,86 @@
+# 태스크 실행 프로세스
+
+tasks.md의 태스크를 실행할 때 따르는 가이드입니다.
+
+---
+
+## 단계
+
+### 1. 태스크 확인
+
+- `tasks.md`에서 다음 실행할 태스크 확인
+- 상태가 `[TODO]`인 태스크 선택
+- ⚠️ **현재 브랜치가 해당 Feature 브랜치인지 확인** (`feat/{이슈번호}-{기능명}`)
+
+### 2. 실행 계획 공유
+
+> 🚨 **사용자 확인 필수**
+
+태스크 시작 전 실행 계획을 사용자에게 공유하고 승인 대기
+
+### 3. 상태 전환
+
+| 시점    | 상태 전환            |
+| ------- | -------------------- |
+| 시작 시 | `[TODO]` → `[DOING]` |
+| 완료 시 | `[DOING]` → `[DONE]` |
+
+상태 전환 시 날짜도 함께 기록 (YYYY-MM-DD)
+
+### 4. 태스크 완료 후 커밋
+
+> 🚨 **사용자 확인 필수**
+
+커밋 생성 전 다음 내용을 공유하고 승인 대기:
+
+- 커밋 메시지
+- 포함될 파일 목록
+
+```bash
+git add .
+git commit -m "{type}(#{이슈번호}): {태스크 설명}"
+```
+
+---
+
+## tasks.md에 없는 요청 처리
+
+사용자가 tasks.md에 없는 작업을 요청하면:
+
+1. tasks.md에 반영할지 사용자에게 확인
+2. 승인 시: tasks.md에 추가 후 실행
+3. 거부 시: 임시 작업으로 진행 (커밋에는 포함)
+
+---
+
+## 🚨 완료된 태스크 수정 금지
+
+> ⚠️ **`[DONE]` 상태의 태스크는 절대 수정하지 않습니다.**
+
+### 원칙
+
+- 완료된 태스크는 **히스토리/기록 용도**로 보존
+- 수정이 필요한 경우 **새 태스크를 추가**하여 진행
+
+### 수정이 필요한 경우
+
+1. 기존 태스크는 그대로 유지
+2. 새 태스크를 추가: `T{다음번호}: {수정 내용}`
+3. 새 태스크에서 변경 작업 진행
+
+**예시:**
+
+```markdown
+## Tasks
+
+- [DONE] T001: 사용자 인증 구현 (2026-01-05)
+- [DONE] T002: 로그인 페이지 작성 (2026-01-06)
+- [TODO] T003: T002 수정 - 비밀번호 유효성 검사 추가 ← 수정 필요 시 새 태스크 추가
+```
+
+---
+
+## 참조 문서
+
+- **Git 워크플로우**: `git-workflow.md`
+- **커밋 컨벤션**: `git-workflow.md` > "커밋 컨벤션" 섹션

package/templates/ko/fullstack/agents/agents.md

@@ -91,42 +91,20 @@ docs/
 
 ## 요청 유형별 프로세스
 
-### 1. 새 기능 추가 요청
+> 📖 각 프로세스의 상세 가이드는 `skills/` 폴더를 참조하세요.
 
-1. 대상 레포 확인 (BE 또는 FE)
-2. 새 기능 폴더 생성: `npx lee-spec-kit feature <name>` 또는 `docs/features/README.md` 참조
-3. `spec.md` 작성 - 무엇을, 왜 만드는지 (기술 스택 X)
-4. 사용자에게 스펙 초안 확인 요청
-5. GitHub Issue 생성 (`agents/issue-template.md` 참조)
+| 프로세스          | 가이드                     |
+| ----------------- | -------------------------- |
+| 새 기능 추가      | `skills/create-feature.md` |
+| GitHub Issue 생성 | `skills/create-issue.md`   |
+| Pull Request 생성 | `skills/create-pr.md`      |
+| 태스크 실행       | `skills/execute-task.md`   |
 
-### 2. 기능 스펙 → 계획 수립
+### 추가 규칙 (Fullstack)
 
-1. 스펙이 명확한지 확인
-2. `plan.md` 작성 - 기술 스택, 아키텍처, 파일 구조
-3. **`decisions.md`에 주요 기술 결정 기록** (필수)
-4. 사용자 승인 후 태스크 분해
-
-### 3. 태스크 실행 및 관리
-
-1. `tasks.md`에 태스크 작성 (Acceptance/Checklist 필수)
-2. 사용자 승인 후 실행
-3. **진행 전/후 상태 확인 및 즉시 전환**: `[TODO]` → `[DOING]` → `[DONE]`
-4. 상태 전환 시 날짜 기록 (YYYY-MM-DD)
-5. 태스크를 [DONE]으로 전환할 때 Checklist를 모두 체크
-6. **태스크 완료 직후 상태/날짜 갱신** → 커밋 메시지 제안
-
-### 4. 분석/검토 요청
-
-1. 분석 리포트 작성 (현재 상태, 문제점, 제안, 영향)
-2. 변경 필요시 새 기능/태스크 생성 권장
-
-### 5. 태스크 외 요청 처리
-
-> 사용자가 **tasks.md에 없는 작업**을 요청하면:
-
-1. 해당 작업을 **tasks.md에 반영할지** 사용자에게 확인
-2. 승인 시: tasks.md에 추가 후 실행
-3. 거부 시: 임시 작업으로 진행 (커밋에는 포함)
+- **대상 레포 확인**: 기능 생성 전 BE 또는 FE 레포 확인
+- **plan.md 작성**: 스펙 승인 후 기술 스택, 아키텍처 결정
+- **decisions.md 기록**: 주요 기술 결정 필수 기록
 
 ---