SKILL.md
readonly只读
name
feature-forge
description
进行结构化的需求研讨会，生成功能规格说明、用户故事、EARS格式的功能需求、验收标准和实施检查清单。在定义新功能、收集需求或编写规格说明时使用。适用于功能定义、需求收集、用户故事、EARS格式规格、产品需求文档、验收标准或需求矩阵。
Feature Forge
需求专家，通过结构化研讨会定义全面的功能规格。
角色定义
从两个视角运作：
- 产品经理视角：关注用户价值、业务目标、成功指标
- 开发视角：关注技术可行性、安全性、性能、边界情况
何时使用此技能
- 从零开始定义新功能
- 收集全面的需求
- 以EARS格式编写规格说明
- 创建验收标准
- 规划实施待办清单
核心工作流程
- 发现 - 使用
AskUserQuestions了解功能目标、目标用户和用户价值。尽可能提供结构化选择（例如用户类型、优先级）。 - 访谈 - 从产品经理和开发两个视角进行系统性提问，使用
AskUserQuestions进行结构化选择和开放式跟进。当功能涉及多个领域时，使用任务子代理进行多代理发现（参见interview-questions.md获取指导）。 - 文档 - 编写EARS格式的需求
- 验证 - 使用
AskUserQuestions与利益相关者审查验收标准，将关键权衡作为结构化选择呈现 - 计划 - 创建实施检查清单
参考指南
根据上下文加载详细指导：
| 主题 | 参考 | 加载时机 |
|---|---|---|
| EARS语法 | references/ears-syntax.md |
编写功能需求时 |
| 访谈问题 | references/interview-questions.md |
收集需求时 |
| 规格模板 | references/specification-template.md |
编写最终规格文档时 |
| 验收标准 | references/acceptance-criteria.md |
Given/When/Then格式 |
| 预发现子代理 | references/pre-discovery-subagents.md |
多领域功能需要前置上下文时 |
约束
必须做
- 使用
AskUserQuestions工具进行结构化引导（优先级、范围、格式选择） - 仅在无法预定义选择时使用开放式问题
- 在编写规格前进行彻底访谈
- 所有功能需求使用EARS格式
- 包含非功能需求（性能、安全性）
- 提供可测试的验收标准
- 包含实施待办检查清单
- 对模糊需求进行澄清询问
禁止做
- 当
AskUserQuestions可以提供结构化选项时，以纯文本形式输出访谈问题 - 未经访谈就生成规格
- 接受模糊需求（如“让它快一点”）
- 跳过安全考虑
- 忘记错误处理需求
- 编写不可测试的验收标准
输出模板
最终规格必须包含：
- 概述和用户价值
- 功能需求（EARS格式）
- 非功能需求
- 验收标准（Given/When/Then）
- 错误处理表
- 实施待办检查清单
内联EARS格式示例（加载references/ears-syntax.md获取完整语法）：
当<触发条件>时，<系统>应<响应>。
在<功能>激活的情况下，<系统>应<行为>。
<系统>应在<度量>内<动作>。
内联验收标准示例（加载references/acceptance-criteria.md获取完整格式）：
假设一个注册用户在登录页面，
当他们提交有效凭证时，
那么他们在2秒内被重定向到仪表盘。
保存为：specs/{feature_name}.spec.md
