Dev Plan
Overview
프로젝트를 분석하고, 범위를 고정하며, 페이즈별 체크박스 태스크 + 테스트 케이스가 포함된 구현 계획서를 생성한다.
Inputs
$goal: 구현할 기능 또는 프로젝트 목표 설명
Process
Step 1: 프로젝트 분석
질문하기 전에 먼저 프로젝트를 분석한다:
- 프로젝트 설정 파악:
CLAUDE.md, README.md, package.json, pyproject.toml, go.mod, Cargo.toml 등 루트 설정 파일을 읽는다.
- 프로젝트 문서 탐색: Glob으로
.md 파일을 탐색하여 PRD, TRD, ADR, RFC, 기존 계획서 등 핵심 문서를 식별하고 읽는다.
- 소스 구조 매핑: Glob으로 디렉토리 레이아웃을 파악한다 (
src/**, lib/**, app/** 등).
- 컨벤션 식별: 테스트 디렉토리, 린팅 설정, 빌드 설정, CI 파이프라인을 찾는다.
- 관련 코드 탐색:
$goal이 기존 기능을 참조하면, Grep으로 관련 모듈, 인터페이스, 타입을 찾는다.
Step 2: 요구사항 확인
$goal이 모호하거나 부족한 경우에만 핵심 질문을 한다:
- 범위 경계는? (명시적으로 제외되는 것은?)
- 하드 제약 조건은? (성능 목표, 하위 호환성, 특정 API 사용)
- 선호하는 아키텍처/패턴이 있는가?
- 테스트 전략은? (유닛, 통합, E2E?)
중요: 과도한 질문 금지. 코드베이스 분석으로 충분한 컨텍스트를 얻었으면 바로 진행한다.
Step 3: 아키텍처 설계
- 필요한 핵심 추상화 식별 (인터페이스, 타입, 모듈)
- 데이터 흐름 매핑 (입력 → 변환 → 출력)
- 기존 코드와의 통합점 식별
- 병렬화 가능한 것 파악 (독립 모듈)
- 순차적이어야 하는 것 파악 (컴포넌트 간 의존성)
Step 4: 계획서 생성
references/dev-plan-template.md 템플릿을 따라 작성한다. 필수 섹션:
- Context (Why / Current State / Target State / Scope Boundary)
- Architecture Overview (Diagram / Design Decisions / New Files / Modified Files)
- Phase Dependencies
- Implementation Phases (Tasks + Success Criteria + Test Cases + Testing Instructions)
- Integration & Verification
- Edge Cases & Risks
- Execution Rules
Step 5: 엔지니어링 리뷰
계획서 생성 후, 구현 전에 리뷰를 수행한다:
- 자체 검증: 계획서를
code-review 스킬의 Plan mode 기준으로 자체 점검한다.
- 아키텍처 정합성, 소유권 경계, 엣지케이스, 보안, 테스트 전략
- Engineering Review 섹션 추가: 계획서에 다음 테이블을 포함한다:
## Engineering Review
| 항목 | 판정 | 메모 |
|---|---|---|
| 아키텍처 | ready / needs revision / blocked | ... |
| 공유 계약 | ready / needs revision / blocked | ... |
| 엣지케이스 | ready / needs revision / blocked | ... |
| 테스트 전략 | ready / needs revision / blocked | ... |
- 심층 리뷰 필요 시: 사용자에게
/code-review [plan-file-path]로 별도 리뷰를 안내한다.
Step 6: 저장 및 보고
- 프로젝트에
docs/ 디렉토리가 있으면 → docs/impl-plan-[feature-name].md
- 없으면 → 프로젝트 루트에
impl-plan-[feature-name].md
- 결과 보고: 저장 위치, 총 Phase 수, 병렬 가능 Phase, 예상 범위
Quality Rules
태스크 구체성
- 모든 태스크에 정확한 파일 경로와 함수/컴포넌트명 명시
- "인증 모듈 구현" (X) → "
src/services/auth/oauth-client.ts에 exchangeCodeForToken() 함수 구현" (O)
페이즈 크기 제한
- 페이즈당 최대 7개 태스크 (초과 시 하위 Phase로 분할)
테스트 명령어
- 복사-붙여넣기로 바로 실행 가능한 정확한 명령어 작성
성공 기준
- 객관적으로 검증 가능해야 함
- "잘 동작함" (X) → "입력
{email: 'test@test.com'}에 대해 HTTP 200과 {token: string} 반환" (O)
페이즈 독립성
- 각 Phase는 작동하고 테스트 가능한 증분(increment)을 생산
- 데이터 의존성이 없는 Phase는 병렬 가능으로 표시
테스트 우선
- Happy-path와 Error-path 테스트 케이스 모두 포함
- 각 Phase의 테스트는 독립적으로 실행 가능해야 함
언어
- 기본: 한국어
- 프로젝트의 기존 문서가 영어면 영어로 전환
- 기술 용어 (함수명, 파일 경로, 명령어)는 항상 영어
1---2name: dev-plan3description: Create or update lightweight phased development plan documents with checkbox tasks, test cases, and completion criteria for implementation work4---56# Dev Plan78## Overview910프로젝트를 분석하고, 범위를 고정하며, 페이즈별 체크박스 태스크 + 테스트 케이스가 포함된 구현 계획서를 생성한다.1112## Inputs1314- `$goal`: 구현할 기능 또는 프로젝트 목표 설명1516---1718## Process1920### Step 1: 프로젝트 분석2122질문하기 전에 먼저 프로젝트를 분석한다:23241. **프로젝트 설정 파악**: `CLAUDE.md`, `README.md`, `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml` 등 루트 설정 파일을 읽는다.252. **프로젝트 문서 탐색**: Glob으로 `.md` 파일을 탐색하여 PRD, TRD, ADR, RFC, 기존 계획서 등 핵심 문서를 식별하고 읽는다.263. **소스 구조 매핑**: Glob으로 디렉토리 레이아웃을 파악한다 (`src/**`, `lib/**`, `app/**` 등).274. **컨벤션 식별**: 테스트 디렉토리, 린팅 설정, 빌드 설정, CI 파이프라인을 찾는다.285. **관련 코드 탐색**: `$goal`이 기존 기능을 참조하면, Grep으로 관련 모듈, 인터페이스, 타입을 찾는다.2930### Step 2: 요구사항 확인3132`$goal`이 모호하거나 부족한 경우에만 핵심 질문을 한다:3334- 범위 경계는? (명시적으로 제외되는 것은?)35- 하드 제약 조건은? (성능 목표, 하위 호환성, 특정 API 사용)36- 선호하는 아키텍처/패턴이 있는가?37- 테스트 전략은? (유닛, 통합, E2E?)3839**중요**: 과도한 질문 금지. 코드베이스 분석으로 충분한 컨텍스트를 얻었으면 바로 진행한다.4041### Step 3: 아키텍처 설계42431. 필요한 **핵심 추상화** 식별 (인터페이스, 타입, 모듈)442. **데이터 흐름** 매핑 (입력 → 변환 → 출력)453. 기존 코드와의 **통합점** 식별464. **병렬화 가능한 것** 파악 (독립 모듈)475. **순차적이어야 하는 것** 파악 (컴포넌트 간 의존성)4849### Step 4: 계획서 생성5051`references/dev-plan-template.md` 템플릿을 따라 작성한다. 필수 섹션:5253- Context (Why / Current State / Target State / Scope Boundary)54- Architecture Overview (Diagram / Design Decisions / New Files / Modified Files)55- Phase Dependencies56- Implementation Phases (Tasks + Success Criteria + Test Cases + Testing Instructions)57- Integration & Verification58- Edge Cases & Risks59- Execution Rules6061### Step 5: 엔지니어링 리뷰6263계획서 생성 후, 구현 전에 리뷰를 수행한다:64651. **자체 검증**: 계획서를 `code-review` 스킬의 Plan mode 기준으로 자체 점검한다.66 - 아키텍처 정합성, 소유권 경계, 엣지케이스, 보안, 테스트 전략672. **Engineering Review 섹션 추가**: 계획서에 다음 테이블을 포함한다:6869```md70## Engineering Review7172| 항목 | 판정 | 메모 |73|---|---|---|74| 아키텍처 | ready / needs revision / blocked | ... |75| 공유 계약 | ready / needs revision / blocked | ... |76| 엣지케이스 | ready / needs revision / blocked | ... |77| 테스트 전략 | ready / needs revision / blocked | ... |78```79803. **심층 리뷰 필요 시**: 사용자에게 `/code-review [plan-file-path]`로 별도 리뷰를 안내한다.8182### Step 6: 저장 및 보고83841. 프로젝트에 `docs/` 디렉토리가 있으면 → `docs/impl-plan-[feature-name].md`852. 없으면 → 프로젝트 루트에 `impl-plan-[feature-name].md`863. 결과 보고: 저장 위치, 총 Phase 수, 병렬 가능 Phase, 예상 범위8788---8990## Quality Rules9192### 태스크 구체성93- 모든 태스크에 **정확한 파일 경로**와 **함수/컴포넌트명** 명시94- "인증 모듈 구현" (X) → "`src/services/auth/oauth-client.ts`에 `exchangeCodeForToken()` 함수 구현" (O)9596### 페이즈 크기 제한97- 페이즈당 **최대 7개 태스크** (초과 시 하위 Phase로 분할)9899### 테스트 명령어100- 복사-붙여넣기로 바로 실행 가능한 **정확한 명령어** 작성101102### 성공 기준103- 객관적으로 검증 가능해야 함104- "잘 동작함" (X) → "입력 `{email: 'test@test.com'}`에 대해 HTTP 200과 `{token: string}` 반환" (O)105106### 페이즈 독립성107- 각 Phase는 작동하고 테스트 가능한 증분(increment)을 생산108- 데이터 의존성이 없는 Phase는 병렬 가능으로 표시109110### 테스트 우선111- Happy-path와 Error-path 테스트 케이스 모두 포함112- 각 Phase의 테스트는 독립적으로 실행 가능해야 함113114### 언어115- 기본: **한국어**116- 프로젝트의 기존 문서가 영어면 영어로 전환117- 기술 용어 (함수명, 파일 경로, 명령어)는 항상 영어