用途：将提案中的能力转化为可测试的行为需求。规格只定义可观察行为，不涉及架构或实现；在提出某能力的建议需求与场景并获得用户批准前，不得写入该能力的规格。
主要能力：读取提案与相关既有规格，依据提案中的能力名称确定新建或修改的规格文件；对修改类能力，先定位当前需求块再起草增量；逐个能力推进，借助 codagent:ask-questions 澄清实质行为、边界、错误与边缘情况；只提问影响可观察行为或范围的问题，必要时给出默认建议，不以泛泛的批准问题代替发现过程；展示该能力完整的建议需求与场景，包括由上下文推断出的重要假设或默认值。
使用方式：用户说出“spec this”“write specs”“create specs”或“run the spec skill”时触发。批准后按下述 OpenSpec 格式写入规格文件，并报告创建的相对路径，不调用其他生命周期技能。每个能力一个文件：specs/<capability>/spec.md。规范性需求使用 SHALL 或 MUST；使用 ### Requirement: <name>，每个需求至少一个 #### Scenario: <name>；场景描述可观察的 WHEN/THEN 行为，场景标题必须恰好四个井号。按需使用增量段落：## ADDED Requirements（新行为）、## MODIFIED Requirements（变更行为，须复制现有完整需求块及全部场景后再编辑）、## REMOVED Requirements（附 Reason 与 Migration）、## RENAMED Requirements（附 FROM 与 TO）。
适用场景：从提案导出行为规格，作为设计前的需求基线。
限制：若行为依赖尚未解决的架构选择，只写当前可知部分，并在受影响场景添加 <!-- deferred-to-design: <reason> -->，由设计阶段补全或修订；规格阶段不要提问架构或实现问题。除非文件内容、配置结构或技能文本本身是公开契约，否则避免为此类内容编写场景。