| name | generate-plan |
|---|---|
| description | 바이브 코딩 도입 계획서를 생성한다. "도입 계획 만들어줘", "전환 계획 생성", "마이그레이션 계획", "generate plan", "바이브 코딩 계획" 등의 요청에 사용한다. |
코드베이스 자동 분석 → 심층 인터뷰 → 사용자 승인 → 계획서 작성 순서로 바이브 코딩 도입 계획서를 생성한다.
$ARGUMENTS: 프로젝트 루트 경로 (기본값: 현재 디렉토리)- 선택:
ideation.md파일이 있으면 참조하여 목표/맥락 보강
코드베이스 자동 분석 → 심층 인터뷰 (3~5회) → 분석 요약 제시 → 사용자 승인 → 계획서 생성
$ARGUMENTS 경로(또는 현재 디렉토리)의 프로젝트를 스캔하여 자동 수집한다.
0-1. 기술 스택 파악
- 언어/프레임워크 (package.json, build.gradle, requirements.txt, composer.json 등)
- 파일 수 및 코드 라인 수 (언어별)
- 디렉토리 구조 패턴 (모노레포, FSD, 레이어드 등)
0-2. 현재 상태 진단
- 테스트: 테스트 파일 수, 프레임워크, 설정 파일 존재 여부
- CI/CD: .github/workflows, .gitlab-ci.yml, Jenkinsfile 등
- 문서: CLAUDE.md, README.md, ADR, OpenSpec 존재 여부
- 린트/포맷: ESLint, Prettier, PHPStan, Ruff 등 설정 파일
- 타입 안전성: TypeScript strict 모드, mypy, PHPStan 레벨
0-3. 기술 부채 스캔
- @ts-nocheck, // @ts-ignore, any 타입 사용 건수
- TODO/FIXME/HACK 주석 건수
- deprecated API 사용 (패키지 버전 확인)
- 대형 파일 (1000줄 이상) 목록
0-4. ideation.md 참조 (있는 경우)
- ideation.md가 프로젝트 루트 또는 지정 경로에 있으면 읽어서 목표/맥락 보강
- 없으면 인터뷰에서 목표를 직접 파악
코드베이스 분석 결과를 기반으로 3~5라운드 심층 인터뷰를 진행한다. AskUserQuestion 도구를 사용하여 대화형으로 진행한다.
라운드 1: 프로젝트 맥락 — 분석 결과를 보여주며 확인:
- 프로젝트 성격 (신규 개발 / 레거시 전환 / 운영 중 개선)
- 팀 규모 및 AI 도구 경험 수준
- 전환의 핵심 동기와 기대 효과
- 분석 결과 중 수정/보완할 사항
라운드 2: 현재 상태 심화
- 테스트 현황의 실제 상태 (통과율, 신뢰도)
- CI/CD의 실제 활용도 (형식적 존재 vs 실제 게이트)
- 가장 큰 기술 부채 또는 페인 포인트
- 외부 의존성 (다른 서비스, 외부 API, DB)
라운드 3: 목표 설정
- 바이브 코딩 도입 후 기대하는 정량 목표 (테스트 커버리지, 배포 빈도 등)
- 절대 바꾸면 안 되는 것 (제외 범위)
- 타임라인 제약 (일정, 릴리즈 주기)
- 참고할 다른 팀 사례가 있는지
라운드 4~5: 필요 시 추가
- 복잡한 도메인 로직 (권한, 결제, 암호화 등)의 상세 확인
- 멀티서비스/멀티플랫폼 환경의 서비스 간 의존성
- 데이터 마이그레이션 필요 여부
인터뷰 결과를 종합하여 분석 요약을 작성하고 사용자에게 제시한다.
## 프로젝트 개요
- 프로젝트명, 성격, 팀 규모
## 현황 진단
| 영역 | 현재 상태 | 갭 | 영향 |
|------|----------|-----|------|
## 전환 목표
- 정량 목표 (전환 전 → 목표)
- 제외 범위
## 제안 Phase 구성
- Phase 1~N 개요 (상세는 승인 후 작성)
## 예상 리스크 (Top 3)사용자가 승인하면 Phase 3으로 진행한다. 수정 요청 시 반영 후 재제시.
승인된 분석 요약을 기반으로 migration-plan.md를 생성한다.
- 필수 10개 섹션은 output-template.md 참조
- 프로젝트 유형별 Phase 구성과 가이드라인은 project-guidelines.md 참조
바이브 코딩 환경에서는 AI 에이전트의 생산성이 높으므로 일정 추정은 하지 않는다. 대신 작업을 최대한 구체적으로 세분화하여 병렬 실행을 극대화한다.
각 Phase는 Step 단위로 최대한 세분화하고, 각 Step에 다음을 포함한다:
- 인수조건 (체크리스트 형태)
- 산출물 목록
- 의존성: 선행 Step 명시 (없으면 "없음 — 병렬 가능")
의존성 표기 규칙:
없음→ 다른 Step과 독립적, 병렬 실행 가능1-1→ Step 1-1 완료 후 시작1-1, 1-3→ 두 Step 모두 완료 후 시작Phase 1 전체→ Phase 1의 모든 Step 완료 후 시작
- 정량화: 모든 목표는 측정 가능하게 (OX 사례)
- 인수조건: 각 Phase에 체크리스트 기반 인수조건 (OX 사례)
- 갭 분석에 "영향" 포함: "없으면 어떤 문제?" (Office Agent 사례)
- 제외 범위 명시: "하지 않을 것" 선언 (Safebox 사례)
- 실패 사례 포함: 예상 리스크와 대응 (오피스메일 사례)
- 작업 세분화: Step 단위 최대 세분화 + 의존성 표기로 병렬 실행 극대화 (CrossViewer 교훈)
- 프롬프트 패턴 포함: 각 Phase별 권장 프롬프트 (오피스메일 BE 사례)
- ADR 사전 정의: ADR 제목과 핵심 결정을 미리 계획 (Office Agent FE 사례)
- 보안 우선: Critical 보안 이슈는 기능 전환보다 먼저 (오피스메일, 웹개발팀 사례)
- 도메인 용어집: AI가 비즈니스 로직을 이해하는 핵심 전략 (OX 사례)
| 파일 | 설명 |
|---|---|
migration-plan.md |
바이브 코딩 도입 계획서 (필수 10개 섹션 포함) |
- 계획서 필수 섹션 템플릿: output-template.md
- 프로젝트 유형별 가이드라인: project-guidelines.md