Menu
SRS 文档不存在且无设计文档时使用 — 通过结构化追问产出高质量需求规格说明书，对齐 ISO/IEC/IEEE 29148
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
启动 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