Development Plan Document PRO
Use this skill when the user wants AI to investigate first and then produce a detailed implementation plan before coding.
Goal: create a plan detailed enough that another engineer or agent can implement it without rediscovering the same context.
Required research phase
Before writing the plan, inspect the repository and identify:
- Entry points and user-facing flow
- Relevant modules, services, hooks, components, commands, or scripts
- Existing types, interfaces, schemas, events, and configuration
- Similar implementations to reuse
- Data flow and state ownership
- Test, build, and runtime validation paths
- Security, compatibility, migration, and rollback risks
Separate confirmed facts from assumptions. If a key detail cannot be found, mark it as an open question instead of inventing it.
Plan structure
Use this structure unless the user requests another format:
- Goal and non-goals
- Current-state findings
- Proposed architecture
- Data model and type definitions
- Module-by-module implementation plan
- Function/method/interface changes
- Event, telemetry, or persistence changes
- Validation plan
- Rollout, rollback, and migration notes
- Risks and open questions
- Step-by-step task checklist
Detail requirements
- Name concrete files or modules when known.
- Include proposed function names, signatures, type shapes, or config keys when useful.
- Explain where data enters, how it transforms, and where it is persisted or rendered.
- Include error handling, idempotency, permissions, and observability where relevant.
- Provide validation commands or manual checks.
- Keep speculative pieces clearly labeled.
Final checks
- Could another agent implement from this plan without redoing all research?
- Are function/type/interface definitions specific enough?
- Are risks, validation, and rollback included?
- Are unknowns explicit rather than hidden?
1---2name: development-plan-doc-pro3description: Use when creating a serious engineering implementation plan after repository research. Pro version requires investigation before planning and produces a detailed plan down to modules, functions, type definitions, interfaces, data flow, validation, risks, rollout, and task checklist.4---56# Development Plan Document PRO78Use this skill when the user wants AI to investigate first and then produce a detailed implementation plan before coding.910Goal: create a plan detailed enough that another engineer or agent can implement it without rediscovering the same context.1112## Required research phase1314Before writing the plan, inspect the repository and identify:15161. Entry points and user-facing flow172. Relevant modules, services, hooks, components, commands, or scripts183. Existing types, interfaces, schemas, events, and configuration194. Similar implementations to reuse205. Data flow and state ownership216. Test, build, and runtime validation paths227. Security, compatibility, migration, and rollback risks2324Separate confirmed facts from assumptions. If a key detail cannot be found, mark it as an open question instead of inventing it.2526## Plan structure2728Use this structure unless the user requests another format:29301. Goal and non-goals312. Current-state findings323. Proposed architecture334. Data model and type definitions345. Module-by-module implementation plan356. Function/method/interface changes367. Event, telemetry, or persistence changes378. Validation plan389. Rollout, rollback, and migration notes3910. Risks and open questions4011. Step-by-step task checklist4142## Detail requirements4344- Name concrete files or modules when known.45- Include proposed function names, signatures, type shapes, or config keys when useful.46- Explain where data enters, how it transforms, and where it is persisted or rendered.47- Include error handling, idempotency, permissions, and observability where relevant.48- Provide validation commands or manual checks.49- Keep speculative pieces clearly labeled.5051## Final checks5253- Could another agent implement from this plan without redoing all research?54- Are function/type/interface definitions specific enough?55- Are risks, validation, and rollback included?56- Are unknowns explicit rather than hidden?
mr-q526