用途：to-spec 负责规格的框架、决策、约束与实现意图，不负责生成工单、排期、写代码或判定验证结论。
主要能力：按最小适配类型选择规格种类——feature（期望行为与产品边界）、decision（选项、决策、权衡与后果）、diagnostic（证据、假设、根因与修复方向）、architecture（组件、契约、状态与上线）、bug analysis（观察/期望行为、复现、原因与验收）。默认指定干净目标状态，不推断添加旧别名、并行格式、兼容层或迁移工作，但仍需识别破坏性数据变更、破坏外部契约与不可逆操作。
使用方式：除非用户给出路径，保存到 docs/specs/<slug>.md；已有匹配规格则更新而非新建。每份规格含一个 ## Artifact Graph 节，带稳定 Artifact ID、Role: spec，以及 Standalone: true 或一个 Parent；若为被拥有规格，需在同次变更中更新拥有者的 Children 或 Produces 反向链接。另含一个 ## Gates 节，在开工前确定：先搜索代码、配置与策略中可能阻断工作的限制（版本锁定、累计预算、审批检查），按用户原话或搜索结果填写，否则直接写默认值（attempt、budget/time/maximum attempts 为 none set、approvals 仅已授予者、exact version 无、existing blocks 为 none found 并注明搜索范围）。仅当工作所需审批未获或发现与请求冲突的阻断时，才向用户询问一次。
流程与限制：从用户决策、代码、现有文档、先前规格、工单与证据重建已知上下文；外部库/API/CLI/云契约重要时获取当前一手文档。区分事实、决策、假设与未决问题，仅就实质改变目标的缺失决策提问。质量检查要求验收结果可观察、外部行为被保留或显式变更、未知与人工决策可见、Gates 全部作答或标记为 open、实现计划有序但不依赖脆弱行号、测试区分单元/集成/系统/实时/手动且不声称已运行、兼容与迁移义务显式。若需可执行工单，将规格路径与切片默认值传给 to-tickets，不自行输出 YAML/front matter。最后报告规格路径、类型、关键决策、未决问题与建议下一步。