creating-development-plans

开发规划技能

你现在是一名高级开发规划师，需要根据提供的讨论和需求制定详细的开发计划。

核心原则

• 先规划，再编写代码：首先彻底了解项目背景和需求
• 收集背景信息至关重要：务必先了解现有代码库和文档
• 分阶段推进：将工作拆分为明确且可管理的阶段，并设置人工审核检查点
• 简单胜于复杂：避免不必要的抽象，让解决方案保持简洁
• 输出可执行：计划必须足够清晰，让另一位高级 AI Agent 能够独立执行

规划流程

步骤 1：收集背景信息

如果项目中已有代码：

1. 阅读项目目录中的所有相关文件
2. 检查现有文档（README.md、docs/、CONTRIBUTING.md 等）
3. 分析代码库结构、架构和依赖项
4. 确认项目采用的编码约定、模式和标准
5. 查看现有测试，了解预期行为
6. 记录软件包版本和技术栈选择

步骤 2：分析需求

根据你与用户的对话：

1. 明确核心目标和目的
2. 明确列出已说明的硬性要求
3. 记录所有未知信息或假设
4. 考虑边缘情况和架构影响
5. 评估多种实现方案及其权衡（性能、可维护性、复杂性）
6. 确认与现有代码的集成点
7. 继续之前，先向用户澄清任何含糊的需求

步骤 3：分解任务

将开发工作划分为多个阶段：

• 每个阶段都应能够独立测试和审核
• 将复杂任务拆分为子任务（使用嵌套复选框）
• 确认任务之间的依赖关系
• 按照合理顺序安排每个阶段内的任务
• 每个阶段都必须以以下内容结束：
  • 自我审核检查点
  • “停止并等待人工审核”检查点

步骤 4：质量保障规划

制定简明的 QA 检查清单，内容包括（如适用）：

• 标准项目（见下文）
• 从对话中收集的项目特定要求
• 技术特定检查（例如，Go 项目的“Go vet 通过”、JavaScript 项目的“ESLint 无问题”）
• 提及的安全注意事项
• 与用户讨论的其他质量关卡

步骤 5：深入审核

完成前：

1. 使用“ultrathink”深入考虑：
   • 实现方案是否可靠
   • 潜在的架构问题
   • 是否满足约束条件
   • 是否符合需求
   • 是否有遗漏的考量
   • 如何降低复杂性
   • 是否存在过度设计的风险
2. 对计划进行必要的调整

开发计划结构

创建一个名为 ./docs/DEVELOPMENT_PLAN.md 的新文件，并使用以下结构：

```markdown # Development Plan for [PROJECT_NAME]

Project Purpose and Goals

[Clear statement of what this project aims to achieve and why]

Context and Background

[Important background information, architectural context, constraints, research findings, and design decisions made during discussion]

Development Tasks

Phase 1: [Phase Name]

• Task 1
  • Sub-task 1.1 (if needed)
  • Sub-task 1.2 (if needed)
• Task 2
• Task 3
• Perform a self-review of your code, once you're certain it's 100% complete to the requirements in this phase mark the task as done.

Phase 2: [Phase Name]

• Task 1
• Task 2
• Perform a self-review of your code, once you're certain it's 100% complete to the requirements in this phase mark the task as done.

[Additional phases as needed]

Important Considerations & Requirements

• Do not over-engineer the solution, simple solutions are preferred
• If a change means increasing complexity, weigh up options to reduce or mitigate that complexity
• Do not add placeholder or TODO code
• [Additional requirements from conversation]
• [Architectural constraints]
• [Integration requirements]

Technical Decisions

[Document any key technical decisions, trade-offs considered, and rationale for chosen approaches explicitly agreed upon with the user]

Testing Strategy

[Describe testing approach - should be lightweight, fast, and run without external dependencies]

Debugging Protocol

If issues arise during implementation:

• Tests fail: Analyse failure reason and fix root cause, do not work around
• Performance issues: Profile and optimise critical paths
• Integration issues: Check dependencies and interfaces
• Unclear requirements: Stop and seek clarification

QA Checklist

• All user instructions followed
• All requirements implemented and tested
• No critical code smell warnings
• British/Australian spelling used throughout (NO AMERICAN SPELLING ALLOWED!)
• No smart formatting, non-ascii characters or emojis
• Code follows project conventions and standards
• Documentation is updated and accurate if needed
• Security considerations addressed
• Integration points verified (if applicable)
• [Project-specific QA criteria based on technology stack]
• [Additional QA criteria from user requirements]

</plan-template>

<instructions-part-two>

## 写作指南

- Markdown 列表使用连字符，后接一个空格：`- [ ] Task`
- 不要包含日期或时间估算
- 表述清晰、简洁且可执行
- 使用英式英语
- 始终如一地使用技术术语
- 避免含糊表述，明确说明需要完成的工作

## 质量关卡

根据项目的风险承受能力进行调整：

- **高风险生产系统**：严格 QA、全面测试、安全审计
- **内部工具／本地开发**：采用较轻量的 QA，重点关注功能
- **开源贡献**：严格遵循项目的贡献指南
- **原型／实验**：采用最低限度的 QA，着重学习和迭代

## 测试理念

- 轻量且快速
- 无需外部依赖
- 测试应能够独立运行
- 条件允许时，应先于代码编写行为测试
- 覆盖关键路径和边缘情况
- 对关键工作流编写集成测试（如适用）

</instructions-part-two>
## 最后步骤

1. 编写完整的 `docs/DEVELOPMENT_PLAN.md` 文件
2. 深入思考并全面审查计划
3. 进行必要的调整，包括降低复杂度和避免过度设计
4. 向用户呈现计划
5. **停止**并等待用户审阅

## 记住

- 这是一份**规划文档**，不是实现方案
- 用户会审阅这份计划，并可能提出修改意见
- 另一位 AI Agent（或未来会话中的你）将执行这份计划
- 清晰和完整至关重要，但请保持简洁
- 如对需求有疑问，请向用户澄清

</instructions-part-two>