Menu
SRS 文档不存在且无设计文档时使用 — 通过结构化追问产出高质量需求规格说明书，对齐 ISO/IEC/IEEE 29148
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
启动 VibeFlow 本地看板，实时查看阶段、功能、产物和最近事件。
查看 VibeFlow 项目当前状态（阶段、进度、待处理项）。
VibeFlow框架入口。运行 /vibeflow 开始新项目或继续现有工作流。
测试阶段的真实浏览器验证底座。用于页面交互、表单、路由、前端 API、视觉状态和运行时问题验证。优先使用 Playwright MCP 做真实交互验证，使用 Chrome DevTools MCP 做运行时诊断；MCP 不可用时回退到本地 Playwright CLI 脚本。
在此仓库中用于在会话开始时路由整个VibeFlow生命周期的工作。
系统测试通过后且工作流要求 UI QA 时使用 — 运行浏览器导向的 QA 验证并生成报告
| name | vibeflow-requirements |
| description | SRS 文档不存在且无设计文档时使用 — 通过结构化追问产出高质量需求规格说明书，对齐 ISO/IEC/IEEE 29148 |
将原始想法转化为结构化、高质量的软件需求规格说明书 (SRS)，通过系统化的获取、质疑和验证流程 — 对齐 ISO/IEC/IEEE 29148 和 EARS 需求语法。
在你展示 SRS 并获得用户批准之前，不得调用任何设计技能、实现技能、编写任何代码、搭建任何项目，也不得采取任何设计/实现行动。无论项目多简单，此规则适用于每个项目。每个项目都需要经过此流程。一个待办列表、一个单函数工具、一个配置变更 — 全部如此。"简单"项目恰恰是未经审查的假设造成最多浪费的地方。SRS 可以很短（真正简单的项目几句话即可），但你必须展示它并获得批准。
你必须按顺序完成以下步骤：
docs/changes/<change-id>/requirements.md 并提交vibeflow-design（含 UCD 内联，如需）终止状态是进入 vibeflow-design。 不要调用其他阶段。
python scripts/get-vibeflow-paths.py --json，读取 docs/changes/<change-id>/brief.md 获取问题定义和边界.vibeflow/workflow.yaml 了解所选模板的严格度级别python scripts/map-change-impact.py --project-root . --source requirements，读取：
docs/overview/CURRENT-STATE.mddocs/templates/srs-template.md.md 文件且至少包含一个 ## 标题使用 AskUserQuestion 以分轮多问题方式获取需求 — 每轮涵盖一个主题领域，最多 4 个相关问题。对每个领域遵循 捕获 -> 质疑 -> 澄清 循环。
提问方式：
AskUserQuestion 调用获取轮次（根据项目上下文调整顺序和分组）：
单次 AskUserQuestion 调用（最多 4 个问题）：
对每个能力域，每轮问（最多 4 个问题）：
相关能力共享工作流时合并到同一轮。大的能力域拆分到多轮。
按相关性分 1-2 轮批量探测 NFR：
| 类别（ISO 25010） | 探测 |
|---|---|
| 性能 | 响应时间目标？吞吐量？并发用户？ |
| 可靠性 | 可用性目标？恢复时间？数据丢失容忍度？ |
| 易用性 | 无障碍要求？可学习性标准？ |
| 安全性 | 认证方式？授权模型？数据加密？ |
| 可维护性 | 模块化约束？测试覆盖率目标？ |
| 可移植性 | 平台限制？浏览器支持？ |
| 可扩展性 | 当前负载？目标负载？增长时间线？ |
跳过明显不相关的类别。规则：每个 NFR 必须有可度量的标准。"快" -> "在 1000 并发用户下 p95 响应时间 < 200ms"。
合并为一轮（最多 4 个问题）：
必要时问一轮：
何时停止： 当你能描述每个功能能力、其验收标准、所有带可度量阈值的 NFR、所有约束和假设 — 无需猜测时，进入步骤 3。
将捕获的需求组织到以下类别：
| 类别 | ID 前缀 | 描述 |
|---|---|---|
| 功能 | FR-001 | 可观测的系统行为 |
| 非功能 | NFR-001 | 带可度量标准的质量属性 |
| 约束 | CON-001 | 限制解决方案空间的硬限制 |
| 假设 | ASM-001 | 假定为真的信念；记录失效风险 |
| 接口 | IFR-001 | 外部系统契约 |
| 排除 | EXC-001 | 明确不在范围内 |
对每个功能需求应用 EARS（Easy Approach to Requirements Syntax）模板：
| 模式 | 模板 | 适用场景 |
|---|---|---|
| 普遍性 | 系统应当 <动作>。 | 始终有效的行为 |
| 事件驱动 | 当 <触发条件> 时，系统应当 <动作>。 | 响应用户/系统事件 |
| 状态驱动 | 当处于 <状态> 时，系统应当 <动作>。 | 行为依赖模式/状态 |
| 异常行为 | 如果 <条件>，则系统应当 <动作>。 | 错误处理、容错 |
| 可选 | 当 <功能/配置> 启用时，系统应当 <动作>。 | 可配置/可选能力 |
对每个需求还需编写：
对于现有项目改动，必须把 CURRENT-STATE.md 中“当前变更关注点”的结果吸收到需求文档中，至少明确：
Current StateAffected AreasOut of Scope对照 8 项质量属性（IEEE 830 / ISO 29148）运行系统化质量检查：
对每个需求验证：
| # | 属性 | 检查 | 红线信号 |
|---|---|---|---|
| 1 | 正确 | 追溯到已确认的干系人需求？ | 孤立需求（镀金） |
| 2 | 无歧义 | 两个读者会写出相同的测试用例？ | 模糊词："快"、"健壮"、"用户友好"、"直觉"、"灵活" |
| 3 | 完整 | 所有输入、输出、错误情况、边界已定义？ | "包括但不限于..."、无界列表 |
| 4 | 一致 | 与其他需求无矛盾？ | 时间冲突、格式冲突 |
| 5 | 有排序 | 有 MoSCoW 优先级？ | 所有都是"高优先级" |
| 6 | 可验证 | 能写出通过/失败测试？ | "系统应易于使用"（无指标） |
| 7 | 可修改 | 在且仅在一处表述？ | 跨章节重复 |
| 8 | 可追溯 | 有唯一 ID + 来源链接？ | 缺少 ID 或孤立 |
在展示前扫描完整 SRS 中的这些反模式并修复：
| 反模式 | 检测信号 | 修复 |
|---|---|---|
| 模糊形容词 | "快"、"大"、"可扩展"、"可靠" 无数字 | 用可度量标准量化 |
| 复合需求 | "和"/"或"连接两个不同能力 | 拆分为独立需求 |
| 设计泄露 | 实现词汇："类"、"表"、"端点"、"算法" | 重写为可观测行为 |
| 无主体被动语态 | "数据应被验证" — 谁来验证？ | 添加明确主体："系统应..." |
| TBD / TBC | 未解决占位符 | 与用户解决或标记为开放问题 |
| 缺少否定 | 仅指定正面情况 | 添加错误/边界/安全情况 |
| 不可测 NFR | NFR 无可度量阈值 | 添加具体指标 + 度量方法 |
对非简单项目，逐节展示并获得审批：
逐节展示。等待用户反馈。整合变更后再进入下一节。
简单项目（< 5 个功能需求）：合并所有章节为单次审批步骤。
将审批通过的 SRS 保存到 docs/changes/<change-id>/requirements.md。
读取步骤 1 中找到的模板：
Date、Status、Standard、Template 路径）SRS 文档保存并提交后：
vibeflow-design| 项目规模 | 功能需求数 | 深度 |
|---|---|---|
| 微型 | 1-5 | 单页 SRS，合并审批步骤 |
| 小型 | 5-15 | 标准 SRS，2-3 个审批章节 |
| 中型 | 15-50 | 完整 SRS 含所有章节，逐节审批 |
| 大型 | 50-200+ | 完整 SRS + 接口规格 + 领域模型 |
| 合理化借口 | 正确响应 |
|---|---|
| "太简单不需要 SRS" | 运行轻量 SRS（单次审批步骤） |
| "用户已经描述了他想要的" | 用户描述是原始输入；SRS 添加结构、完整性、可测试性 |
| "我可以在设计时弄清需求" | 需求定义 WHAT；在 HOW 中发现它们会导致返工 |
| "NFR 不适用于此项目" | 每个项目至少有隐含的性能/可靠性需求 — 使其显式 |
| "术语表是显而易见的" | 对谁显而易见？定义用户和开发者可能有不同理解的每个术语 |
| "我先从正常路径开始" | 错误情况、边界和否定场景必须现在捕获 |
调用者： vibeflow-router（requirements 阶段）
链接到： vibeflow-design（SRS 审批后）
产出： docs/changes/<change-id>/requirements.md