create-development-plan

# Create Development Plan Write an implementation plan that an engineer with no context can follow without asking questions. Be specific about *what* to change, *where*, and *how to verify*; do not write the code itself. Keep it DRY and YAGNI. Relation to other planning artifacts: `docs/tasks/plan.md` and `docs/tasks/todo.md` hold the project-wide order and task list (see `.agents/skills/planning-and-task-breakdown`). A development plan expands **one slice** of that list into a self-contained document. Do not duplicate the project plan. **Do not write production code while planning.** ## Process 1. **Collect.** Read the relevant requirement IDs (FR/AC) in `requirements.md`, the contract entries, `docs/knowledge/README.md`, the ADRs that apply, and the existing code in the owner's area (`backend/` or `frontend/`). Note the patterns and conventions to follow. 2. **Clarify.** List open decisions as a design tree. Ask every question whose prerequisites are settled in one round: number them, give your recommended answer, then wait for the answers before asking dependent questions. Look up facts yourself (files, tools, versions); ask the user only for decisions. Record open questions in the plan's decisions table with an `[Answer]:` slot. 3. **Break down.** Cut the slice into tasks that are each independently completable and verifiable (target: one focused session, at most about 5 files). Order them by dependency; keep vertical slices (API + UI + test) over horizontal layers when practical. 4. **Write.** Fill `./assets/plan-template.md` and save to `docs/development-plans/YYYY-MM-DD-<slice>.md` (create the folder if missing). Link requirement, contract and TC IDs on every task. 5. **Review.** Check: every AC is covered by a task; every task names files, tests and a verification command; risks and the fallback are explicit; no "ask the user" remains. Then request approval from the TechLead before implementation starts. ## Rules - Tasks name the exact files and the exact commands from `AGENTS.md` (backend gate, frontend gate, Docker check). - Tests come first or with the code: each task lists the unit/API/e2e cases (TC IDs) to write or update. - Security and performance: reference the `dev-standards` checklist items that apply to the slice. - Record deviations from `contract.md` or the ADRs as a proposed change, never silently. - After implementation, tick the Definition of Done in the plan and log the changed files in `docs/FILE-CHANGELOG.md`. ## References and assets - [Plan template](./assets/plan-template.md)