agentleFS
yh594774855yh594774855/skill-collection/skills/implementation-planner/SKILL.md

implementation-planner

Skill0 starsChanged 3 months agoMITView on GitHub

专业的软件架构师,根据用户需求和设计方案创建详细的实施(开发)计划。将设计方案转化为可执行的任务列表,支持测试驱动开发和渐进式实现。

7 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use code-review.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 20 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 20

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the following content to build comprehensive understanding:

    line 67
  2. Distinctive:

    Read the design specification for the current feature

    line 79
  3. Distinctive:

    Only read specifications from related historical features based on subdirectory names

    line 84
  4. Distinctive:

    Avoid reading too many unrelated files to prevent context overflow

    line 85
  5. Distinctive:

    Create a detailed implementation plan following these CRITICAL CONSTRAINTS:

    line 89
  6. Distinctive:

    Output ONLY the task list template content: - no additional sections or commentary

    line 93
  7. Distinctive:

    Write property-based tests for universal attributes all inputs should have

    line 112
  8. Distinctive:

    Test utilities and fixtures

    line 133
  9. Distinctive:

    Cover all codeable aspects: - ensure the plan addresses everything that can be implemented

    line 151
  10. Distinctive:

    Proactively identify gaps: - if gaps are found during planning, suggest returning to requirements or design phase

    line 188
  11. Distinctive:

    Place property tasks close to implementation for early error detection

    line 191
  12. Distinctive:

    After generating the initial task list:

    line 197
  13. Distinctive:

    If user requests changes or doesn't explicitly approve, go back to Step 2

    line 201
  14. Distinctive:

    If user explicitly approves, proceed to next step

    line 202
  15. Distinctive:

    If tool unavailable, send message to user and wait for response

    line 209
  16. Distinctive:

    If user wants all tasks executed, remove all "*" markers to make them required

    line 210
  17. Distinctive:

    Write the final task list to:

    line 214
  18. Distinctive:

    Before finalizing the task list, verify:

    line 230
  19. Distinctive:

    All communication uses the project's configured language

    line 246
  20. Distinctive:

    If gaps are found during planning, proactively suggest returning to requirements/design phase

    line 247

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

实施计划生成器

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. 设置项目结构和核心接口
   - 为模型、服务、存储库和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 (docs/)
    • INDEX.md - Project overview
    • ARCHITECTURE.md - System architecture
    • Other relevant documentation files
  3. Current Feature Design (specs/[feature-name]/design.md)
    • Read the design specification for the current feature
    • Understand requirements, architecture, and components
  4. Historical Feature Specs (specs/*/*.md)
    • IMPORTANT: First use Glob to list all subdirectories under 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:

specs/{FEATURE_NAME}/tasklist.md

Output File Structure

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.