SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsimplementation-planner

implementation-planner

Coding & development

View repository

Updated 10-15 17:33

About this skill

Implementation Plan Generator

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:

# 需求实施计划

  • 1. Set up project structure and core interfaces

    • Create directory structure for models, services, repositories, and API components
    • Define interfaces that establish system boundaries
    • Set up testing framework

  • 2. Implement data models and validation

    • 2.1 Create core data model interfaces and types

      • Write TypeScript interfaces for all data models
      • Implement data integrity validation functions

    • 2.2 Implement user model with validation

      • Write user class with validation methods

    • 2.3 Implement document model with relationships

      • Write document class code with relationship handling

    • [ ]* 2.4 Write unit tests for data models

      • Create unit tests for user model validation
      • Write unit tests for document model
      • Write unit tests for relationship management

  • 3. Checkpoint - Ensure all tests pass

    • Ensure all tests pass, ask the user if there are any questions

  • 4. Create storage mechanism

    • 4.1 Implement database connection utility

      • Write connection management code
      • Create error handling utility for database operations

    • 4.2 Implement repository pattern for data access

      • Write base repository interface code
      • Implement concrete repositories with CRUD operations

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