用途：在 ol-sdd-workflow 第一阶段为单个功能编写完整规格。规格由三份文档组成，顺序严格，每份之间有审批门。该技能负责需求与任务阶段，并把设计阶段委派给 software-architect（feature-design 模式）。可由工作流编排器调用，也可由用户或架构师直接调用。
主要产出：documentation/specs/{feature}/requirements.md（本技能，门 1a 需求审批）、design.md（software-architect，门 1b 设计审批）、tasks.md（本技能，门 1c 任务审批）。三份文档经 docs adapter 发布；docs 目标为 confluence、notion、ado-wiki 或 local，缺省时从 documentation/workflow-config.md 推断，无 docs MCP 时默认 local。
使用方式：先读取 documentation/steering 下的 product.md、tech.md、structure.md，缺失则要求先回到 product-vision-steering（Phase 0）；同时读取活动发布的 epic-map.md。与用户确认功能名（kebab-case）、单行描述、所属发布 epic、上游依赖与约束，并初始化目录与空文件。需求按模板填写，含 EARS 格式验收标准并编号，附非功能性需求。设计阶段调用 software-architect，生成概览、steering 对齐、代码复用分析、Mermaid 架构图、组件与接口、数据模型、错误处理、测试策略等。任务阶段拆成原子任务：文件范围 1–3 个、15–30 分钟、单一可测结果、明确路径，并标注 Requirements、Leverage、Skill（依据 references/skill-routing.md）及工时估算。三门通过后提交并发布。
发布：无发布计划时，独立 epic 由后续 backlog 类技能创建；有发布 epic 时更新其描述加入规格链接，并把 epic-map.md 的 Spec Status 从 not specced 改为 specced。
限制：不做 BORO/BIE 本体分析（交给 ontologist 等）；不创建 tracker 工单；不实现任务；不刷新 steering 文档。若因技能规则误解或缺失被纠正，可调用 skill-feedback 反馈，未安装时询问用户是否安装。