PLAN 파일을 읽고 계획에 따라 개발을 순서대로 진행한다.
0. PLAN 파일 확인
대상 플랜 파일은 현재 디렉토리의 PLAN.md, 없으면 PLAN_*.md 중 가장 최근 수정본이다(어느 파일을 쓰는지 알린다). 둘 다 없으면 "PLAN 파일이 없습니다. /make-a-plan 으로 먼저 작성해 주세요." 라고 알리고 중단한다. 있으면 전체를 읽고 미완료 항목·우선순위·의존 관계·완료 조건을 파악한다.
아이디어(I-N) 제외: "아이디어 (보류)" 섹션의 I-N 항목은 착수 전 보류 후보이므로 진행 대상에서 제외한다. 태스크(T-N)만 순서대로 처리한다(마일스톤 M-N 은 태스크를 묶는 상위 단위일 뿐 그 자체가 실행 대상은 아니다). 사용자가 특정 아이디어 착수를 지시하면 그때 상세 인터뷰를 거쳐 정식 태스크로 편입한 뒤 진행한다.
진행 원칙: 항목을 한꺼번에 섞지 않고 하나씩, 반드시 구현 → 검증 → 커밋 으로 완결한다. 검증을 통과하지 않으면 커밋하지 않고, 커밋하지 않으면 다음 항목으로 넘어가지 않는다.
세션 위생: PLAN 은 세션 리셋 후에도 재개 가능한 진실원본이다. 태스크 몇 개를 소화해 컨텍스트가 비대해졌으면, 커밋 직후 경계에서 세션을 리셋(/clear)하고 재진입해도 손실이 없다. 늘어진 세션으로 품질을 떨어뜨리는 것보다 낫다.
1. 항목별 반복 루프
1-1. 작업 전 준비
해당 항목의 범위·완료 조건을 정의하고 관련 파일(정의·참조·테스트·설정)을 읽는다. PLAN 에 명시되지 않아 판단이 필요한 사항(설계 방향, 라이브러리·API 선택, 범위 경계, 네이밍, 에러 처리 정책 등)은 구현 시작 전에 AskUserQuestion 으로 모두 해소한다 — 추측으로 진행하지 않고, 답변으로 생긴 후속 의문도 다시 묻는다. PLAN 에 이미 명시됐거나 판단 요소가 없으면 묻지 않고 바로 구현한다. 확정된 결정은 섹션 2 형식으로 PLAN.md 에 기록한다.
1-2. 구현
작고 안전한 변경을 반복한다. 새 코드에는 테스트를 함께 작성하고, 버그 수정이면 회귀 테스트를 먼저 작성(실패 확인 후 수정)한다. 안전하지 않은 우회(--no-verify 등)는 쓰지 않는다.
1-3. 검증
테스트 전부 통과 + 빌드 성공 + 항목의 완료 조건에 맞는 동작 확인(성공 경로와 실패/경계 경로)을 모두 통과해야 1-4 로 간다. 실패하면 1-2 로 돌아가 수정 후 재검증하고, 해결 불가 시에만 사용자에게 알린다.
1-4. 커밋
검증이 모두 통과한 직후 /commit 스킬 규칙에 따라 즉시 커밋한다. 커밋 없이 다음 항목으로 넘어가지 않는다. 커밋 전 PLAN.md 의 해당 항목을 완료 처리하고 진행 상황을 갱신해 같은 커밋에 포함한다.
2. 디자인 결정 기록
항목 진행 중 중요한 설계 결정을 내릴 경우, PLAN.md의 적절한 위치에 다음 형식으로 기록한다.
### 디자인 결정: [결정 제목]
- **날짜**: YYYY-MM-DD
- **결정**: 선택한 방향
- **이유**: 결정 근거 (트레이드오프 포함)
- **대안**: 검토했던 다른 방법3. 완료 보고
모든 항목 완료 후 완료된 항목 목록, 중요한 디자인 결정, 추가 확인이 필요한 사항을 요약해 알린다. PLAN 에 완료([x]) 태스크가 3개 이상 쌓여 있으면 /cleanup-plan 실행 권장을 덧붙인다.