lee-spec-kit 0.1.8 → 0.2.1

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

@@ -1,170 +0,0 @@
-# Git Workflow Guide
-
-Rules for AI agents to automate Git/GitHub operations.
-
----
-
-## Core Concepts
-
-| 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    # 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       | 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 List
-
-| 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 Start
-
-```bash
-# 1. Create GitHub Issue (Feature = Issue)
-# 2. Create branch
-git checkout -b feat/{issue-number}-{feature-name}
-```
-
-> When creating/modifying issues/PRs with `gh`, share the title/body/labels first and **wait for user confirmation (OK)** before proceeding.
-
-### 2. Document Commit (docs repo)
-
-> 📌 The docs folder is managed as a separate git, so a separate commit strategy is used.
-
-| #   | Commit Timing                                            | Included Documents              | Commit Message Example          |
-| --- | -------------------------------------------------------- | ------------------------------- | ------------------------------- |
-| 1   | **When planning is complete** (spec+plan+tasks approved) | spec.md, plan.md, tasks.md      | `docs(#123): spec, plan, tasks` |
-| 2   | **When Feature is complete** (all tasks done)            | tasks.md (status), decisions.md | `docs(#123): Feature complete`  |
-
-> ⚠️ **Do not commit when creating Feature folder.**
-
-### 3. Auto Commit on Task Completion
-
-When a task is completed:
-
-```bash
-git add .
-git commit -m "{type}(#{issue}): {task-description}"
-```
-
-> Before running `git commit`, share the commit message and file list first and **wait for user confirmation (OK)** before proceeding.
-
-### 4. Create PR on Feature Completion
-
-When all tasks are completed:
-
-```bash
-git push origin feat/{issue-number}-{feature-name}
-gh pr create --title "feat(#{issue}): {feature-title}" \
-  --body "Closes #{issue}" \
-  --base main
-```
-
-### 5. Merge
-
-When all reviews are resolved:
-
-```bash
-# Update main before merge
-git checkout main
-git pull
-
-# Squash and Merge
-gh pr merge --squash --delete-branch
-
-# Update main after merge
-git pull
-```
-
----
-
-## Agent Automation Rules
-
-### On Task Completion
-
-```
-1. Complete code changes
-2. Update tasks.md status [DOING] → [DONE] (docs)
-3. git add .
-4. git commit -m "{type}(#{issue}): {description}"
-5. Proceed to next task
-```
-
-### On Feature Completion
-
-```
-1. Verify all tasks [DONE]
-2. git push origin {branch}
-3. gh pr create
-4. Wait for review
-5. Address review comments
-6. gh pr merge --squash
-```
-
----
-
-## GitHub Setup Requirements
-
-### Required
-
-- [ ] GitHub CLI (`gh`) installed and authenticated
-- [ ] Branch protection rules (main)
-  - Require PR before merging
-
-### Recommended
-
-- [ ] Auto-delete head branches
-- [ ] Squash merging only

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

@@ -1,80 +0,0 @@
-# {{projectName}} Constitution
-
-프로젝트의 핵심 원칙과 기술 결정 가이드라인입니다.
-모든 개발 결정은 이 문서를 기준으로 합니다.
-
-> **📌 문서 범위**
->
-> - **이 문서**: 기술 스택, 아키텍처 원칙, 코드 품질, 보안 원칙
-> - **PRD**: 제품 요구사항, 비즈니스 로직, 사용자 스토리 → `prd/*.md`
-
----
-
-## 프로젝트 미션
-
-> (프로젝트의 미션을 작성하세요)
-
----
-
-## 기술 스택
-
-### Backend
-
-| 기술         | 버전   | 이유        |
-| ------------ | ------ | ----------- |
-| (예: NestJS) | (버전) | (선택 이유) |
-
-### Frontend
-
-| 기술        | 버전   | 이유        |
-| ----------- | ------ | ----------- |
-| (예: React) | (버전) | (선택 이유) |
-
-### 공통
-
-| 기술              | 버전   | 이유        |
-| ----------------- | ------ | ----------- |
-| TypeScript        | strict | 타입 안전성 |
-| ESLint + Prettier | -      | 코드 품질   |
-| pnpm              | -      | 패키지 관리 |
-
----
-
-## 아키텍처 원칙
-
-### 1. Feature 중심 관리
-
-- 새 기능은 `docs/features/F00X/` 구조로 관리
-- FE/BE 분리하여 **기능 단위**로 개발
-- spec → plan → tasks → decisions 워크플로우
-
-### 2. (추가 원칙)
-
-(프로젝트별 아키텍처 원칙을 작성하세요)
-
----
-
-## 코드 품질 기준
-
-- TypeScript strict mode 필수
-- ESLint + Prettier 필수
-- 주요 비즈니스 로직 테스트 커버리지 **80%+**
-- 컴포넌트는 **단일 책임 원칙**
-- 중복 코드 최소화
-
----
-
-## 보안 원칙
-
-- 환경 변수로 시크릿 관리 (저장소 커밋 금지)
-- 사용자 데이터 **최소 수집**
-- CORS는 허용 오리진만 설정
-
----
-
-## 언어/코드 규칙
-
-- **답변**: 한국어
-- **코드/파일명**: 영어
-- **주석/커밋**: 한국어
-- **날짜/시간**: 사용자 PC 시스템 시간 기준 (예: `{{date}}`)

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

@@ -1,29 +0,0 @@
-# Custom Rules
-
-> ⚠️ 이 문서는 **사용자 정의 규칙**입니다.
-> `npx lee-spec-kit update`의 영향을 받지 않습니다.
-> **이 문서의 규칙은 다른 모든 agents 규칙보다 우선합니다.**
-
----
-
-## 프로젝트 특화 규칙
-
-(여기에 프로젝트만의 규칙을 작성하세요)
-
----
-
-## 추가 언어/코드 규칙
-
-(기본 규칙을 오버라이드하거나 추가 규칙을 작성하세요)
-
----
-
-## 커스텀 워크플로우
-
-(프로젝트만의 워크플로우가 있다면 작성하세요)
-
----
-
-## 기타
-
-(기타 규칙을 작성하세요)

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

@@ -1,170 +0,0 @@
-# Git 워크플로우 가이드
-
-에이전트가 Git/GitHub 작업을 자동화하기 위한 규칙입니다.
-
----
-
-## 핵심 개념
-
-| 개념      | GitHub 매핑  | 설명                    |
-| --------- | ------------ | ----------------------- |
-| Feature   | GitHub Issue | 기능 단위 작업          |
-| 태스크    | Commit       | 개별 구현 단위          |
-| 기능 완료 | Pull Request | Feature 완료 시 PR 생성 |
-
----
-
-## 브랜치 전략
-
-```
-main
- └── feat/123-feature-name    # Issue #123 기반 브랜치
-      ├── commit 1: feat(#123): 기능 구현
-      ├── commit 2: test(#123): 테스트 작성
-      └── commit 3: docs(#123): 문서 업데이트
-```
-
-### 브랜치 네이밍
-
-```
-{type}/{issue-number}-{feature-name}
-```
-
-| Type       | 설명      |
-| ---------- | --------- |
-| `feat`     | 새 기능   |
-| `fix`      | 버그 수정 |
-| `refactor` | 리팩토링  |
-| `docs`     | 문서      |
-
-**예시:**
-
-- `feat/123-user-auth`
-- `fix/456-login-error`
-
----
-
-## 커밋 컨벤션
-
-> 📖 Type과 Description은 [Udacity Git Commit Message Style Guide](https://udacity.github.io/git-styleguide/)를 따릅니다.
-
-### 형식
-
-```
-{type}(#{issue}): {description}
-```
-
-### Type 목록
-
-| Type       | 설명        | 예시                                |
-| ---------- | ----------- | ----------------------------------- |
-| `feat`     | 새 기능     | `feat(#123): 사용자 인증 구현`      |
-| `fix`      | 버그 수정   | `fix(#123): 로그인 오류 수정`       |
-| `refactor` | 리팩토링    | `refactor(#123): 인증 로직 분리`    |
-| `test`     | 테스트      | `test(#123): 인증 단위 테스트 추가` |
-| `docs`     | 문서        | `docs(#123): 스펙 명확화`           |
-| `style`    | 코드 스타일 | `style(#123): 린트 오류 수정`       |
-| `chore`    | 기타        | `chore(#123): 의존성 업데이트`      |
-
----
-
-## 자동화 워크플로우
-
-### 1. Feature 시작
-
-```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 생성
-
-모든 태스크 완료 시:
-
-```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
-```
-
----
-
-## 에이전트 자동화 규칙
-
-### 태스크 완료 시
-
-```
-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
-```
-
----
-
-## GitHub 설정 요구사항
-
-### 필수
-
-- [ ] GitHub CLI (`gh`) 설치 및 인증
-- [ ] Branch protection rules (main)
-  - Require PR before merging
-
-### 권장
-
-- [ ] Auto-delete head branches
-- [ ] Squash merging only

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

@@ -1,114 +0,0 @@
-# GitHub Issue 템플릿 가이드
-
-에이전트가 GitHub Issue를 생성할 때 참조하는 템플릿입니다.
-
----
-
-## 이슈 생성 규칙
-
-### 제목 형식
-
-```text
-F{번호}: {기능명} ({짧은 설명})
-```
-
-예: `F001: user-auth (사용자 인증 기능)`
-
-> "짧은 설명"은 한 줄로 의도를 전달할 수 있을 정도로만 작성합니다.
-
-### 링크 형식 (중요!)
-
-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에서 클릭되지 않으므로, 링크 대신 경로 텍스트만 제공합니다.
-
----
-
-## 이슈 본문 템플릿
-
-```markdown
-## 개요
-
-{기능에 대한 간략한 설명}
-
-## 목표
-
-- {목표 1}
-- {목표 2}
-
-## 완료 조건
-
-- [ ] {조건 1}
-- [ ] {조건 2}
-
-## 관련 문서
-
-- Spec: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
-
-## 라벨
-
-- `enhancement` (새 기능)
-- `bug` (버그 수정)
-- `documentation` (문서)
-```
-
----
-
-## 라벨 규칙
-
-| 라벨            | 용도          |
-| --------------- | ------------- |
-| `enhancement`   | 새 기능       |
-| `bug`           | 버그 수정     |
-| `documentation` | 문서 작업     |
-| `backend`       | BE 관련       |
-| `frontend`      | FE 관련       |
-| `priority:high` | 높은 우선순위 |
-
-> ⚠️ 라벨이 존재하지 않으면 먼저 생성합니다:
->
-> ```bash
-> gh label create "라벨명" --description "설명" --color "색상코드"
-> ```
-
----
-
-## Assignee 규칙
-
-- 기본값: 본인 할당 (`--assignee @me`)
-- 다른 담당자 지정 시 **사용자에게 확인** 후 진행
-- 예시:
-  ```bash
-  gh issue create --assignee @me ...
-  gh issue create --assignee username ...
-  ```
-
----
-
-## 본문 입력 규칙 (셸 실행 방지)
-
-- 이슈 본문은 **`--body-file` 사용을 기본**으로 한다.
-- 백틱(`)이나 `$()`가 포함된 본문을 `"..."`에 직접 넣으면 **셸에서 명령치환**될 수 있다.
-- 여러 줄 본문은 `cat <<'EOF'` 형식의 **싱글 쿼트 heredoc**을 사용하고,
-  필요한 변수는 **플레이스홀더 → sed 치환**으로 처리한다.

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

@@ -1,110 +0,0 @@
-# GitHub PR 템플릿 가이드
-
-에이전트가 Pull Request를 생성할 때 참조하는 템플릿입니다.
-
----
-
-## PR 생성 규칙
-
-### 제목 형식
-
-```text
-feat(#{이슈번호}): {기능명}
-```
-
-예: `feat(#1): 사용자 인증 구현`
-
-### 링크 형식 (중요!)
-
-PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을 사용**:
-
-```markdown
-[파일명](https://github.com/{owner}/{repo}/blob/{브랜치명}/docs/path/to/file.md)
-```
-
-> ⚠️ `main` 브랜치 링크는 머지 전까지 404가 발생합니다!
-> 반드시 **현재 피처 브랜치명** (예: `feat/5-feature-name`)을 사용하세요.
-
-## PR 본문 템플릿
-
-```markdown
-## 개요
-
-{변경 사항에 대한 간략한 설명}
-
-## 변경 사항
-
-- {변경 1}
-- {변경 2}
-- {변경 3}
-
-## 테스트
-
-- [ ] 유닛 테스트 통과
-- [ ] 통합 테스트 완료
-
-## 스크린샷 (UI 변경 시)
-
-{있으면 첨부}
-
-## 관련 문서
-
-- Spec: `docs/features/{be|fe}/F{번호}-{기능명}/spec.md`
-- Tasks: `docs/features/{be|fe}/F{번호}-{기능명}/tasks.md`
-
-Closes #{이슈번호}
-```
-
----
-
-## PR 생성 명령어
-
-```bash
-# 현재 브랜치명 확인
-BRANCH=$(git branch --show-current)
-
-gh pr create \
-  --title "feat(#{issue}): {기능명}" \
-  --body-file /tmp/pr-body.md \
-  --base main
-```
-
----
-
-## 머지 규칙
-
-| 상황         | 머지 방식         |
-| ------------ | ----------------- |
-| 일반 Feature | Squash and Merge  |
-| 긴급 Hotfix  | Merge 또는 Rebase |
-| 문서 수정    | Squash and Merge  |
-
----
-
-## 라벨 규칙
-
-- PR 생성 시 적절한 라벨 지정 (`--label`)
-- 라벨이 존재하지 않으면 먼저 생성:
-  ```bash
-  gh label create "라벨명" --description "설명" --color "색상코드"
-  ```
-
----
-
-## Assignee 규칙
-
-- 기본값: 본인 할당 (`--assignee @me`)
-- 리뷰어 지정 시 `--reviewer` 옵션 사용
-- 예시:
-  ```bash
-  gh pr create --assignee @me --reviewer reviewer-username ...
-  ```
-
----
-
-## 본문 입력 규칙 (셸 실행 방지)
-
-- PR 본문은 **`--body-file` 사용을 기본**으로 한다.
-- 백틱(`)이나 `$()`가 포함된 본문을 `"..."`에 직접 넣으면 **셸에서 명령치환**될 수 있다.
-- 여러 줄 본문은 `cat <<'EOF'` 형식의 **싱글 쿼트 heredoc**을 사용하고,
-  필요한 변수는 **플레이스홀더 → sed 치환**으로 처리한다.