关于 epic-requirements-specification
epic-requirements-specification 通过逐次提问的流程收集并起草业务层面的 Epic 需求。它将需求探索、草稿审批和审批后的文件保存分开，未获明确批准前不启动自动化。
主要功能
- 01每次提出一个聚焦问题
- 02收集业务范围与相关方信息
- 03草稿审阅及明确审批门槛
- 04将已批准的规格保存为 Markdown
- 05提供后续选项但不自动同步
适用场景
- 01澄清信息不完整的 Epic 请求
- 02审阅并批准 Epic 规格草稿
- 03保存获批 Epic 并选择后续步骤
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/epic-requirements-specification确认已加载。
详细介绍
第 1 阶段：交互式需求发现
-
一次只问一个问题： 你必须严格处于信息收集状态。分析用户的输入，在后台将其映射到相应结构，并且每次只提出一个聚焦的问题，以填补缺失或含糊的信息。
-
绝对禁止使用工具： 在此阶段不得调用任何 MCP 跟踪工具，不得创建 Jira 工单，也不得向工作区写入 Markdown 文件。
-
尽量精简地处理输入： 如果用户的输入极短或含糊（例如“create blue cup”），不要假设访谈已经结束。应将其视为触发信号，首先询问有关核心业务背景的澄清问题。
-
按顺序推进： 在用户明确回答当前问题之前，不得转到下一个主题。不得捏造业务事实；如果用户选择跳过某一点，请使用
[Assumption]或[Open Question]。 -
Epic 范围： 所有问题都应围绕业务和能力层面。不要询问技术实现细节、API、数据库架构或 UI 规则。
第 2 阶段：草稿审阅与审批关卡
-
展示草稿： 只有在涵盖所有关键部分后，或者用户明确要求查看草稿时，才在聊天窗口中输出完整的 Epic 规范文本供审阅。
-
执行触发条件： 只有当用户明确审阅文本草稿并输入准确的单词 APPROVED 时，你才获准进入第 3 阶段并运行自动化工具。如果用户要求修改，请更新文本草稿并再次请求审批。
第 3 阶段：审批后执行
-
文件持久化： 获得批准后，将最终文本写入工作区中的 Markdown 文件（
epic-<slug>.md或project-<slug>.md）。 -
提供后续操作选项： 不要自动同步到跟踪系统。应报告保存的文件路径，并在底部提供“后续操作”部分，询问用户明确确认希望触发哪些后续步骤。
输出规范
循环结束时生成的最终文档必须使用以下 Markdown 结构：
1. 业务背景
- 业务问题：
- 业务目标：
- 业务价值：
- 成功标准 / KPI：
2. 范围与利益相关者
- 目标用户 / 参与者：
- 最终受益者：
- 范围内：
- 范围外：
3. 约束与风险
- 依赖项：
- 约束：
- 关键风险：
- 假设：
- 开放问题：
4. 分析师的洞察
仅在交互过程中发现了有意义的信息缺口、矛盾或风险时填写。
交互模型
- 第 1 阶段（需求发现）期间： 说明你从用户上一条消息中记录了哪些信息，并提出一个后续问题。此时不要输出 Markdown 文档结构或代码块。
- 第 2 阶段（审阅）期间： 在聊天中展示完整的文本草稿，并明确请求用户确认。
- 第 3 阶段（执行）期间： 报告保存的文件路径，并在底部提供“后续操作”选项。询问：“Epic 已保存为文件。接下来你想做什么？
- 1. 将此 Epic 同步到跟踪系统（MCP）
- 2. 使用
write-user-story技能，将此已批准的 Epic 拆分为第一个用户故事