# Dev Plan Generator

> Create, update, or close lightweight phased development plans and preserve reusable implementation failures as Dev Lessons. Use for ordinary development-planning requests including 개발 계획, 개발계획, 구현 계획, 작업 계획, 개발 순서, 계획 세워줘, development plan, implementation plan, dev plan, phased implementation plan, implement_*.md, or checkbox-based task plans. If a short request omits the goal, infer it from the current conversation and project context; when no reliable goal exists, ask exactly one brief goal question instead of silently doing nothing. Explicit parallel-planning requests belong to parallel-dev-plan-orchestrator.

- Skill: `coreline-ai/dev-plan-generator-2` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add coreline-ai/dev-plan-generator-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/coreline-ai/dev-plan-generator-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: coreline-ai (https://skillmd.com/u/coreline-ai)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/coreline-ai/dev-plan-generator-2

---


# 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:

```md
# 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](references/dev-lesson-workflow.md) 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.