用途
writing-specs 是工作流家族为所有规格文档设立的共享质量标准，适用于工作流某一步骤正在起草或修订规格产物的场景，包括目标与需求文档、架构文档和模块 SPEC。流程类技能会在起草或修订规格的步骤点名引用这一概念；具体起草什么、何时起草，仍由引用它的技能决定。
主要能力与原则
该准则从三个维度约束规格质量：
简短：规格应小到可以一次性读完，追求高信号而非面面俱到。要解释意图而不是罗列清单——说明该事物为何存在、拥有什么、边界在哪，而不是堆文件清单或复述代码。
诚实：只出现已确定的内容，不用 [TBD] 或占位段落填充；尚未敲定的章节直接不存在。任何推断而非确认的内容，需在出现的原处内联标注为未确认。新建和推断出的规格在用户审阅前保持 status: draft，转为非草稿状态取决于用户审阅，而非起草智能体自行判断。经审阅的持久规格进入 active 状态而非 done，它会持续生效并随项目演进。
有据可依：高信号到未来智能体或人类无需重新推导即可落回决策之上。规格是决策理由的唯一归宿：决策、不变量、权衡和缺陷复盘都记录在这里，而不是代码注释；代码中发现的说理段落应提升到所属规格，最多保留一行指针以防误改静默破坏。每件事只说一次：按 id 链接而非复述；兄弟模块之间的依赖边记录在父级规格中，而不是每个叶子中。每个真实边界一份规格，而非每个目录或每个文件一份。
此外，该准则还规定目标文档描述产品而非计划：goal-and-requirements 是产品是什么以及为什么的活记录，包括目标、问题、受众、能力、非目标以及任何持久原则。不写版本、发布、阶段、MVP/v1/v2 拆分或“以后”清单——排期不是规格的职责，被移出范围的设想交还给用户在其规划工作的地方跟踪，绝不进入文档。能力描述产品做什么，对新项目则描述其最小可用的首次构建将做什么。非目标只包含因决策而排除的内容；既未列出也未排除的事项是开放的，而非禁止的。目标文档随产品演进：新增能力或推翻原则的变更，要在同一次变更中更新目标文档。
使用方式
writing-specs 本身不是一个可直接调用的工具，而是被流程技能在起草或修订规格的步骤中引用的共享概念。它与 spec-graph 技能分工：frontmatter、链接种类、spec_* 工具等图机制属于 spec-graph 技能的基础内容，writing-specs 在其之上承载家族对规格的质量要求，并沉淀家族关于规格和规格图的规则。
适用场景
适用于需要产出或维护规格文档的工程工作流，尤其是采用规格图管理多模块依赖的项目。起草目标与需求、架构或模块 SPEC 时，以及需要判断规格是否达到“简短、诚实、有据可依”标准时，可参照该准则。
限制
该准则不规定何时起草规格，也不涵盖规格图的底层机制（如 frontmatter、链接种类和 spec_* 工具），这些由 spec-graph 技能负责。其具体使用条件和集成方式，暂未提供更多细节。