lee-spec-kit 0.1.7 → 0.2.0

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

@@ -4,10 +4,38 @@
 
 ---
 
+## 🚨 사용자 확인 필수 규칙 (MUST)
+
+> ⚠️ **아래 작업은 반드시 사용자의 명시적 승인(OK)을 받은 후에만 진행합니다.**
+> **확인 없이 진행 시 작업을 즉시 중단해야 합니다.**
+
+| 작업          | 확인 시점            | 공유 내용                   |
+| ------------- | -------------------- | --------------------------- |
+| 스펙 작성     | `spec.md` 작성 후    | 스펙 내용 전문              |
+| 태스크 실행   | 각 태스크 시작 전    | 실행 계획                   |
+| 커밋 생성     | `git commit` 전      | 커밋 메시지, 포함 파일 목록 |
+| 이슈 생성     | `gh issue create` 전 | 제목, 본문, 라벨            |
+| PR 생성       | `gh pr create` 전    | 제목, 본문, 라벨            |
+| Assignee 변경 | 본인 외 지정 시      | 대상 사용자명               |
+| Git 원격 작업 | `push`, `merge` 전   | 브랜치, 변경 사항           |
+
+### 확인 프로세스
+
+1. 작업 내용을 사용자에게 **먼저 공유**
+2. 사용자의 **명시적 승인(OK)** 대기
+3. 승인 후에만 실행
+
+> 🚫 **금지 사항**: 사용자 응답 없이 임의로 진행하는 것
+
+---
+
 ## 참조 문서
 
 ### 핵심 문서
 
+> ⚠️ **`custom.md`의 규칙은 다른 모든 규칙보다 우선합니다.**
+
+- **🔴 커스텀 규칙 (최우선)**: `/docs/agents/custom.md`
 - **프로젝트 원칙**: `/docs/agents/constitution.md`
 - **Git 워크플로우**: `/docs/agents/git-workflow.md`
 - **이슈 템플릿**: `/docs/agents/issue-template.md`
@@ -63,42 +91,20 @@ docs/
 
 ## 요청 유형별 프로세스
 
-### 1. 새 기능 추가 요청
-
-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` 참조)
-
-### 2. 기능 스펙 → 계획 수립
-
-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. 변경 필요시 새 기능/태스크 생성 권장
+> 📖 각 프로세스의 상세 가이드는 `skills/` 폴더를 참조하세요.
 
-### 5. 태스크 외 요청 처리
+| 프로세스          | 가이드                     |
+| ----------------- | -------------------------- |
+| 새 기능 추가      | `skills/create-feature.md` |
+| GitHub Issue 생성 | `skills/create-issue.md`   |
+| Pull Request 생성 | `skills/create-pr.md`      |
+| 태스크 실행       | `skills/execute-task.md`   |
 
-> 사용자가 **tasks.md에 없는 작업**을 요청하면:
+### 추가 규칙 (Fullstack)
 
-1. 해당 작업을 **tasks.md에 반영할지** 사용자에게 확인
-2. 승인 시: tasks.md에 추가 후 실행
-3. 거부 시: 임시 작업으로 진행 (커밋에는 포함)
+- **대상 레포 확인**: 기능 생성 전 BE 또는 FE 레포 확인
+- **plan.md 작성**: 스펙 승인 후 기술 스택, 아키텍처 결정
+- **decisions.md 기록**: 주요 기술 결정 필수 기록
 
 ---
 

package/templates/ko/single/agents/agents.md

@@ -4,10 +4,38 @@
 
 ---
 
+## 🚨 사용자 확인 필수 규칙 (MUST)
+
+> ⚠️ **아래 작업은 반드시 사용자의 명시적 승인(OK)을 받은 후에만 진행합니다.**
+> **확인 없이 진행 시 작업을 즉시 중단해야 합니다.**
+
+| 작업          | 확인 시점            | 공유 내용                   |
+| ------------- | -------------------- | --------------------------- |
+| 스펙 작성     | `spec.md` 작성 후    | 스펙 내용 전문              |
+| 태스크 실행   | 각 태스크 시작 전    | 실행 계획                   |
+| 커밋 생성     | `git commit` 전      | 커밋 메시지, 포함 파일 목록 |
+| 이슈 생성     | `gh issue create` 전 | 제목, 본문, 라벨            |
+| PR 생성       | `gh pr create` 전    | 제목, 본문, 라벨            |
+| Assignee 변경 | 본인 외 지정 시      | 대상 사용자명               |
+| Git 원격 작업 | `push`, `merge` 전   | 브랜치, 변경 사항           |
+
+### 확인 프로세스
+
+1. 작업 내용을 사용자에게 **먼저 공유**
+2. 사용자의 **명시적 승인(OK)** 대기
+3. 승인 후에만 실행
+
+> 🚫 **금지 사항**: 사용자 응답 없이 임의로 진행하는 것
+
+---
+
 ## 참조 문서
 
 ### 핵심 문서
 
+> ⚠️ **`custom.md`의 규칙은 다른 모든 규칙보다 우선합니다.**
+
+- **🔴 커스텀 규칙 (최우선)**: `/docs/agents/custom.md`
 - **프로젝트 원칙**: `/docs/agents/constitution.md`
 - **Git 워크플로우**: `/docs/agents/git-workflow.md`
 - **이슈 템플릿**: `/docs/agents/issue-template.md`
@@ -34,7 +62,12 @@ docs/
 │   ├── constitution.md
 │   ├── git-workflow.md
 │   ├── issue-template.md
-│   └── pr-template.md
+│   ├── pr-template.md
+│   └── skills/         # 프로세스별 가이드
+│       ├── create-feature.md
+│       ├── create-issue.md
+│       ├── create-pr.md
+│       └── execute-task.md
 ├── prd/                # 제품 요구사항
 ├── features/           # 기능별 문서
 │   ├── feature-base/   # 템플릿
@@ -55,27 +88,14 @@ docs/
 
 ## 요청 유형별 프로세스
 
-### 1. 새 기능 추가 요청
-
-1. 새 기능 폴더 생성: `npx lee-spec-kit feature <name>`
-2. `spec.md` 작성 - 무엇을, 왜 만드는지
-3. 사용자에게 스펙 초안 확인 요청
-4. GitHub Issue 생성
-
-### 2. 태스크 실행 및 관리
-
-1. `tasks.md`에 태스크 작성
-2. 사용자 승인 후 실행
-3. 상태 전환: `[TODO]` → `[DOING]` → `[DONE]`
-4. 태스크 완료 직후 커밋
-
-### 3. 태스크 외 요청 처리
-
-> 사용자가 **tasks.md에 없는 작업**을 요청하면:
+> 📖 각 프로세스의 상세 가이드는 `skills/` 폴더를 참조하세요.
 
-1. 해당 작업을 **tasks.md에 반영할지** 사용자에게 확인
-2. 승인 시: tasks.md에 추가 후 실행
-3. 거부 시: 임시 작업으로 진행 (커밋에는 포함)
+| 프로세스          | 가이드                     |
+| ----------------- | -------------------------- |
+| 새 기능 추가      | `skills/create-feature.md` |
+| GitHub Issue 생성 | `skills/create-issue.md`   |
+| Pull Request 생성 | `skills/create-pr.md`      |
+| 태스크 실행       | `skills/execute-task.md`   |
 
 ---
 

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

@@ -1,80 +0,0 @@
-# {{projectName}} Constitution
-
-Core principles and technical decision guidelines for the project.
-All development decisions should be based on this document.
-
-> **📌 Document Scope**
->
-> - **This document**: Tech stack, architecture principles, code quality, security principles
-> - **PRD**: Product requirements, business logic, user stories → `prd/*.md`
-
----
-
-## Project Mission
-
-> (Write your project mission here)
-
----
-
-## Tech Stack
-
-### Backend
-
-| Technology     | Version   | Reason   |
-| -------------- | --------- | -------- |
-| (e.g., NestJS) | (version) | (reason) |
-
-### Frontend
-
-| Technology    | Version   | Reason   |
-| ------------- | --------- | -------- |
-| (e.g., React) | (version) | (reason) |
-
-### Common
-
-| Technology        | Version | Reason             |
-| ----------------- | ------- | ------------------ |
-| TypeScript        | strict  | Type safety        |
-| ESLint + Prettier | -       | Code quality       |
-| pnpm              | -       | Package management |
-
----
-
-## Architecture Principles
-
-### 1. Feature-Centric Management
-
-- New features managed in `docs/features/F00X/` structure
-- Develop by **feature unit** with FE/BE separation
-- Workflow: spec → plan → tasks → decisions
-
-### 2. (Additional Principles)
-
-(Write project-specific architecture principles)
-
----
-
-## Code Quality Standards
-
-- TypeScript strict mode required
-- ESLint + Prettier required
-- Test coverage **80%+** for core business logic
-- Components follow **single responsibility principle**
-- Minimize code duplication
-
----
-
-## Security Principles
-
-- Manage secrets via environment variables (no repo commits)
-- **Minimal** user data collection
-- CORS configured for allowed origins only
-
----
-
-## Language/Code Rules
-
-- **AI Responses**: English
-- **Code/Filenames**: English
-- **Comments/Commits**: English
-- **Date/Time**: User's PC system time (e.g., `{{date}}`)

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

@@ -1,110 +0,0 @@
-# GitHub Issue Template Guide
-
-Template for AI agents to create GitHub Issues.
-
----
-
-## Issue Creation Rules
-
-### Title Format
-
-```text
-F{number}: {feature-name} ({short description})
-```
-
-Example: `F001: user-auth (User authentication feature)`
-
-### Link Format (Important!)
-
-In GitHub Issues, use different link formats **based on file location**:
-
-1. **Files within project repo**: Use full URL (clickable)
-   - **Merged documents/code**: Use `main` branch
-     ```markdown
-     [filename](https://github.com/{owner}/{repo}/blob/main/path/to/file)
-     ```
-   - **In-progress documents** (not merged yet): Use **Feature branch**
-     ```markdown
-     [filename](https://github.com/{owner}/{repo}/blob/{feat-branch}/path/to/file)
-     ```
-
-2. **External documents (with public URL)**: Use **absolute URL**
-
-   ```markdown
-   [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
-   ```
-
-> ⚠️ Local documents are not clickable on GitHub, so provide path text only.
-
-## Issue Body Template
-
-```markdown
-## Overview
-
-{Brief description of the feature}
-
-## Goals
-
-- {Goal 1}
-- {Goal 2}
-
-## Completion Criteria
-
-- [ ] {Criterion 1}
-- [ ] {Criterion 2}
-
-## Related Documents
-
-- Spec: `docs/features/{be|fe}/F{number}-{feature-name}/spec.md`
-
-## Labels
-
-- `enhancement` (New feature)
-- `bug` (Bug fix)
-- `documentation` (Documentation)
-```
-
----
-
-## Label Rules
-
-| Label           | Usage         |
-| --------------- | ------------- |
-| `enhancement`   | New feature   |
-| `bug`           | Bug fix       |
-| `documentation` | Documentation |
-| `backend`       | BE related    |
-| `frontend`      | FE related    |
-| `priority:high` | High priority |
-
-> ⚠️ If a label does not exist, create it first:
->
-> ```bash
-> gh label create "label-name" --description "description" --color "color-code"
-> ```
-
----
-
-## Assignee Rules
-
-- Default: Self-assign (`--assignee @me`)
-- When assigning others, **confirm with user** first
-- Examples:
-  ```bash
-  gh issue create --assignee @me ...
-  gh issue create --assignee username ...
-  ```
-
----
-
-## Body Input Rules (Shell Execution Prevention)
-
-- Issue body should use **`--body-file` by default**.
-- If the body contains backticks (`) or `$()`and is placed directly in`"..."`, it may be **interpreted by the shell**.
-- For multi-line bodies, use **single-quoted heredoc** like `cat <<'EOF'`,
-  and handle variables via **placeholder → sed substitution**.

package/templates/en/fullstack/agents/pr-template.md

@@ -1,96 +0,0 @@
-# GitHub PR Template Guide
-
-Template for AI agents to create Pull Requests.
-
----
-
-## PR Creation Rules
-
-### Title Format
-
-```text
-feat(#{issue-number}): {feature-name}
-```
-
-Example: `feat(#1): Implement user authentication`
-
-### Link Format (Important!)
-
-For file links within the repo in PR body, **always use current branch name**:
-
-```markdown
-[filename](https://github.com/{owner}/{repo}/blob/{branch-name}/docs/path/to/file.md)
-```
-
-> ⚠️ `main` branch links will return 404 until merged!
-> Always use the **current feature branch name** (e.g., `feat/5-feature-name`).
-
-## PR Body Template
-
-```markdown
-## Overview
-
-{Brief description of changes}
-
-## Changes
-
-- {Change 1}
-- {Change 2}
-- {Change 3}
-
-## Tests
-
-- [ ] Unit tests passed
-- [ ] Integration tests completed
-
-## Screenshots (for UI changes)
-
-{Attach if applicable}
-
-## Related Documents
-
-- Spec: `docs/features/{be|fe}/F{number}-{feature-name}/spec.md`
-- Tasks: `docs/features/{be|fe}/F{number}-{feature-name}/tasks.md`
-
-Closes #{issue-number}
-```
-
----
-
-## Merge Rules
-
-| Situation      | Merge Method     |
-| -------------- | ---------------- |
-| Normal Feature | Squash and Merge |
-| Urgent Hotfix  | Merge or Rebase  |
-| Documentation  | Squash and Merge |
-
----
-
-## Label Rules
-
-- Specify appropriate labels when creating PR (`--label`)
-- If a label does not exist, create it first:
-  ```bash
-  gh label create "label-name" --description "description" --color "color-code"
-  ```
-
----
-
-## Assignee Rules
-
-- Default: Self-assign (`--assignee @me`)
-- Use `--reviewer` option to specify reviewers
-- Examples:
-  ```bash
-  gh pr create --assignee @me --reviewer reviewer-username ...
-  ```
-
----
-
-## Body Input Rules (Shell Execution Prevention)
-
-- PR body should use **`--body-file` by default**.
-- If the body contains backticks (`) or `$()`and is placed directly in`"..."`, it may be **interpreted by the shell**.
-- For multi-line bodies, use **single-quoted heredoc** like `cat <<'EOF'`,
-  and handle variables via **placeholder → sed substitution**.