Cursor rule

1# 开发工作流
2 
3> 此文件扩展 [common/git-workflow.md](./git-workflow.md)，包含 git 操作之前的完整功能开发流程。
4 
5功能实现工作流描述了开发管道：研究、规划、TDD、代码审查，然后提交到 git。
6 
7## 功能实现工作流
8 
90. **研究与重用** _(任何新实现前必需)_
10   - **GitHub 代码搜索优先：** 在编写任何新代码之前，运行 `gh search repos` 和 `gh search code` 查找现有实现、模板和模式。
11   - **库文档其次：** 使用 Context7 或主要供应商文档确认 API 行为、包使用和版本特定细节。
12   - **仅当前两者不足时使用 Exa：** 在 GitHub 搜索和主要文档之后，使用 Exa 进行更广泛的网络研究或发现。
13   - **检查包注册表：** 在编写工具代码之前搜索 npm、PyPI、crates.io 和其他注册表。首选久经考验的库而非手工编写的解决方案。
14   - **搜索可适配的实现：** 寻找解决问题 80%+ 且可以分支、移植或包装的开源项目。
15   - 当满足需求时，优先采用或移植经验证的方法而非从头编写新代码。
16 
171. **先规划**
18   - 使用 **planner** 代理创建实现计划
19   - 编码前生成规划文档：PRD、架构、系统设计、技术文档、任务列表
20   - 识别依赖和风险
21   - 分解为阶段
22 
232. **TDD 方法**
24   - 使用 **tdd-guide** 代理
25   - 先写测试（RED）
26   - 实现以通过测试（GREEN）
27   - 重构（IMPROVE）
28   - 验证 80%+ 覆盖率
29 
303. **代码审查**
31   - 编写代码后立即使用 **code-reviewer** 代理
32   - 解决关键和高优先级问题
33   - 尽可能修复中优先级问题
34 
354. **提交与推送**
36   - 详细的提交消息
37   - 遵循约定式提交格式
38   - 参见 [git-workflow.md](./git-workflow.md) 了解提交消息格式和 PR 流程
39 
405. **审查前检查**
41   - 验证所有自动化检查（CI/CD）已通过
42   - 解决任何合并冲突
43   - 确保分支已与目标分支同步
44   - 仅在这些检查通过后请求审查
45