用途
requirements 是 keel 工作流中的需求文档技能，把用户已明确的需求和背景扩展为结构化需求文档，建立功能点（F）、用户故事（US）、验收标准（AC）与约束（CON）的关联体系。它定位为产品分析师：关注用户价值、场景完备性和验收可测性，回避技术实现、架构决策和性能方案，判断倾向是宁可多问不可假设。
模糊的产品想法不适合本技能，应先用 /prd；技术设计交给 /system-design；测试用例交给 /test-cases。
主要能力
- 需求扩写：将简短需求扩展为结构化文档，生成 F/US/AC 编号并建立追溯矩阵。
- 多运行模式：
/requirements：自动检测初始/增量模式。无 01-requirements.md 走初始模式，已有则走增量模式。/requirements --from-prd <index路径>：消费 /prd 产出的结构化需求包，FR-XX 转为 F/US/AC，NFR-XX 转为 CON-XXX，并回写 keel 映射。/requirements --update-design：写入或更新设计资产（design_context），不触发需求拆解。/requirements --context：背景信息模式，追加或更新背景。
- 约束编号 CON-XXX：承载制品型需求（性能基线、日志规约、安全加固、可观测性、上架合规、平台备案）。有用户可观测行为的需求必须走 F/US/AC，不得写成 CON 规避 AC。
- 发布合规清单两级触发：用户明说发布/上架/提审/合规等，或文档已有该类别 CON 时加载清单展开；仅探测到平台制品文件时只输出一行提示，不展开、不追问。
- 质量自检：INVEST 标准、AC 可验证性、GWT 完整性，自检不通过自动修复后再呈现用户。
- needs review 机制：未确认假设、开放问题、待实测项进入待确认区，必填关联、问题、归属、关闭条件、提出日期、下游影响。
使用方式
- 快速开始：一句话将明确需求转化为 F/US/AC 结构化文档；最常见用法是
/requirements（自动检测初始/增量）或/requirements --from-prd <index路径>。 - 初始模式流程：设计资产感知 → 收集原始需求（记录原话、来源、日期）→ 理解需求并探索代码库 → 呈现需求拆解方案与轻量假设挑战 → 用户确认 → 识别功能点 → 编写用户故事 → 编写验收标准 → 生成追溯矩阵。用户确认前只展示方案，不写入文件。
- 增量模式：扫描现有 F/US/AC 最大编号，追加新需求到原始需求表，延续编号并标注增量版本和日期，更新追溯矩阵，返回新增编号列表，不删除或覆盖既有内容。
- 背景信息模式：基线项目写 00-baseline.md（未知/推导待确认条目需用户明确确认才升格），否则写 01-requirements.md 的背景与目标章节。
- 输出文件：主文件 docs/devdocs/01-requirements.md，超过 300 行可拆分为概览、用户故事详情、非功能性需求等文件。文档含 11 个章节：原始需求、设计资产（可选）、背景与目标、功能点清单、里程碑（可选）、用户故事、验收标准、追溯矩阵、非功能性需求、范围边界、风险与假设。
- 编号规范：F-XXX、US-XXX、AC-XXX、M-XXX（里程碑，可选，不进追溯矩阵），全局顺序编号，不嵌套，编号一旦分配不可复用。
- 语言：支持中英文提问，统一中文回复，使用中文生成文档。
适用场景
- 用户提供功能需求或想法，要求创建或编写需求文档。
- 用户想澄清或记录需求，或补充项目背景信息（尤其 retrofit 后）。
- 来自 /feature 的增量需求委托、/insights 的洞察转化、/bugfix 暴露的需求缺失。
- 消费 /prd 产出的需求包，转化为正式 F/US/AC。
- 与 /system-design、/test-cases、/onboard 等下游技能协作。
限制
- 文档阶段禁止产出实现代码（源代码、脚本、配置变更），编码转交 /dev-workflow。
- 生成或更新文档必须在顶部写入 generated_by / spec_version / generated_at 三字段 YAML frontmatter，否则禁止继续。
- 输入少于 200 字且无结构化标记时，必须确认，建议先运行 /prd。
- 初始模式在编号分配前必须经用户确认功能点划分、范围边界和优先级。
- 里程碑只问一次是否分段交付，不自动划分、不替用户划。
- 不得添加用户未提及且未确认的功能；不得把未确认假设写成确定事实。
- 敏感信息（密钥、密码、内部 URL）不得写入文档。
- 具体收费、价格、平台支持情况等资料暂未提供。