sdd-spec

用途：sdd-spec 是 SDD 流程中专责编写规格的子智能体。它接收编排器传入的变更名称与产物存储模式，读取提案（proposal）中的 Capabilities 部分，产出描述系统行为增量的 delta specs，或用例场景化的完整新规格。\n\n主要能力：一，区分新增与修改能力；新增能力写成完整规格，修改能力写成 delta 规格；二，增量规格分 ADDED、MODIFIED、REMOVED、RENAMED 四类；三，需求使用 RFC 2119 关键词（MUST、SHALL、SHOULD、MAY）表达强度；四，场景统一用 GIVEN/WHEN/THEN/AND 格式，需覆盖正常路径与边界情况且可测试。\n\n使用方式：先确认自身角色，若是子智能体则继续本阶段工作，不得委派或调用 Skill 工具；若通过 skill() 直接加载，则作为编排器应停止并委派给专门的 sdd-spec 子智能体。随后读取共享约定文件（如 skills/_shared/sdd-phase-common.md、openspec-convention.md），按模式读取与保存产物：engram 读取 sdd/{change-name}/proposal 并保存 sdd/{change-name}/spec；openspec 与 hybrid 按 openspec 约定在 openspec/changes/{change-name}/specs/{domain}/spec.md 下写文件；none 仅返回结果，不创建或修改项目文件。文件落点由调度器只读取变更目录下的规格决定。\n\n修改既有需求时须遵循固定流程：在主规格中定位需求，整块复制（含全部场景）到 MODIFIED Requirements 下，再编辑副本并注明（Previously: …）。新增行为而不改变既有行为时应使用 ADDED。REMOVED 需给出原因并建议迁移说明，RENAMED 需写明新旧名称。新领域无既有规格时写完整规格，不直接写入 openspec/specs/，由 sdd-archive 提升。\n\n限制：技术产物默认英文；规格描述 WHAT 不描述 HOW，不得包含实现细节；每个需求至少一个场景；规格产物须在 650 词以内，场景每例 3 至 5 行；须遵循 openspec/config.yaml 中的 rules.specs。若缺少提案或存储模式等必要输入，资料未提供相应处理方式。