| name | plan |
| description | 구현 전 설계 및 계획 수립 — 요구사항 분석, 설계 대안 비교, 구현 계획을 사용자와 정렬한다 |
| user-invocable | true |
Plan
구현을 시작하기 전에 요구사항을 분석하고, 설계 대안을 비교하고, 구현 계획을 수립한다.
workstream 기반 프로젝트에서는 현재 workstream만 보는 것이 아니라 roadmap의 모든 workstream 설계와 의존 관계를 먼저 확정한다.
사용자와 계획을 정렬한 후 구현을 진행한다.
1. 요구사항 분석
- 사용자의 요청을 읽고 핵심 목표와 제약을 정리한다.
- 인자가 전달되면 (
/plan <task-description>) 해당 내용을 작업 설명으로 사용한다.
- 프로젝트의 architecture 문서, roadmap, rules가 있으면 읽어서 현재 맥락을 파악한다.
- 관련된 기존 코드를 탐색하여 현재 구조와 패턴을 이해한다.
정리할 항목
- 목표: 이 작업이 달성해야 하는 것
- 제약: 건드리면 안 되는 것, 유지해야 하는 것
- 영향 범위: 변경이 미치는 파일/모듈 범위
- 불확실한 점: 추가 확인이 필요한 사항
2. 설계 대안 비교
변경이 단순하지 않을 때 (3개 이상의 파일 수정 또는 설계 판단이 필요한 경우), 실행 가능한 접근 방식을 2-3개 도출하고 비교한다.
각 대안에 대해:
- 핵심 아이디어 (1-2문장)
- 장점
- 단점 / 리스크
- 영향받는 파일/모듈
변경이 단순하면 이 단계를 건너뛰고 바로 구현 계획으로 넘어간다.
3. 구현 계획
선택한 접근 방식을 구체적인 작업 단위로 분해한다.
계획에 포함할 항목
- 작업 순서 (의존성 고려)
- 각 단계에서 변경할 파일/모듈
- 각 단계의 검증 방법 (테스트, 빌드)
- 예상되는 커밋 단위
- roadmap/workstream이 있으면 모든 workstream의 목표, 순서, 선행 의존성, 종료 조건
- 새로 도입할 라이브러리가 있으면 후보를 조사하고, 선정 근거와 함께 문서에 확정한다 (dependencies.md "Library Selection" 참조)
계획 수립 시 원칙
- 의존되는 쪽을 먼저 구현한다.
- 각 단계가 끝나면 빌드와 테스트가 통과하는 상태여야 한다.
- workstream이 있는 프로젝트에서는 roadmap 전체를 설계하되, 구현 계획은 workstream 순서대로 분해한다.
4. 사용자 확인
기본 모드에서는 계획을 사용자에게 다음 형식으로 보고하고 구현 전 정렬한다.
단, project-automation.md에서 automation_mode: full-auto이고 allow_midway_user_prompt: false이면 별도 승인 대기 없이 roadmap 전체 계획을 확정하고 다음 구현 단계로 진행한다.
목표 및 제약
(정리된 목표와 제약)
접근 방식
(선택한 방식과 이유. 대안이 있었으면 비교 요약)
구현 계획
(번호가 매겨진 단계별 목록. workstream 기반 프로젝트라면 모든 workstream이 포함되어야 한다.)
불확실한 점
(추가 확인이 필요한 사항. 없으면 없음)
중간 승인이 허용된 모드에서는 사용자가 계획을 승인하면 구현을 시작한다. 수정 요청이 있으면 계획을 조정한 후 재확인한다.
/workstream와의 관계
/plan은 roadmap 전체의 설계와 구현 계획을 수립하고, /workstream은 각 workstream을 그 계획 순서대로 실행한다.
- workstream 기반 프로젝트에서는
/plan으로 모든 workstream 설계를 확정한 후, /workstream 또는 /autopilot으로 실행을 시작한다.
/plan은 단독으로도 사용할 수 있다. workstream이 없는 프로젝트에서는 /plan 후 바로 구현한다.