lee-spec-kit 0.1.0

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

@@ -0,0 +1,125 @@
+# Agents Guide
+
+코드 어시스턴트/에이전트가 일관된 코드 생성·리팩토링을 수행하도록 돕는 운영 규칙입니다.
+
+---
+
+## 참조 문서
+
+### 핵심 문서
+
+- **프로젝트 원칙**: `/docs/agents/constitution.md`
+- **Git 워크플로우**: `/docs/agents/git-workflow.md`
+- **이슈 템플릿**: `/docs/agents/issue-template.md`
+- **PR 템플릿**: `/docs/agents/pr-template.md`
+
+### PRD
+
+- **제품 요구사항**: `/docs/prd/`
+
+### Feature (기능별 문서)
+
+- **BE 기능**: `/docs/features/be/{feature-id}/`
+- **FE 기능**: `/docs/features/fe/{feature-id}/`
+- **템플릿 (SSOT)**: `/docs/features/feature-base/` (spec, plan, tasks, decisions)
+
+---
+
+## 📁 docs 표준 구조
+
+```
+docs/
+├── README.md           # 문서 안내
+├── agents/             # 에이전트 운영 규칙
+│   ├── agents.md       # 메인 규칙 (이 파일)
+│   ├── constitution.md # 프로젝트 원칙
+│   ├── git-workflow.md # Git 자동화
+│   ├── issue-template.md
+│   └── pr-template.md
+├── prd/                # 제품 요구사항
+├── features/           # 기능별 문서
+│   ├── be/             # Backend Features
+│   │   └── F00X-{name}/
+│   └── fe/             # Frontend Features
+│       └── F00X-{name}/
+└── scripts/            # 유틸리티
+```
+
+### 규칙
+
+- **기술 결정**: Feature의 `decisions.md`에 기록 (ADR 스타일)
+
+---
+
+## 언어/코드 규칙
+
+- 답변: 한국어
+- 코드/파일명: 영어
+- 주석/커밋메시지: 한국어
+- Issue/PR 제목·본문: 한국어
+- **날짜/시간: 사용자 PC의 시스템 시간 사용** (예: `2025-12-27`)
+
+---
+
+## 요청 유형별 프로세스
+
+### 1. 새 기능 추가 요청
+
+1. 대상 레포 확인 (BE 또는 FE)
+2. 새 기능 폴더 생성: `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. 변경 필요시 새 기능/태스크 생성 권장
+
+---
+
+## 📋 ADR (Architecture Decision Records) 규칙
+
+> `decisions.md`는 기술 결정과 그 이유를 기록하는 **필수** 문서입니다.
+
+### 언제 기록하는가?
+
+1. **기술/라이브러리 선택 시** (예: Prisma vs TypeORM)
+2. **아키텍처 결정 시** (예: 단일 테이블 + JSON vs 정규화)
+3. **설계 트레이드오프 시** (예: 성능 vs 가독성)
+4. **코드 리뷰 피드백 반영 시**
+5. **문제 해결 시** (예: 에러 핸들링 방식 변경)
+
+### 기록 형식
+
+```markdown
+## D{번호}: {결정 제목} ({YYYY-MM-DD})
+
+- **Context**: 문제 상황 또는 배경
+- **Options**: 고려한 대안들
+- **Decision**: 최종 선택
+- **Rationale**: 선택 이유
+- **Consequences**: 결과 및 영향 (선택사항)
+```
+
+### 에이전트 행동 규칙
+
+- 태스크 진행 중 **기술 결정이 발생하면 즉시 `decisions.md`에 기록**
+- 코드 리뷰 피드백으로 **접근 방식이 변경되면 새 결정으로 추가**
+- **암묵적인 결정도 명시적으로 기록**

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

@@ -0,0 +1,75 @@
+# {{projectName}} Constitution
+
+프로젝트의 핵심 원칙과 기술 결정 가이드라인입니다.
+모든 개발 결정은 이 문서를 기준으로 합니다.
+
+---
+
+## 프로젝트 미션
+
+> (프로젝트의 미션을 작성하세요)
+
+---
+
+## 기술 스택
+
+### 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/fullstack/agents/git-workflow.md

@@ -0,0 +1,157 @@
+# 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}(#{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. 태스크 완료 시 자동 커밋
+
+태스크 하나가 완료되면:
+
+```bash
+git add .
+git commit -m "{type}(#{issue}): {task-description}"
+```
+
+> `git commit` 실행 전 커밋 메시지와 포함될 파일 목록을 먼저 공유하고 **반드시** 사용자 확인(OK) 후 진행합니다.
+
+### 3. Feature 완료 시 PR 생성
+
+모든 태스크 완료 시:
+
+```bash
+git push origin feat/{issue-number}-{feature-name}
+gh pr create --title "feat(#{issue}): {feature-title}" \
+  --body "Closes #{issue}" \
+  --base main
+```
+
+### 4. 머지
+
+모든 리뷰 해결 시:
+
+```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/fullstack/agents/issue-template.md

@@ -0,0 +1,60 @@
+# GitHub Issue 템플릿 가이드
+
+에이전트가 GitHub Issue를 생성할 때 참조하는 템플릿입니다.
+
+---
+
+## 이슈 생성 규칙
+
+### 제목 형식
+
+```text
+F{번호}: {기능명} ({짧은 설명})
+```
+
+예: `F001: user-auth (사용자 인증 기능)`
+
+> "짧은 설명"은 한 줄로 의도를 전달할 수 있을 정도로만 작성합니다.
+
+---
+
+## 이슈 본문 템플릿
+
+```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` | 높은 우선순위 |

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

@@ -0,0 +1,71 @@
+# GitHub PR 템플릿 가이드
+
+에이전트가 Pull Request를 생성할 때 참조하는 템플릿입니다.
+
+---
+
+## PR 생성 규칙
+
+### 제목 형식
+
+```text
+feat(#{이슈번호}): {기능명}
+```
+
+예: `feat(#1): 사용자 인증 구현`
+
+---
+
+## 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  |

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

@@ -0,0 +1,98 @@
+# Features 가이드
+
+기능별 스펙, 계획, 태스크를 관리하는 폴더입니다.
+**FE/BE 레포가 분리되어 있으므로 Feature도 분리하여 관리합니다.**
+
+---
+
+## 폴더 구조
+
+```
+features/
+├── README.md           # 이 파일
+├── feature-base/       # 공용 템플릿 (수정 시 한 곳만 수정)
+│   ├── spec.md
+│   ├── plan.md
+│   ├── tasks.md
+│   └── decisions.md
+├── be/                 # Backend Features
+│   └── F00X-{name}/
+└── fe/                 # Frontend Features
+    └── F00X-{name}/
+```
+
+---
+
+## 새 기능 생성
+
+### CLI 사용 (권장)
+
+```bash
+# Backend Feature
+lee-spec-kit feature --repo be user-auth
+
+# Frontend Feature
+lee-spec-kit feature --repo fe user-profile
+```
+
+> 💡 CLI는 `feature-base/`에서 템플릿을 복사하고 ID를 자동 채번합니다.
+
+---
+
+## 기능 ID 규칙
+
+- `F{번호}-{기능명}` (예: F001-user-auth)
+- 번호는 **최소 3자리 패딩** (001, 002, ...)
+- 999를 초과하면 **4자리 이상으로 확장** (F1000, F1001, ...)
+- 기능명은 kebab-case
+- **BE/FE 공통으로 번호는 전역 유일** (중복 사용 금지)
+- **Feature = Issue**: 각 Feature는 하나의 GitHub Issue에 대응됩니다.
+
+---
+
+## 상태 확인
+
+Feature 진행 상태는 CLI로 한 번에 확인합니다.
+
+```bash
+lee-spec-kit status
+```
+
+파일로 저장:
+
+```bash
+lee-spec-kit status --write
+```
+
+---
+
+## 각 파일 역할
+
+| 파일           | 역할                       | 작성 시점      |
+| -------------- | -------------------------- | -------------- |
+| `spec.md`      | **무엇을, 왜** 만드는지    | 기능 정의 시   |
+| `plan.md`      | **어떻게** 만드는지 (기술) | 스펙 승인 후   |
+| `tasks.md`     | 구체적인 작업 목록         | 계획 승인 후   |
+| `decisions.md` | 기술 결정 기록 (ADR)       | 개발 중 수시로 |
+
+---
+
+## 워크플로우
+
+### BE 작업
+
+```
+1. docs/features/be/FXXX-{name}/ 생성
+2. spec.md → plan.md → tasks.md 작성
+3. GitHub Issue 생성
+4. 구현 → Commit → PR
+```
+
+### FE 작업
+
+```
+1. docs/features/fe/FXXX-{name}/ 생성
+2. spec.md → plan.md → tasks.md 작성
+3. GitHub Issue 생성
+4. 구현 → Commit → PR
+```

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

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

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

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

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

@@ -0,0 +1,15 @@
+# Decisions Log
+
+기술 결정과 그 이유를 기록합니다.
+
+> 형식: `D{번호}: {결정 제목} ({YYYY-MM-DD})`
+
+---
+
+## D001: {결정 제목} ({YYYY-MM-DD})
+
+- **Context**: 문제 상황 또는 배경
+- **Options**: 고려한 대안들
+- **Decision**: 최종 선택
+- **Rationale**: 선택 이유
+- **Consequences**: 결과 및 영향 (선택사항)

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

@@ -0,0 +1,49 @@
+# Implementation Plan: {기능명}
+
+> 스펙이 승인된 후 작성합니다.
+
+---
+
+## 개요
+
+- **기능 ID**: F{번호}
+- **대상 레포**: {{projectName}}-{be|fe}
+- **작성일**: YYYY-MM-DD
+- **상태**: Draft | Review | Approved
+
+---
+
+## 기술 스택
+
+| 구분 | 선택 | 이유 |
+| ---- | ---- | ---- |
+
+---
+
+## 아키텍처
+
+(컴포넌트 구조, 데이터 흐름)
+
+---
+
+## 파일 구조
+
+```
+src/
+├── ...
+```
+
+---
+
+## 테스트 전략
+
+- **단위 테스트**:
+- **통합 테스트**:
+- **E2E 테스트**:
+
+---
+
+## 관련 문서
+
+- Spec: [spec.md](./spec.md)
+- Decisions: [decisions.md](./decisions.md)