Menu
将工作分解为有序任务。当你有一个规格或明确需求，需要将工作分解为可实现的 task 时使用。当一个 task 感觉太大无法开始时、需要估算范围时，或并行工作可行时使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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。