lee-spec-kit 0.1.2 → 0.1.5

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

@@ -1,75 +1,80 @@
 # {{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
 
-| 기술         | 버전   | 이유        |
-| ------------ | ------ | ----------- |
-| (예: NestJS) | (버전) | (선택 이유) |
+| Tech          | Version   | Reason   |
+| ------------- | --------- | -------- |
+| (e.g. NestJS) | (version) | (reason) |
 
 ### Frontend
 
-| 기술        | 버전   | 이유        |
-| ----------- | ------ | ----------- |
-| (예: React) | (버전) | (선택 이유) |
+| Tech         | Version   | Reason   |
+| ------------ | --------- | -------- |
+| (e.g. React) | (version) | (reason) |
 
-### 공통
+### Common
 
-| 기술              | 버전   | 이유        |
-| ----------------- | ------ | ----------- |
-| TypeScript        | strict | 타입 안전성 |
-| ESLint + Prettier | -      | 코드 품질   |
-| pnpm              | -      | 패키지 관리 |
+| Tech              | Version | Reason       |
+| ----------------- | ------- | ------------ |
+| TypeScript        | strict  | Type safety  |
+| ESLint + Prettier | -       | Code quality |
+| pnpm              | -       | Package mgmt |
 
 ---
 
-## 아키텍처 원칙
+## Architecture Principles
 
-### 1. Feature 중심 관리
+### 1. Feature-Centric Management
 
-- 새 기능은 `docs/features/F00X/` 구조로 관리
-- FE/BE 분리하여 **기능 단위**로 개발
-- spec → plan → tasks → decisions 워크플로우
+- Manage new features in `docs/features/F00X/` structure
+- Develop by **feature unit** (FE/BE separate)
+- spec → plan → tasks → decisions workflow
 
-### 2. (추가 원칙)
+### 2. (Additional Principles)
 
-(프로젝트별 아키텍처 원칙을 작성하세요)
+(Write project-specific architecture principles here)
 
 ---
 
-## 코드 품질 기준
+## Code Quality Standards
 
-- TypeScript strict mode 필수
-- ESLint + Prettier 필수
-- 주요 비즈니스 로직 테스트 커버리지 **80%+**
-- 컴포넌트는 **단일 책임 원칙**
-- 중복 코드 최소화
+- TypeScript strict mode required
+- ESLint + Prettier required
+- Major business logic test coverage **80%+**
+- Components follow **Single Responsibility Principle**
+- Minimize code duplication
 
 ---
 
-## 보안 원칙
+## Security Principles
 
-- 환경 변수로 시크릿 관리 (저장소 커밋 금지)
-- 사용자 데이터 **최소 수집**
-- CORS는 허용 오리진만 설정
+- Manage secrets via environment variables (no repo commits)
+- **Minimal data collection** for user data
+- CORS only for allowed origins
 
 ---
 
-## 언어/코드 규칙
+## Language/Code Rules
 
-- **답변**: 한국어
-- **코드/파일명**: 영어
-- **주석/커밋**: 한국어
-- **날짜/시간**: 사용자 PC 시스템 시간 기준 (예: `{{date}}`)
+- **Responses**: English
+- **Code/Filenames**: English
+- **Comments/Commits**: English
+- **Date/Time**: User's local system time (e.g., `{{date}}`)

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

@@ -1,97 +1,99 @@
-# Git 워크플로우 가이드
+# Git Workflow Guide
 
-에이전트가 Git/GitHub 작업을 자동화하기 위한 규칙입니다.
+Rules for AI agents to automate Git/GitHub operations.
 
 ---
 
-## 핵심 개념
+## Core Concepts
 
-| 개념      | GitHub 매핑  | 설명                    |
-| --------- | ------------ | ----------------------- |
-| Feature   | GitHub Issue | 기능 단위 작업          |
-| 태스크    | Commit       | 개별 구현 단위          |
-| 기능 완료 | Pull Request | Feature 완료 시 PR 생성 |
+| Concept          | GitHub Mapping | Description                     |
+| ---------------- | -------------- | ------------------------------- |
+| Feature          | GitHub Issue   | Feature-level work unit         |
+| Task             | Commit         | Individual implementation unit  |
+| Feature Complete | Pull Request   | Create PR on feature completion |
 
 ---
 
-## 브랜치 전략
+## Branch Strategy
 
 ```
 main
- └── feat/123-feature-name    # Issue #123 기반 브랜치
-      ├── commit 1: feat(#123): 기능 구현
-      ├── commit 2: test(#123): 테스트 작성
-      └── commit 3: docs(#123): 문서 업데이트
+ └── feat/123-feature-name    # Branch based on Issue #123
+      ├── commit 1: feat(#123): implement feature
+      ├── commit 2: test(#123): add tests
+      └── commit 3: docs(#123): update docs
 ```
 
-### 브랜치 네이밍
+### Branch Naming
 
 ```
 {type}/{issue-number}-{feature-name}
 ```
 
-| Type       | 설명      |
-| ---------- | --------- |
-| `feat`     | 새 기능   |
-| `fix`      | 버그 수정 |
-| `refactor` | 리팩토링  |
-| `docs`     | 문서      |
+| Type       | Description   |
+| ---------- | ------------- |
+| `feat`     | New feature   |
+| `fix`      | Bug fix       |
+| `refactor` | Refactoring   |
+| `docs`     | Documentation |
 
-**예시:**
+**Examples:**
 
 - `feat/123-user-auth`
 - `fix/456-login-error`
 
 ---
 
-## 커밋 컨벤션
+## Commit Convention
 
-### 형식
+> 📖 Type and Description follow [Udacity Git Commit Message Style Guide](https://udacity.github.io/git-styleguide/).
+
+### Format
 
 ```
 {type}(#{issue}): {description}
 ```
 
-### Type 목록
+### Type List
 
-| Type       | 설명        | 예시                                |
-| ---------- | ----------- | ----------------------------------- |
-| `feat`     | 새 기능     | `feat(#123): 사용자 인증 구현`      |
-| `fix`      | 버그 수정   | `fix(#123): 로그인 오류 수정`       |
-| `refactor` | 리팩토링    | `refactor(#123): 인증 로직 분리`    |
-| `test`     | 테스트      | `test(#123): 인증 단위 테스트 추가` |
-| `docs`     | 문서        | `docs(#123): 스펙 명확화`           |
-| `style`    | 코드 스타일 | `style(#123): 린트 오류 수정`       |
-| `chore`    | 기타        | `chore(#123): 의존성 업데이트`      |
+| Type       | Description   | Example                               |
+| ---------- | ------------- | ------------------------------------- |
+| `feat`     | New feature   | `feat(#123): implement user auth`     |
+| `fix`      | Bug fix       | `fix(#123): fix login error`          |
+| `refactor` | Refactoring   | `refactor(#123): separate auth logic` |
+| `test`     | Tests         | `test(#123): add auth unit tests`     |
+| `docs`     | Documentation | `docs(#123): clarify spec`            |
+| `style`    | Code style    | `style(#123): fix lint errors`        |
+| `chore`    | Other         | `chore(#123): update dependencies`    |
 
 ---
 
-## 자동화 워크플로우
+## Automation Workflow
 
-### 1. Feature 시작
+### 1. Feature Start
 
 ```bash
-# 1. GitHub Issue 생성 (Feature = Issue)
-# 2. 브랜치 생성
+# 1. Create GitHub Issue (Feature = Issue)
+# 2. Create branch
 git checkout -b feat/{issue-number}-{feature-name}
 ```
 
-> `gh`로 이슈/PR 생성·수정 시 작성할 제목/본문/라벨을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
+> When creating/modifying issues/PRs with `gh`, share the title/body/labels first and **wait for user confirmation (OK)** before proceeding.
 
-### 2. 태스크 완료 시 자동 커밋
+### 2. Auto Commit on Task Completion
 
-태스크 하나가 완료되면:
+When a task is completed:
 
 ```bash
 git add .
 git commit -m "{type}(#{issue}): {task-description}"
 ```
 
-> `git commit` 실행 전 커밋 메시지와 포함될 파일 목록을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
+> Before running `git commit`, share the commit message and file list first and **wait for user confirmation (OK)** before proceeding.
 
-### 3. Feature 완료 시 PR 생성
+### 3. Create PR on Feature Completion
 
-모든 태스크 완료 시:
+When all tasks are completed:
 
 ```bash
 git push origin feat/{issue-number}-{feature-name}
@@ -100,58 +102,58 @@ gh pr create --title "feat(#{issue}): {feature-title}" \
   --base main
 ```
 
-### 4. 머지
+### 4. Merge
 
-모든 리뷰 해결 시:
+When all reviews are resolved:
 
 ```bash
-# 머지 전 main 최신화
+# Update main before merge
 git checkout main
 git pull
 
 # Squash and Merge
 gh pr merge --squash --delete-branch
 
-# 머지 후 main 최신화
+# Update main after merge
 git pull
 ```
 
 ---
 
-## 에이전트 자동화 규칙
+## Agent Automation Rules
 
-### 태스크 완료 시
+### On Task Completion
 
 ```
-1. 코드 변경 완료
-2. tasks.md 상태 [DOING] → [DONE] 업데이트 (docs)
+1. Complete code changes
+2. Update tasks.md status [DOING] → [DONE] (docs)
 3. git add .
 4. git commit -m "{type}(#{issue}): {description}"
-5. 다음 태스크 진행
+5. Proceed to next task
 ```
 
-### Feature 완료 시
+### On Feature Completion
 
 ```
-1. 모든 태스크 [DONE] 확인
+1. Verify all tasks [DONE]
 2. git push origin {branch}
 3. gh pr create
-4. 리뷰 대기
-5. 리뷰 코멘트 수정
+4. Wait for review
+5. Address review comments
 6. gh pr merge --squash
 ```
 
 ---
 
-## GitHub 설정 요구사항
+## GitHub Setup Requirements
 
-### 필수
+### Required
 
-- [ ] GitHub CLI (`gh`) 설치 및 인증
+- [ ] GitHub CLI (`gh`) installed and authenticated
 - [ ] Branch protection rules (main)
   - Require PR before merging
 
-### 권장
+### Recommended
 
 - [ ] Auto-delete head branches
 - [ ] Squash merging only

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

@@ -1,60 +1,96 @@
-# GitHub Issue 템플릿 가이드
+# GitHub Issue Template Guide
 
-에이전트가 GitHub Issue를 생성할 때 참조하는 템플릿입니다.
+A template for AI agents to create GitHub Issues.
 
 ---
 
-## 이슈 생성 규칙
+## Issue Creation Rules
 
-### 제목 형식
+### Title Format
 
 ```text
-F{번호}: {기능명} ({짧은 설명})
+F{number}: {feature-name} ({short description})
 ```
 
-예: `F001: user-auth (사용자 인증 기능)`
+Example: `F001: user-auth (User authentication feature)`
 
-> "짧은 설명"은 한 줄로 의도를 전달할 수 있을 정도로만 작성합니다.
+> Keep the "short description" concise enough to convey the intent in one line.
+
+### 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
 
-- {목표 1}
-- {목표 2}
+- {Goal 1}
+- {Goal 2}
 
-## 완료 조건
+## Completion Criteria
 
-- [ ] {조건 1}
-- [ ] {조건 2}
+- [ ] {Criterion 1}
+- [ ] {Criterion 2}
 
-## 관련 문서
+## Related Documents
 
-- Spec: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
+- Spec: `docs/features/F{number}-{feature-name}/spec.md`
 
-## 라벨
+## Labels
 
-- `enhancement` (새 기능)
-- `bug` (버그 수정)
-- `documentation` (문서)
+- `enhancement` (New feature)
+- `bug` (Bug fix)
+- `documentation` (Documentation)
 ```
 
 ---
 
-## 라벨 규칙
+## Label Rules
 
-| 라벨            | 용도          |
+| Label           | Usage         |
 | --------------- | ------------- |
-| `enhancement`   | 새 기능       |
-| `bug`           | 버그 수정     |
-| `documentation` | 문서 작업     |
-| `backend`       | BE 관련       |
-| `frontend`      | FE 관련       |
-| `priority:high` | 높은 우선순위 |
+| `enhancement`   | New feature   |
+| `bug`           | Bug fix       |
+| `documentation` | Documentation |
+| `backend`       | BE related    |
+| `frontend`      | FE related    |
+| `priority:high` | High priority |
+
+---
+
+## 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/single/agents/pr-template.md

@@ -1,71 +1,91 @@
-# GitHub PR 템플릿 가이드
+# GitHub PR Template Guide
 
-에이전트가 Pull Request를 생성할 때 참조하는 템플릿입니다.
+A template for AI agents to create Pull Requests.
 
 ---
 
-## PR 생성 규칙
+## PR Creation Rules
 
-### 제목 형식
+### Title Format
 
 ```text
-feat(#{이슈번호}): {기능명}
+feat(#{issue-number}): {feature-name}
 ```
 
-예: `feat(#1): 사용자 인증 구현`
+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 본문 템플릿
+## PR Body Template
 
 ```markdown
-## 개요
+## Overview
 
-{변경 사항에 대한 간략한 설명}
+{Brief description of changes}
 
-## 변경 사항
+## Changes
 
-- {변경 1}
-- {변경 2}
-- {변경 3}
+- {Change 1}
+- {Change 2}
+- {Change 3}
 
-## 테스트
+## Tests
 
-- [ ] 유닛 테스트 통과
-- [ ] 통합 테스트 완료
+- [ ] Unit tests passed
+- [ ] Integration tests completed
 
-## 스크린샷 (UI 변경 시)
+## Screenshots (for UI changes)
 
-{있으면 첨부}
+{Attach if applicable}
 
-## 관련 문서
+## Related Documents
 
-- Spec: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
-- Tasks: `docs/features/{be|fe}/F{번호}-{기능명}/tasks.md`
+- Spec: `docs/features/F{number}-{feature-name}/spec.md`
+- Tasks: `docs/features/F{number}-{feature-name}/tasks.md`
 
-Closes #{이슈번호}
+Closes #{issue-number}
 ```
 
 ---
 
-## PR 생성 명령어
+## PR Creation Command
 
 ```bash
-# 현재 브랜치명 확인
+# Check current branch name
 BRANCH=$(git branch --show-current)
 
 gh pr create \
-  --title "feat(#{issue}): {기능명}" \
+  --title "feat(#{issue}): {feature-name}" \
   --body-file /tmp/pr-body.md \
   --base main
 ```
 
 ---
 
-## 머지 규칙
+## Merge Rules
+
+| Situation      | Merge Method     |
+| -------------- | ---------------- |
+| Normal Feature | Squash and Merge |
+| Urgent Hotfix  | Merge or Rebase  |
+| Docs update    | Squash and Merge |
+
+---
+
+## Body Input Rules (Shell Execution Prevention)
 
-| 상황         | 머지 방식         |
-| ------------ | ----------------- |
-| 일반 Feature | Squash and Merge  |
-| 긴급 Hotfix  | Merge 또는 Rebase |
-| 문서 수정    | Squash and Merge  |
+- 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**.

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
 

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: