implementation-planner

# 实施计划生成器 Transform design documents into detailed, executable implementation plans with structured task lists. ## Overview This skill acts as a professional software architect that: 1. Reads project context, documentation, and design specifications 2. Generates detailed implementation plans following a specific task list format 3. Ensures plans are executable, testable, and aligned with design documents 4. Supports iterative refinement with user feedback ## Task List Template Implementation plans must follow this structure: ```markdown # 需求实施计划 - [ ] 1. 设置项目结构和核心接口 - 为模型、服务、存储库和API组件创建目录结构 - 定义建立系统边界的接口 - 设置测试框架 - [ ] 2. 实现数据模型和验证 - [ ] 2.1 创建核心数据模型接口和类型 - 为所有数据模型编写TypeScript接口 - 实现数据完整性验证函数 - [ ] 2.2 实现带有验证的用户模型 - 编写带有验证方法的用户类 - [ ] 2.3 实现带有关系的文档模型 - 编写带有关系处理的文档类代码 - [ ]* 2.4 为数据模型编写单元测试 - 为用户模型验证创建单元测试 - 为文档模型编写单元测试 - 为关系管理编写单元测试 - [ ] 3. 检查点 - 确保所有测试通过 - 确保所有测试通过,如有疑问请询问用户 - [ ] 4. 创建存储机制 - [ ] 4.1 实现数据库连接工具 - 编写连接管理代码 - 为数据库操作创建错误处理工具 - [ ] 4.2 实现数据访问的存储库模式 - 编写基础存储库接口代码 - 实现具有CRUD操作的具体存储库 ``` ## Workflow ### Step 1: Gather Context Read the following content to build comprehensive understanding: 1. **Project Code Structure** - Analyze existing codebase organization - Identify architectural patterns and conventions 2. **Project Documentation** (`.monkeycode/docs/`) - `INDEX.md` - Project overview - `ARCHITECTURE.md` - System architecture - Other relevant documentation files 3. **Current Feature Design** (`.monkeycode/specs/[feature-name]/design.md`) - Read the design specification for the current feature - Understand requirements, architecture, and components 4. **Historical Feature Specs** (`.monkeycode/specs/*/*.md`) - **IMPORTANT**: First use Glob to list all subdirectories under `.monkeycode/specs/` - Only read specifications from related historical features based on subdirectory names - Avoid reading too many unrelated files to prevent context overflow ### Step 2: Generate Task List Create a detailed implementation plan following these **CRITICAL CONSTRAINTS**: #### Format Requirements - **Output ONLY the task list template content** - no additional sections or commentary - **Maximum 2 levels of hierarchy**: - Top-level items (epics) - use only when needed - Sub-tasks with decimal numbering (e.g., 1.1, 1.2, 2.1) - **Every item must be a checkbox** - **Prefer simple, flat structure when possible** #### Task Content Requirements Each task must include: - **Clear objective** describing what code to write, modify, or test - **Additional details** as sub-bullets under the task - **References to specific requirements** from the design document (reference fine-grained sub-requirements, not just user stories) #### Testing Strategy **CRITICAL TESTING PATTERNS**: 1. **Property-Based Testing** - Write property-based tests for universal attributes all inputs should have - Unit tests and property tests are complementary: - Unit tests catch specific errors - Property tests verify general correctness 2. **Test Task Organization** - Testing tasks MUST NOT exist as standalone top-level tasks - Testing tasks MUST be sub-tasks under parent implementation tasks - Testing sub-tasks are marked as **optional** with suffix "*" to indicate they're not required for core functionality 3. **Optional Task Marking** - Testing-related sub-tasks include: unit tests, property tests, integration tests - **Top-level tasks MUST NEVER have "*" suffix** - **Only sub-tasks can have "*" suffix** - ❌ WRONG: `- [ ]* 2. 设置项目结构和核心接口` - ✅ CORRECT: `- [ ]* 2.2 编写集成测试` (as a sub-task) 4. **Optional Task Categories** - Property-based tests - Unit tests - Integration tests - Test utilities and fixtures - Other supporting test infrastructure 5. **Task Execution Rules** - **Core implementation tasks must NEVER be marked as optional** - **Optional tasks (marked with *) should NOT be implemented by the agent** - **Required tasks (no *) MUST be implemented by the agent** - Example: - `- [ ]* 2.2 编写集成测试` → Agent skips this - `- [ ] 2.2 为存储库操作编写单元测试` → Agent must implement this #### Planning Principles - **Discrete, manageable coding steps** - each task should be a single, focused action - **Reference specific requirements** - link each task to design document requirements - **Avoid excessive implementation details** - design document already covers those - **Assume all context is available** - requirements and design docs will be accessible during implementation - **Progressive building** - each step builds upon previous steps - **Cover all codeable aspects** - ensure the plan addresses everything that can be implemented #### Checkpoints - Include checkpoint tasks at reasonable breakpoints - Checkpoint task format: `"确保所有测试通过,如有疑问请询问用户"` - Multiple checkpoints are allowed - Checkpoints ensure code quality before proceeding #### Implementation-First Development - **Implement functionality BEFORE writing corresponding tests** - **Validate core functionality early** through code execution - Focus on making features work first, then ensure they work correctly #### Scope Boundaries **Tasks MUST be actionable by a coding agent:** - Writing, modifying, or testing specific code components - Specifying files or components to create/modify - Specific enough to execute without additional clarification - Focused on implementation details, not high-level concepts - Scoped to concrete coding activities (e.g., "Implement X function" not "Support X feature") **Tasks MUST NOT include non-coding activities:** - ❌ User acceptance testing or feedback collection - ❌ Deployment to production/staging environments - ❌ Performance metrics collection or analysis - ❌ Running the application for end-to-end testing (but automated E2E tests are OK) - ❌ User training or documentation creation - ❌ Business process or organizational changes - ❌ Marketing or communication activities - ❌ Anything that cannot be completed by writing/modifying/testing code #### Coverage and Quality - **Ensure all requirements are covered** in implementation tasks - **Proactively identify gaps** - if gaps are found during planning, suggest returning to requirements or design phase - **Translate correctness properties** into property-based tests - Each property in its own separate sub-task - Place property tasks close to implementation for early error detection - Annotate with property number and requirement clause reference - Explicitly reference the design document property being checked ### Step 3: User Review and Iteration After generating the initial task list: 1. **Ask for Additions** using the AskUserQuestion tool: - Question: "对当前的任务列表是否有需要补充的内容?" - If user requests changes or doesn't explicitly approve, go back to Step 2 - If user explicitly approves, proceed to next step 2. **Ask about Optional Tasks** using the AskUserQuestion tool: - Question: "任务列表中默认将一些非开发任务(例如测试、文档)标记为可选,以便优先关注核心功能。是否要在本次实施过程中执行这些任务?" - Options: - "目前只执行开发任务,将其他任务标记为可选" (keep "*" markers) - "执行所有任务" (remove "*" markers) - If tool unavailable, send message to user and wait for response - If user wants all tasks executed, remove all "*" markers to make them required ### Step 4: Write Task List Write the final task list to: ``` .monkeycode/specs/{FEATURE_NAME}/tasklist.md ``` ## Output File Structure ``` .monkeycode/specs/{FEATURE_NAME}/ ├── requirements.md # Feature requirements (from previous phase) ├── design.md # Technical design (from previous phase) └── tasklist.md # Implementation plan (generated by this skill) ``` ## Quality Checklist Before finalizing the task list, verify: - [ ] Uses maximum 2 levels of hierarchy - [ ] All items are checkboxes - [ ] Testing tasks are sub-tasks, not top-level - [ ] Optional tasks marked with "*" suffix (only sub-tasks) - [ ] Top-level tasks have NO "*" suffix - [ ] Each task references specific requirements - [ ] Tasks are actionable by coding agents - [ ] No non-coding activities included - [ ] Checkpoints included at reasonable intervals - [ ] All design aspects covered - [ ] Progressive, buildable task sequence ## Notes - All communication uses the project's configured language - If gaps are found during planning, proactively suggest returning to requirements/design phase - Focus on creating actionable, executable tasks for coding agents - Balance detail with clarity - provide enough context without over-specifying implementation