implementation-planner
Skill0 starsChanged 3 months agoMITView on GitHub
专业的软件架构师,根据用户需求和设计方案创建详细的实施(开发)计划。将设计方案转化为可执行的任务列表,支持测试驱动开发和渐进式实现。
7 other projects use a version of this.
Adopted by
Most recently taken up by
- Flowerf19/agents-skillstheir own version, first seen Nov 8, 2026
- galz10/pickle-rick-extensiontheir own version, first seen Oct 8, 2026
- cellrishi-code/claude-skills-atlastheir own version, first seen Oct 4, 2026
- fworks-tech/agenthoodtheir own version, first seen Sep 28, 2026
- gasatrya/skillstheir own version, first seen Jun 9, 2026
- xuanjgcarryyou/claude-skilltheir own version, first seen May 29, 2026
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.
GoogleSkillcode-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
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- galz10/pickle-rick-extension★ 454same name
- cellrishi-code/claude-skills-atlas★ 6same name
- Flowerf19/agents-skills★ 3same name
- fworks-tech/agenthood★ 3same name
- gasatrya/skills★ 1same name
- ngothanhthien/claude-skills★ 0same name
- xuanjgcarryyou/claude-skill★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- deploy-websiteSkill
- feature-designSkill
- feature-implementerSkill
- project-wikiSkill
- publish-websiteSkill
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
- Distinctive: line 67
Read the following content to build comprehensive understanding:
- Distinctive: line 79
Read the design specification for the current feature
- Distinctive: line 84
Only read specifications from related historical features based on subdirectory names
- Distinctive: line 85
Avoid reading too many unrelated files to prevent context overflow
- Distinctive: line 89
Create a detailed implementation plan following these CRITICAL CONSTRAINTS:
- Distinctive: line 93
Output ONLY the task list template content: - no additional sections or commentary
- Distinctive: line 112
Write property-based tests for universal attributes all inputs should have
- Distinctive: line 133
Test utilities and fixtures
- Distinctive: line 151
Cover all codeable aspects: - ensure the plan addresses everything that can be implemented
- Distinctive: line 188
Proactively identify gaps: - if gaps are found during planning, suggest returning to requirements or design phase
- Distinctive: line 191
Place property tasks close to implementation for early error detection
- Distinctive: line 197
After generating the initial task list:
- Distinctive: line 201
If user requests changes or doesn't explicitly approve, go back to Step 2
- Distinctive: line 202
If user explicitly approves, proceed to next step
- Distinctive: line 209
If tool unavailable, send message to user and wait for response
- Distinctive: line 210
If user wants all tasks executed, remove all "*" markers to make them required
- Distinctive: line 214
Write the final task list to:
- Distinctive: line 230
Before finalizing the task list, verify:
- Distinctive: line 246
All communication uses the project's configured language
- Distinctive: line 247
If gaps are found during planning, proactively suggest returning to requirements/design phase
“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.
Files
实施计划生成器
Transform design documents into detailed, executable implementation plans with structured task lists.
Overview
This skill acts as a professional software architect that:
- Reads project context, documentation, and design specifications
- Generates detailed implementation plans following a specific task list format
- Ensures plans are executable, testable, and aligned with design documents
- 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:
- Project Code Structure
- Analyze existing codebase organization
- Identify architectural patterns and conventions
- Project Documentation (
docs/)INDEX.md- Project overviewARCHITECTURE.md- System architecture- Other relevant documentation files
- Current Feature Design (
specs/[feature-name]/design.md)- Read the design specification for the current feature
- Understand requirements, architecture, and components
- 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
- IMPORTANT: First use Glob to list all subdirectories under
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:
- 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
- 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
- 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)
- Optional Task Categories
- Property-based tests
- Unit tests
- Integration tests
- Test utilities and fixtures
- Other supporting test infrastructure
- 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:
- 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
- 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.mdOutput 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
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
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.

