Dev Plan Generator

Dev Plan Generator

Overview

Create a lightweight development scope document that keeps implementation focused on the current goal. This document is for fixing scope, tracking phased work, and preserving development history across multiple implementation efforts.

Core intent

• Fix the goal and scope of the current work.
• Prevent implementation from expanding in a different direction.
• Track progress with phase-based checkboxes.
• Keep a history by creating a new plan file for each new workstream.

Trigger boundary and minimum response

• Treat ordinary requests such as 개발 계획, 개발계획, 구현 계획, 작업 계획, 개발 순서, 계획 세워줘, development plan, and implementation plan as this V1 workflow.
• Reserve explicit parallel requests such as 병렬 개발 계획, 병렬개발계획, 병렬 계획, or 병렬화 가능한지 판단 for V2 parallel-dev-plan-orchestrator.
• For a bare or underspecified planning request, first infer the goal from the current conversation, selected project, and relevant project docs. If the goal is reliable, proceed without asking again.
• If no reliable goal exists, ask exactly one concise goal question, such as 어떤 기능의 개발 계획을 작성할까요?, and wait for the answer. Never silently no-op and never invent a project goal.

Workflow

1. Read only the docs needed to fix scope before drafting: prefer README.md, AGENTS.md, CLAUDE.md, relevant docs/*.md, and recent dev-plan/*.md.
2. Clarify the goal, expected file/tree scope, exclusions, documented rules, and material ambiguities; if unclear, list likely cases/options and ask before choosing.
3. Before finalizing the plan, use scripts/dev_lesson.py find with the expected file/tree scopes. Start scope-only; use exact tags only to narrow an overly broad result. Zero matches is valid.
4. For each match, record adopted, not-applicable, or waived. An adopted item must name the prevention control and the exact plan task/test that applies it.
5. Create a new dev-plan/implement_YYYYMMDD_HHMMSS.md for a new workstream.
6. Update the same file only when the goal and scope are the same workstream.
7. Create a new file when the goal, scope, or refactor direction changes.
8. During implementation, record an evidence-only occurrence candidate for a material or reusable problem. At completion, triage every candidate as plan-only, existing-reference, or new-lesson.

Document rules

• Put 개발 목적, 개발 범위, 제외 범위, 참조 문서, and 공통 진행 규칙 at the top.
• Keep the document lightweight and implementation-oriented.
• Do not turn the document into a PRD, TRD, meeting log, or large design spec.
• Break work into ordered phases.
• Use markdown checkboxes for all implementation and test tasks.
• Each Phase must include self-tests.
• Do not move to the next Phase until the current Phase tests are complete.
• Record implementation issues inside the current Phase and fix them there.
• Create an occurrence candidate only for material impact, recurrence risk, a test/QA escape, security/privacy/integrity near-miss, or material rework. Do not record immediate typos and syntax fixes individually.
• At occurrence time, record only time, symptom, impact, reproduction/evidence, and temporary action. Do not guess the root cause.
• Confirm root cause, prevention control, and verification before promoting a reusable failure with scripts/dev_lesson.py record.
• Update checkbox state to match real progress.
• Do not add undocumented new features or unrelated refactors.
• Write the plan so another agent can resume it: purpose, scope, exclusions, file structure, implementation order, and test criteria must be clear.
• Plan implementation in the smallest maintainable responsibility units needed for the feature; define each unit's role and boundary without adding options, extensions, or extras outside scope.
• Extract shared logic only when it reduces duplication inside the planned scope; avoid purposeless abstraction.
• Prefer existing project APIs, official SDKs, and standard libraries before custom implementation; add new dependencies only when required by scope.
• Include a separate QA 관점 section for adversarial review, failure cases, boundary values, and regression risks.
• Keep Dev Lessons advisory. Do not manufacture a match, promote trivial failures, or automatically block completion.

History rules

• Create files under dev-plan/.
• Name files as implement_YYYYMMDD_HHMMSS.md.
• Set the first H1 to the exact filename including .md.
• Add 작성 일시 near the top.
• If this work follows a previous plan, add the previous plan to 참조 문서.
• Do not overwrite old plan files.

Required structure

Use this structure by default:

# implement_YYYYMMDD_HHMMSS.md

작성 일시: `YYYY-MM-DD HH:MM:SS TZ`

이 문서는 이번 개발의 범위를 고정하고, 구현이 목적 밖으로 확장되지 않도록 하기 위한 작업 문서다.

## 개발 목적
...

## 개발 범위
...

## 제외 범위
- ...

## 참조 문서
- [문서명](경로 또는 링크)
- 없음

## 과거 실패·교훈 참조
- 검색 상태: `미실행`
- 검색 대상 scope: `미확정`
- 검색 결과: `미확정`
- match가 있으면 disposition, 이유, 예방 control, 적용 task/test 위치를 적는다.

## 공통 진행 규칙
- 각 Phase는 앞선 Phase의 자체 테스트 완료 후에만 시작한다.
- 구현 중 발생한 이슈는 해당 Phase에서 수정하고 기록한다.
- 체크박스 상태를 실제 진행 상태와 맞게 업데이트한다.
- 문서에 없는 범위 확장은 하지 않는다.
- 요구사항이 불명확하면 가능한 케이스를 나누고 확인 후 진행한다.
- 한 기능은 유지보수 가능한 최소 책임 단위로 나누고, 각 단위의 역할과 경계를 계획에 적는다.
- 계획 밖 옵션/확장/부가 기능을 만들기 위한 분리는 하지 않는다.
- 공통화는 계획 범위 안의 중복을 줄일 때만 수행하고 과도한 추상화는 피한다.
- 기존 프로젝트 API, 공식 SDK, 표준 라이브러리를 우선 검토하고 새 의존성은 범위상 필요할 때만 포함한다.

## Phase 상태 요약
- [ ] Phase 1 완료
- [ ] Phase 2 완료

## QA 관점
- [ ] 실패 케이스와 경계값을 검토한다.
- [ ] 회귀 리스크와 검증 기준을 확인한다.

## 교훈 분류 요약
- [ ] 발생 후보 없음
- 후보가 있으면 `plan-only | existing-reference | new-lesson` 분류와 근거를 적는다.

## Phase 1. <이름>
### 목표
- ...

### 구현 태스크
- [ ] ...
- [ ] ...

### 자체 테스트
- [ ] ...
- [ ] ...

### 이슈 및 수정
- [ ] 발견 이슈 없음

### 완료 조건
- [ ] 구현 완료
- [ ] 자체 테스트 완료
- [ ] 다음 Phase 진행 가능

Optional sections

Add only when needed:

• 문서 기반 제약 사항
• 확인 필요 사항 / 결정 기록
• 예상 변경 파일 / 영향 범위
• 최종 결과 요약
• 잔여 리스크 / 후속 과제
• 이전 개발 계획

Script

Use scripts/new_dev_plan.py to scaffold a new file quickly. The script should stay minimal. It creates the document skeleton; the actual scope clarification comes from reading project docs and the user request.

Use scripts/dev_lesson.py for deterministic lesson find, record, and validate operations. Read the Dev Lesson workflow when lessons exist, an issue occurs, or the plan is being completed. Markdown is the only source of truth; do not create a committed index.