القائمة
将工作分解为有序任务。当你有一个规格或明确需求，需要将工作分解为可实现的 task 时使用。当一个 task 感觉太大无法开始时、需要估算范围时，或并行工作可行时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | planning-and-task-breakdown |
| description | 将工作分解为有序任务。当你有一个规格或明确需求，需要将工作分解为可实现的 task 时使用。当一个 task 感觉太大无法开始时、需要估算范围时，或并行工作可行时使用。 |
将工作分解为具有显式验收条件的小型、可验证的 task。良好的任务分解是让智能体可靠完成工作与产生一团乱麻的区别。每个 task 应该足够小，以至于可以在一次专注的会话中实现、测试和验证。
何时不使用： 范围明显的单文件变更，或规格已经包含明确定义的 task。
在编写任何代码之前，以只读模式操作：
在规划期间不要编写代码。 输出是保存到 tasks/plan.md 的计划文档和保存到 tasks/todo.md 的 task 列表，而非实现。
绘制什么依赖什么的图：
存储引擎数据布局 / 核心数据结构
│
├── 协议定义与类型（protobuf / IDL）
│ │
│ ├── RPC service 实现
│ │ │
│ │ └── 客户端 SDK / 调用方库
│ │ │
│ │ └── 集成测试
│ │
│ └── 输入校验逻辑
│
└── 测试数据 / 迁移脚本
实现顺序遵循依赖关系图自底向上：先构建基础。
而不是先构建所有存储层，然后是所有 RPC，然后是所有客户端——一次构建一个完整的功能路径：
坏（水平切片）：
任务 1：构建整个数据模型
任务 2：构建所有 RPC 端点
任务 3：构建所有服务端模块
任务 4：连接所有内容
好（垂直切片）：
任务 1：客户端可以创建资源（写入路径的 Schema + RPC + 存储）
任务 2：客户端可以读取资源（读取路径的索引 + RPC + 存储）
任务 3：客户端可以列出资源（列表查询的索引 + RPC + 分页）
任务 4：客户端可以删除资源（删除路径的 RPC + 墓碑 + GC）
每个垂直切片交付可工作的、可测试的功能。
每个任务遵循此结构：
## 任务 [N]：[简短的描述性标题]
**描述：** 一段话解释此任务完成什么。
**验收条件：**
- [ ] [具体的、可测试的条件]
- [ ] [具体的、可测试的条件]
**验证：**
- [ ] 测试通过：`go test ./... -run TestFeatureName` 或 `cargo test feature_name`
- [ ] 构建成功：`go build ./...` 或 `cargo build`
- [ ] 手动检查：[描述要验证什么]
**依赖项：** [此任务依赖的任务编号，或"无"]
**可能涉及的文件：**
- `internal/service/task.go` 或 `src/service/task.rs`
- `internal/service/task_test.go` 或 `src/service/task_test.rs`
**估算范围：** [小：1-2 个文件 | 中：3-5 个文件 | 大：5+ 个文件]
安排任务使：
添加显式检查点：
## 检查点：任务 1-3 之后
- [ ] 所有测试通过
- [ ] 应用程序构建无错误
- [ ] 核心用户流程端到端工作
- [ ] 在继续之前与人类一起审查
| 大小 | 文件数 | 范围 | 示例 |
|---|---|---|---|
| XS | 1 | 单个函数或配置变更 | 添加验证规则 |
| S | 1-2 | 一个模块或 RPC 端点 | 添加新 RPC 端点 |
| M | 3-5 | 一个功能切片 | 资源 CRUD 流程 |
| L | 5-8 | 跨模块功能 | 带过滤和分页的列表查询 |
| XL | 8+ | 太大——进一步分解 | — |
如果一个任务大小是 L 或更大，它应该被分解为更小的任务。智能体在 S 和 M 任务上表现最佳。
何时进一步分解任务：
tasks/plan.md。tasks/todo.md。如果 tasks/ 目录不存在，请创建它。这些路径是 /build 命令和其他下游工具期望的约定。
# 实现计划：[功能/项目名称]
## 概述
[一段话总结我们正在构建什么]
## 架构决策
- [关键决策 1 及其原因]
- [关键决策 2 及其原因]
## 任务列表
### 阶段 1：基础
- [ ] 任务 1：...
- [ ] 任务 2：...
### 检查点：基础
- [ ] 测试通过，构建干净
### 阶段 2：核心功能
- [ ] 任务 3：...
- [ ] 任务 4：...
### 检查点：核心功能
- [ ] 端到端流程工作
### 阶段 3：打磨
- [ ] 任务 5：...
- [ ] 任务 6：...
### 检查点：完成
- [ ] 所有验收条件已满足
- [ ] 准备好进行审查
## 风险与缓解措施
| 风险 | 影响 | 缓解措施 |
|------|--------|------------|
| [风险] | [高/中/低] | [策略] |
## 待解决问题
- [需要人工输入的问题]
当有多智能体或多个会话可用时：
| 合理化借口 | 现实 |
|---|---|
| "我边做边搞清楚" | 这就是你最终得到一团乱麻和返工的原因。10 分钟规划节省数小时。 |
| "任务很显而易见" | 还是写下来。显式的任务揭示隐藏的依赖项和被遗忘的边界情况。 |
| "规划是额外开销" | 规划就是任务。没有计划的实现只是打字。 |
| "我可以在脑袋里全记住" | 上下文窗口是有限的。书面计划在会话边界和压缩之后仍然存在。 |
在开始实现之前，确认：
验收条件是按任务定义的，并回答"我们构建了正确的东西吗？"。它们位于项目范围的完成定义之上，这是每个任务在计入完成之前都需要清除的常设标准。参见 references/definition-of-done.md。