用途：在写代码之前先写结构化 spec，作为人与工程师共享的事实来源，定义要构建什么、为什么构建、以及如何判定完成。适用于新项目或新功能、需求有歧义或不完整、变更触及多个文件或模块、即将做架构决策、任务实现超过约30分钟。单行修复、拼写更正或需求明确且自包含的变更不必使用。
主要能力：采用门控四阶段工作流——SPECIFY、PLAN、TASKS、IMPLEMENT，每阶段需人工评审通过后再进入下一阶段。阶段0范围检查在请求打包了多个可独立测试的能力时激活，先产出能力地图（模块 id 用 kebab-case、依赖有方向无环、构建顺序），经评审后再按模块递归。Specify 阶段先暴露假设，再写覆盖 Objective、Commands、Project Structure、Code Style、Testing Strategy、Boundaries 六区的 spec，并把模糊需求重框为可测试的成功标准。Plan 输出到 tasks/plan.md，Tasks 拆成离散任务并写入默认 tasks/todo.md，Implement 逐步执行并保持 spec 鲜活。
使用方式与限制：spec 随代码版本控制，在 PR 中引用；项目若已用 OpenSpec 等外部规格系统则沿用其格式，不重复创建 SPEC.md。具体实现顺序、任务拆分、上下文加载等机制以其引用的其他技能为准。该技能的收费、平台要求等资料暂未提供。