메뉴
在编码之前创建规格。当开始一个新项目、功能或重大变更且尚无规格时使用。当需求不清晰、模棱两可，或仅作为模糊想法存在时使用。当需要起草 PRD（产品需求文档）时使用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
SOC 직업 분류 기준
| 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 小时的调试。 |
| "需求反正会变" | 这就是为什么规格是活的文档。过时的规格仍然比没有规格好。 |
| "用户知道他们想要什么" | 即使是明确的请求也有隐含的假设。规格揭示那些假设。 |
在继续实现之前，确认：