القائمة
在编码之前创建规格。当开始一个新项目、功能或重大变更且尚无规格时使用。当需求不清晰、模棱两可，或仅作为模糊想法存在时使用。当需要起草 PRD（产品需求文档）时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | spec-driven-development |
| description | 在编码之前创建规格。当开始一个新项目、功能或重大变更且尚无规格时使用。当需求不清晰、模棱两可，或仅作为模糊想法存在时使用。当需要起草 PRD（产品需求文档）时使用。 |
在编写任何代码之前编写结构化规格。规格是你和人类工程师之间的共享真相来源——它定义我们正在构建什么、为什么以及如何知道它完成了。没有规格的代码就是猜测。
何时不使用： 单行修复、拼写纠正或需求明确且自包含的变更。
规范驱动开发有四个阶段。在当前阶段被验证之前，不要推进到下一阶段。
规格化 ──→ 规划 ──→ 任务 ──→ 实现
│ │ │ │
▼ ▼ ▼ ▼
人类 人类 人类 人类
审查 审查 审查 审查
从高层愿景开始。询问人类澄清问题，直到需求具体。
立即提出假设。 在编写任何规格内容之前，列出你正在假设的内容：
我正在做的假设：
1. 这是一个单机存储引擎（非分布式）
2. 节点间通信使用 gRPC（非自研二进制协议）
3. 持久化格式沿用现有 LSM-tree 布局（基于现有 manifest 格式）
4. 我们仅针对 Linux x86_64（无 macOS/ARM 支持）
→ 现在就纠正我，否则我将按这些进行。
不要静默地填补模棱两可的需求。规格的整个目的就是在代码编写之前揭示误解——假设是最危险的误解形式。
编写涵盖这六个核心领域的规格文档：
目标——我们正在构建什么以及为什么？用户是谁？成功是什么样子？
命令——带有标志的完整可执行命令，而不仅仅是工具名称。
构建：cargo build --release
测试：cargo test --workspace
Lint：cargo clippy -- -D warnings
开发：cargo run --bin server
项目结构——源代码的位置、测试的位置、文档的位置。
src/ → 服务源代码
src/storage → 存储引擎
src/rpc → 网络与 RPC 层
tests/ → 单元和集成测试
tests/cluster → 多节点端到端测试
docs/ → 文档
代码风格——一个展示你风格的真实代码片段胜过三段描述它的文字。包含命名约定、格式化规则和良好输出的示例。
测试策略——什么框架、测试的位置、覆盖率期望、哪些测试级别用于哪些关注点。
边界——三层系统：
规格模板：
# 规格：[项目/功能名称]
## 目标
[我们正在构建什么以及为什么。用户故事或验收条件。]
## 技术栈
[框架、语言、关键依赖项及版本]
## 命令
[构建、测试、Lint、开发——完整命令]
## 项目结构
[带描述的目录布局]
## 代码风格
[示例片段 + 关键约定]
## 测试策略
[框架、测试位置、覆盖率要求、测试级别]
## 边界
- 始终：[...]
- 先询问：[...]
- 永远不：[...]
## 成功标准
[我们如何知道这完成了——具体的、可测试的条件]
## 待解决问题
[任何未解决的、需要人类输入的问题]
将指令重新框定为成功标准。 当收到模糊需求时，将其转化为具体条件：
需求："让读取路径更快"
重新框定的成功标准：
- 命中缓存的点查 p99 < 1ms
- 冷读（未命中缓存）p99 < 10ms
- 16 线程下吞吐不低于 200K ops/s
→ 这些是正确的目标吗？
这让你能够循环、重试和解决问题以达成清晰目标，而非猜测"更快"意味着什么。
有了经过验证的规格，生成技术实现计划：
遵循
planning-and-task-breakdown了解这些步骤背后的依赖图映射和垂直切片机制；它是规范的来源。上面的要点是轻量摘要；如果它们有分歧，以planning-and-task-breakdown为准。输出约定： 将计划保存到
tasks/plan.md，将任务列表保存到tasks/todo.md，按照/plan命令约定。如果tasks/不存在则创建它。下游命令（/build等）期望这些路径。
计划应该是可审查的：人类应该能够阅读它然后说"是的，这是正确的方法"或"不，改 X。"
将计划分解为离散的、可实现的 task：
遵循
planning-and-task-breakdown了解完整的任务规模化和依赖排序机制；它是规范的来源。下面的模板是轻量内联形式；如果它们有分歧，以planning-and-task-breakdown为准。
任务模板：
- [ ] 任务：[描述]
- 验收：[完成后什么必须为真]
- 验证：[如何确认——测试命令、构建、手动检查]
- 文件：[哪些文件将被触碰]
一次执行一个任务，遵循 skills/incremental-implementation/SKILL.md（incremental-implementation）和 skills/test-driven-development/SKILL.md（test-driven-development）。使用 skills/context-engineering/SKILL.md（context-engineering）在每个步骤加载正确的规格部分和源文件，而非用整个规格淹没智能体。
规格是活的文档，而非一次性产物：
| 合理化借口 | 现实 |
|---|---|
| "这很简单，我不需要规格" | 简单的任务不需要长规格，但它们仍然需要验收条件。两行的规格也可以。 |
| "我写完代码再写规格" | 那是文档，不是规格。规格的价值在于在代码之前强制清晰性。 |
| "规格会拖慢我们" | 15 分钟的规格可以防止数小时的返工。15 分钟的瀑布式胜过 15 小时的调试。 |
| "需求反正会变" | 这就是为什么规格是活的文档。过时的规格仍然比没有规格好。 |
| "用户知道他们想要什么" | 即使是明确的请求也有隐含的假设。规格揭示那些假设。 |
在继续实现之前，确认：