用途
Spec 是一个在写代码之前钉住意图的技能，把同一阶段拆成按调用顺序执行的三项工作：Spec（写规格）、Plan（写实施计划）、Tickets（切工单）。核心原则是规格捕获意图——用户需要什么、为什么；实施是计划的工作。混在一起会产生随技术栈变化就失效的规格，以及把未经检验的假设固化进去的计划。
主要能力
Spec 轮次
在规划之前捕获 WHAT/WHY：用户故事、验收标准、[NEEDS CLARIFICATION] 标记、接缝草图。此阶段不设计实现、不选技术栈/架构/库/数据结构、不写代码/文件路径/任务拆解，可用只读工具检查仓库；交付物为 .hermes/specs/ 下的 markdown 规格。
Plan 轮次
消费规格，写出可执行的实施计划：目标、当前上下文/假设、拟议方案、分步计划、可能变更的文件、测试/验证、风险与开放问题；代码任务还需准确文件路径、可能的测试目标与验证步骤。计划面向零上下文实施者：细小任务、DRY、YAGNI、TDD、频繁提交。此阶段不实现代码、不编辑除计划 markdown 外的项目文件、不运行变更性命令。交付物为 .hermes/plans/ 下的 markdown 计划。
Tickets
把已确定的规格或计划切成带阻塞边的 tracer-bullet 工单，便于并行工作单元；流程、工单文件格式、粒度、前沿调度见 references/ticket-slicing.md。
使用方式
用户可说“为 X 写规格”“规划 X”“plan mode”“把它拆成工单”“切分这个”“创建工作单元”等。按规模分级：T0 跳过本阶段；T1 跳过 spec 轮次（计划头部带假设行和 3-6 条以 step → verify: check 格式写的验收标准，计划为单个任务）；T2/T3 运行全部轮次。请求足够清晰时直接写计划，无明确指令时从对话上下文推断任务，确实描述不足时提一个简短澄清问题而非猜测。
保存位置（write_file，相对于当前工作目录）：
- Spec：.hermes/specs/YYYY-MM-DD_HHMMSS-<slug>.md
- Plan：.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md
- Tickets：.hermes/tickets/<feature-slug>/
适用场景
- 从零开始非平凡构建，先钉住意图；或已有规格、需要 HOW
- 工作在单个上下文窗口内会失控，或需要带依赖边、可并行的工作单元
- 用户明确要求写规格、做计划或切工单
限制与不适用
- 不适用于决策隐藏在其中的模糊计划，应先用 grill 阶段
- 不适用于能放进一个计划任务的单任务功能（直接规划，跳过切工单）、研究或探索、事后代码审查（用流水线的 review 阶段）
- 计划禁止占位符：不得出现 TBD、TODO、implement later、“添加适当的错误处理/验证”“为上述写测试”（未命名测试用例、接缝与期望值来源）、“与任务 N 类似”、只描述做什么不展示怎么做、引用任何任务中未定义的类型/函数/方法
- 规格中不得猜测：未说明处用 [NEEDS CLARIFICATION] 明确标记；规划前应尽量批量提问解决，用户不可用时保留标记，绝不静默解决
- 若规格覆盖多个独立子系统，建议拆成多个计划，每个子系统一个，各自能产出可工作、可测试的软件
规格自检要点
每条用户故事有可测试的验收标准（如“返回 200 且 JSON 体包含字段 X”而非“工作正常”）；无技术栈/库名/文件路径/架构选择泄漏；[NEEDS CLARIFICATION] 均已解决或确实无法解决；非功能需求可度量（目标数字而非“快”“安全”）；边界覆盖空状态、超限、非法输入、并发（如相关）、失败模式；无投机性“可能需要”的功能；约束逐字复制用户原话。