lee-spec-kit 0.1.3 → 0.1.7

package/templates/en/single/features/README.md

@@ -22,7 +22,7 @@ features/
 ## Creating New Features
 
 ```bash
-lee-spec-kit feature user-auth
+npx lee-spec-kit feature user-auth
 ```
 
 > 💡 CLI copies templates from `feature-base/` and auto-assigns IDs.
@@ -41,7 +41,7 @@ lee-spec-kit feature user-auth
 ## Status Check
 
 ```bash
-lee-spec-kit status
+npx lee-spec-kit status
 ```
 
 ---

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

@@ -1,4 +1,4 @@
-# Implementation Plan: {기능명}
+# Implementation Plan: {feature-name}
 
 > Write after spec is approved.
 
@@ -6,7 +6,7 @@
 
 ## Overview
 
-- **Feature ID**: F{번호}
+- **Feature ID**: F{number}
 - **Target Repo**: {{projectName}}
 - **Created**: YYYY-MM-DD
 - **Status**: Draft | Review | Approved

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

@@ -1,4 +1,4 @@
-# Feature Spec: {기능명}
+# Feature Spec: {feature-name}
 
 > Tech stack is covered in plan.md.
 
@@ -6,10 +6,10 @@
 
 ## Overview
 
-- **Feature ID**: F{번호}
-- **Feature Name**: {기능명}
+- **Feature ID**: F{number}
+- **Feature Name**: {feature-name}
 - **Target Repo**: {{projectName}}
-- **Issue Number**: #{이슈번호}
+- **Issue Number**: #{issue-number}
 - **Created**: YYYY-MM-DD
 - **Status**: Draft | Review | Approved
 
@@ -17,6 +17,8 @@
 
 ## Purpose
 
+{{description}}
+
 (Why is this feature needed? What problem does it solve?)
 
 ---

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

@@ -1,4 +1,4 @@
-# Tasks: {기능명}
+# Tasks: {feature-name}
 
 ## Task Rules
 
@@ -10,8 +10,8 @@
 ## GitHub Issue
 
 - **Repo**: {{projectName}}
-- **Issue**: #{이슈번호}
-- **Branch**: `feat/{이슈번호}-{기능명}`
+- **Issue**: #{issue-number}
+- **Branch**: `feat/{issue-number}-{feature-name}`
 
 ---
 
@@ -19,7 +19,7 @@
 
 ### Phase 1: {Phase Name}
 
-- [TODO][P1] T-F{번호}-01 {Task Title}
+- [TODO][P1] T-F{number}-01 {Task Title}
   - Acceptance:
     - (verification condition)
   - Checklist:

package/templates/en/single/prd/README.md

@@ -1,15 +1,20 @@
 # PRD (Product Requirements Document)
 
-이 폴더에는 제품 요구사항 문서를 작성합니다.
+This folder contains product requirements documents.
 
-## 작성 가이드
+> **📌 Document Scope**
+>
+> - **This folder**: Product requirements, business logic, user stories
+> - **Constitution**: Tech stack, architecture principles, code quality, security principles → `agents/constitution.md`
 
-1. 프로젝트 개요와 목표를 정의하세요
-2. 주요 기능과 사용자 스토리를 작성하세요
-3. 기술 아키텍처 개요를 포함하세요
+## Writing Guide
 
-## 예시 파일
+1. Define project overview and goals
+2. Write main features and user stories
+3. Include technical architecture overview
 
-- `{project-name}-prd.md` - 메인 PRD 문서
-- `backend-overview.md` - 백엔드 아키텍처 (선택)
-- `frontend-overview.md` - 프론트엔드 아키텍처 (선택)
+## Example Files
+
+- `{project-name}-prd.md` - Main PRD document
+- `backend-overview.md` - Backend architecture (optional)
+- `frontend-overview.md` - Frontend architecture (optional)

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

@@ -66,7 +66,7 @@ docs/
 ### 1. 새 기능 추가 요청
 
 1. 대상 레포 확인 (BE 또는 FE)
-2. 새 기능 폴더 생성: `lee-spec-kit feature <name>` 또는 `docs/features/README.md` 참조
+2. 새 기능 폴더 생성: `npx lee-spec-kit feature <name>` 또는 `docs/features/README.md` 참조
 3. `spec.md` 작성 - 무엇을, 왜 만드는지 (기술 스택 X)
 4. 사용자에게 스펙 초안 확인 요청
 5. GitHub Issue 생성 (`agents/issue-template.md` 참조)
@@ -92,6 +92,14 @@ docs/
 1. 분석 리포트 작성 (현재 상태, 문제점, 제안, 영향)
 2. 변경 필요시 새 기능/태스크 생성 권장
 
+### 5. 태스크 외 요청 처리
+
+> 사용자가 **tasks.md에 없는 작업**을 요청하면:
+
+1. 해당 작업을 **tasks.md에 반영할지** 사용자에게 확인
+2. 승인 시: tasks.md에 추가 후 실행
+3. 거부 시: 임시 작업으로 진행 (커밋에는 포함)
+
 ---
 
 ## 📋 ADR (Architecture Decision Records) 규칙

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

@@ -3,6 +3,11 @@
 프로젝트의 핵심 원칙과 기술 결정 가이드라인입니다.
 모든 개발 결정은 이 문서를 기준으로 합니다.
 
+> **📌 문서 범위**
+>
+> - **이 문서**: 기술 스택, 아키텍처 원칙, 코드 품질, 보안 원칙
+> - **PRD**: 제품 요구사항, 비즈니스 로직, 사용자 스토리 → `prd/*.md`
+
 ---
 
 ## 프로젝트 미션

package/templates/ko/fullstack/agents/git-workflow.md

@@ -46,6 +46,8 @@ main
 
 ## 커밋 컨벤션
 
+> 📖 Type과 Description은 [Udacity Git Commit Message Style Guide](https://udacity.github.io/git-styleguide/)를 따릅니다.
+
 ### 형식
 
 ```
@@ -78,7 +80,19 @@ git checkout -b feat/{issue-number}-{feature-name}
 
 > `gh`로 이슈/PR 생성·수정 시 작성할 제목/본문/라벨을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
 
-### 2. 태스크 완료 시 자동 커밋
+### 2. 문서 작성 및 커밋
+
+| 문서         | 커밋 시점          | 커밋 메시지 예시         |
+| ------------ | ------------------ | ------------------------ |
+| spec.md      | 사용자 승인 후     | `docs(#123): spec 작성`  |
+| plan.md      | 사용자 승인 후     | `docs(#123): plan 작성`  |
+| tasks.md     | 사용자 승인 후     | `docs(#123): tasks 분해` |
+| decisions.md | 태스크 커밋에 포함 | (별도 커밋 없음)         |
+
+> 📌 **Feature 폴더 생성 시점**에는 커밋하지 않습니다.
+> 각 문서가 **사용자 승인**을 받은 후 개별 커밋합니다.
+
+### 3. 태스크 완료 시 자동 커밋
 
 태스크 하나가 완료되면:
 
@@ -89,7 +103,7 @@ git commit -m "{type}(#{issue}): {task-description}"
 
 > `git commit` 실행 전 커밋 메시지와 포함될 파일 목록을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
 
-### 3. Feature 완료 시 PR 생성
+### 4. Feature 완료 시 PR 생성
 
 모든 태스크 완료 시:
 
@@ -100,7 +114,7 @@ gh pr create --title "feat(#{issue}): {feature-title}" \
   --base main
 ```
 
-### 4. 머지
+### 5. 머지
 
 모든 리뷰 해결 시:
 

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

@@ -16,6 +16,33 @@ F{번호}: {기능명} ({짧은 설명})
 
 > "짧은 설명"은 한 줄로 의도를 전달할 수 있을 정도로만 작성합니다.
 
+### 링크 형식 (중요!)
+
+GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
+
+1. **프로젝트 레포 내 파일**: 전체 URL 사용 (클릭 가능)
+   - **일반 문서/코드** (이미 머지됨): `main` 브랜치
+     ```markdown
+     [파일명](https://github.com/{owner}/{repo}/blob/main/path/to/file)
+     ```
+   - **개발 중인 문서** (아직 머지 안 됨): **Feature 브랜치**
+     ```markdown
+     [파일명](https://github.com/{owner}/{repo}/blob/{feat-branch}/path/to/file)
+     ```
+
+2. **외부 문서 (공개 URL 있음)**: **절대 URL로 링크**
+
+   ```markdown
+   [react-i18next](https://react.i18next.com/)
+   ```
+
+3. **외부/로컬 문서** (docs 레포 등, URL 없음): **상대 경로 텍스트로만 표기**
+   ```text
+   ../docs/features/F001-feature-name/spec.md
+   ```
+
+> ⚠️ 로컬 문서는 GitHub에서 클릭되지 않으므로, 링크 대신 경로 텍스트만 제공합니다.
+
 ---
 
 ## 이슈 본문 템플릿
@@ -59,6 +86,24 @@ F{번호}: {기능명} ({짧은 설명})
 | `frontend`      | FE 관련       |
 | `priority:high` | 높은 우선순위 |
 
+> ⚠️ 라벨이 존재하지 않으면 먼저 생성합니다:
+>
+> ```bash
+> gh label create "라벨명" --description "설명" --color "색상코드"
+> ```
+
+---
+
+## Assignee 규칙
+
+- 기본값: 본인 할당 (`--assignee @me`)
+- 다른 담당자 지정 시 **사용자에게 확인** 후 진행
+- 예시:
+  ```bash
+  gh issue create --assignee @me ...
+  gh issue create --assignee username ...
+  ```
+
 ---
 
 ## 본문 입력 규칙 (셸 실행 방지)

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

@@ -14,7 +14,16 @@ feat(#{이슈번호}): {기능명}
 
 예: `feat(#1): 사용자 인증 구현`
 
----
+### 링크 형식 (중요!)
+
+PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을 사용**:
+
+```markdown
+[파일명](https://github.com/{owner}/{repo}/blob/{브랜치명}/docs/path/to/file.md)
+```
+
+> ⚠️ `main` 브랜치 링크는 머지 전까지 404가 발생합니다!
+> 반드시 **현재 피처 브랜치명** (예: `feat/5-feature-name`)을 사용하세요.
 
 ## PR 본문 템플릿
 
@@ -72,6 +81,27 @@ gh pr create \
 
 ---
 
+## 라벨 규칙
+
+- PR 생성 시 적절한 라벨 지정 (`--label`)
+- 라벨이 존재하지 않으면 먼저 생성:
+  ```bash
+  gh label create "라벨명" --description "설명" --color "색상코드"
+  ```
+
+---
+
+## Assignee 규칙
+
+- 기본값: 본인 할당 (`--assignee @me`)
+- 리뷰어 지정 시 `--reviewer` 옵션 사용
+- 예시:
+  ```bash
+  gh pr create --assignee @me --reviewer reviewer-username ...
+  ```
+
+---
+
 ## 본문 입력 규칙 (셸 실행 방지)
 
 - PR 본문은 **`--body-file` 사용을 기본**으로 한다.

package/templates/ko/fullstack/features/README.md

@@ -29,10 +29,10 @@ features/
 
 ```bash
 # Backend Feature
-lee-spec-kit feature --repo be user-auth
+npx lee-spec-kit feature --repo be user-auth
 
 # Frontend Feature
-lee-spec-kit feature --repo fe user-profile
+npx lee-spec-kit feature --repo fe user-profile
 ```
 
 > 💡 CLI는 `feature-base/`에서 템플릿을 복사하고 ID를 자동 채번합니다.
@@ -55,13 +55,13 @@ lee-spec-kit feature --repo fe user-profile
 Feature 진행 상태는 CLI로 한 번에 확인합니다.
 
 ```bash
-lee-spec-kit status
+npx lee-spec-kit status
 ```
 
 파일로 저장:
 
 ```bash
-lee-spec-kit status --write
+npx lee-spec-kit status --write
 ```
 
 ---

package/templates/ko/fullstack/features/be/README.md

@@ -2,4 +2,4 @@
 
 이 폴더에 Backend Feature들이 생성됩니다.
 
-`lee-spec-kit feature --repo be <name>` 명령어로 새 Feature를 생성하세요.
+`npx lee-spec-kit feature --repo be <name>` 명령어로 새 Feature를 생성하세요.

package/templates/ko/fullstack/features/fe/README.md

@@ -2,4 +2,4 @@
 
 이 폴더에 Frontend Feature들이 생성됩니다.
 
-`lee-spec-kit feature --repo fe <name>` 명령어로 새 Feature를 생성하세요.
+`npx lee-spec-kit feature --repo fe <name>` 명령어로 새 Feature를 생성하세요.

package/templates/ko/fullstack/features/feature-base/spec.md

@@ -17,6 +17,8 @@
 
 ## 목적
 
+{{description}}
+
 (이 기능이 왜 필요한지, 어떤 문제를 해결하는지)
 
 ---

package/templates/ko/fullstack/prd/README.md

@@ -2,6 +2,11 @@
 
 이 폴더에는 제품 요구사항 문서를 작성합니다.
 
+> **📌 문서 범위**
+>
+> - **이 폴더**: 제품 요구사항, 비즈니스 로직, 사용자 스토리
+> - **Constitution**: 기술 스택, 아키텍처 원칙, 코드 품질, 보안 원칙 → `agents/constitution.md`
+
 ## 작성 가이드
 
 1. 프로젝트 개요와 목표를 정의하세요

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

@@ -57,7 +57,7 @@ docs/
 
 ### 1. 새 기능 추가 요청
 
-1. 새 기능 폴더 생성: `lee-spec-kit feature <name>`
+1. 새 기능 폴더 생성: `npx lee-spec-kit feature <name>`
 2. `spec.md` 작성 - 무엇을, 왜 만드는지
 3. 사용자에게 스펙 초안 확인 요청
 4. GitHub Issue 생성
@@ -69,6 +69,14 @@ docs/
 3. 상태 전환: `[TODO]` → `[DOING]` → `[DONE]`
 4. 태스크 완료 직후 커밋
 
+### 3. 태스크 외 요청 처리
+
+> 사용자가 **tasks.md에 없는 작업**을 요청하면:
+
+1. 해당 작업을 **tasks.md에 반영할지** 사용자에게 확인
+2. 승인 시: tasks.md에 추가 후 실행
+3. 거부 시: 임시 작업으로 진행 (커밋에는 포함)
+
 ---
 
 ## 📋 ADR (Architecture Decision Records) 규칙

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

@@ -3,6 +3,11 @@
 프로젝트의 핵심 원칙과 기술 결정 가이드라인입니다.
 모든 개발 결정은 이 문서를 기준으로 합니다.
 
+> **📌 문서 범위**
+>
+> - **이 문서**: 기술 스택, 아키텍처 원칙, 코드 품질, 보안 원칙
+> - **PRD**: 제품 요구사항, 비즈니스 로직, 사용자 스토리 → `prd/*.md`
+
 ---
 
 ## 프로젝트 미션

package/templates/ko/single/agents/git-workflow.md

@@ -46,6 +46,8 @@ main
 
 ## 커밋 컨벤션
 
+> 📖 Type과 Description은 [Udacity Git Commit Message Style Guide](https://udacity.github.io/git-styleguide/)를 따릅니다.
+
 ### 형식
 
 ```
@@ -78,7 +80,19 @@ git checkout -b feat/{issue-number}-{feature-name}
 
 > `gh`로 이슈/PR 생성·수정 시 작성할 제목/본문/라벨을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
 
-### 2. 태스크 완료 시 자동 커밋
+### 2. 문서 작성 및 커밋
+
+| 문서         | 커밋 시점          | 커밋 메시지 예시         |
+| ------------ | ------------------ | ------------------------ |
+| spec.md      | 사용자 승인 후     | `docs(#123): spec 작성`  |
+| plan.md      | 사용자 승인 후     | `docs(#123): plan 작성`  |
+| tasks.md     | 사용자 승인 후     | `docs(#123): tasks 분해` |
+| decisions.md | 태스크 커밋에 포함 | (별도 커밋 없음)         |
+
+> 📌 **Feature 폴더 생성 시점**에는 커밋하지 않습니다.
+> 각 문서가 **사용자 승인**을 받은 후 개별 커밋합니다.
+
+### 3. 태스크 완료 시 자동 커밋
 
 태스크 하나가 완료되면:
 
@@ -89,7 +103,7 @@ git commit -m "{type}(#{issue}): {task-description}"
 
 > `git commit` 실행 전 커밋 메시지와 포함될 파일 목록을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
 
-### 3. Feature 완료 시 PR 생성
+### 4. Feature 완료 시 PR 생성
 
 모든 태스크 완료 시:
 
@@ -100,7 +114,7 @@ gh pr create --title "feat(#{issue}): {feature-title}" \
   --base main
 ```
 
-### 4. 머지
+### 5. 머지
 
 모든 리뷰 해결 시:
 

package/templates/ko/single/agents/issue-template.md

@@ -16,6 +16,33 @@ F{번호}: {기능명} ({짧은 설명})
 
 > "짧은 설명"은 한 줄로 의도를 전달할 수 있을 정도로만 작성합니다.
 
+### 링크 형식 (중요!)
+
+GitHub Issue에서 링크는 **파일 위치에 따라** 다르게 작성:
+
+1. **프로젝트 레포 내 파일**: 전체 URL 사용 (클릭 가능)
+   - **일반 문서/코드** (이미 머지됨): `main` 브랜치
+     ```markdown
+     [파일명](https://github.com/{owner}/{repo}/blob/main/path/to/file)
+     ```
+   - **개발 중인 문서** (아직 머지 안 됨): **Feature 브랜치**
+     ```markdown
+     [파일명](https://github.com/{owner}/{repo}/blob/{feat-branch}/path/to/file)
+     ```
+
+2. **외부 문서 (공개 URL 있음)**: **절대 URL로 링크**
+
+   ```markdown
+   [react-i18next](https://react.i18next.com/)
+   ```
+
+3. **외부/로컬 문서** (docs 레포 등, URL 없음): **상대 경로 텍스트로만 표기**
+   ```text
+   ../docs/features/F001-feature-name/spec.md
+   ```
+
+> ⚠️ 로컬 문서는 GitHub에서 클릭되지 않으므로, 링크 대신 경로 텍스트만 제공합니다.
+
 ---
 
 ## 이슈 본문 템플릿
@@ -59,6 +86,24 @@ F{번호}: {기능명} ({짧은 설명})
 | `frontend`      | FE 관련       |
 | `priority:high` | 높은 우선순위 |
 
+> ⚠️ 라벨이 존재하지 않으면 먼저 생성합니다:
+>
+> ```bash
+> gh label create "라벨명" --description "설명" --color "색상코드"
+> ```
+
+---
+
+## Assignee 규칙
+
+- 기본값: 본인 할당 (`--assignee @me`)
+- 다른 담당자 지정 시 **사용자에게 확인** 후 진행
+- 예시:
+  ```bash
+  gh issue create --assignee @me ...
+  gh issue create --assignee username ...
+  ```
+
 ---
 
 ## 본문 입력 규칙 (셸 실행 방지)

package/templates/ko/single/agents/pr-template.md

@@ -14,7 +14,16 @@ feat(#{이슈번호}): {기능명}
 
 예: `feat(#1): 사용자 인증 구현`
 
----
+### 링크 형식 (중요!)
+
+PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을 사용**:
+
+```markdown
+[파일명](https://github.com/{owner}/{repo}/blob/{브랜치명}/docs/path/to/file.md)
+```
+
+> ⚠️ `main` 브랜치 링크는 머지 전까지 404가 발생합니다!
+> 반드시 **현재 피처 브랜치명** (예: `feat/5-feature-name`)을 사용하세요.
 
 ## PR 본문 템플릿
 
@@ -72,6 +81,27 @@ gh pr create \
 
 ---
 
+## 라벨 규칙
+
+- PR 생성 시 적절한 라벨 지정 (`--label`)
+- 라벨이 존재하지 않으면 먼저 생성:
+  ```bash
+  gh label create "라벨명" --description "설명" --color "색상코드"
+  ```
+
+---
+
+## Assignee 규칙
+
+- 기본값: 본인 할당 (`--assignee @me`)
+- 리뷰어 지정 시 `--reviewer` 옵션 사용
+- 예시:
+  ```bash
+  gh pr create --assignee @me --reviewer reviewer-username ...
+  ```
+
+---
+
 ## 본문 입력 규칙 (셸 실행 방지)
 
 - PR 본문은 **`--body-file` 사용을 기본**으로 한다.

package/templates/ko/single/features/README.md

@@ -22,7 +22,7 @@ features/
 ## 새 기능 생성
 
 ```bash
-lee-spec-kit feature user-auth
+npx lee-spec-kit feature user-auth
 ```
 
 > 💡 CLI는 `feature-base/`에서 템플릿을 복사하고 ID를 자동 채번합니다.
@@ -41,7 +41,7 @@ lee-spec-kit feature user-auth
 ## 상태 확인
 
 ```bash
-lee-spec-kit status
+npx lee-spec-kit status
 ```
 
 ---

package/templates/ko/single/features/feature-base/spec.md

@@ -17,6 +17,8 @@
 
 ## 목적
 
+{{description}}
+
 (이 기능이 왜 필요한지, 어떤 문제를 해결하는지)
 
 ---

package/templates/ko/single/prd/README.md

@@ -2,6 +2,11 @@
 
 이 폴더에는 제품 요구사항 문서를 작성합니다.
 
+> **📌 문서 범위**
+>
+> - **이 폴더**: 제품 요구사항, 비즈니스 로직, 사용자 스토리
+> - **Constitution**: 기술 스택, 아키텍처 원칙, 코드 품질, 보안 원칙 → `agents/constitution.md`
+
 ## 작성 가이드
 
 1. 프로젝트 개요와 목표를 정의하세요