| schemaVersion | "2026-04-11T00:00:00.000Z" |
| skillId | general/development-plan-doc-pro |
| name | development-plan-doc-pro |
| displayName | Development Plan Document PRO |
| description | 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. |
| aliases | ["development-plan-doc-pro","Development Plan Document PRO","development plan doc pro","developmentplandocpro","开发计划文档","功能开发规划","技术方案","实施方案","详细开发计划","方法定义","类型定义","接口定义","任务拆解","coding plan","implementation plan","plan","计划","开发计划"] |
| version | 0.1.0 |
| sourceHash | sha256:c7850be779ea7ab5eb709394614ae09ec19ce24ee153556982cd235cc701a28a |
| domain | general |
| departmentTags | ["backend-platform","frontend-platform"] |
| sceneTags | ["architecture","planning","review"] |
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?
