用途
vibe-requirements-spec 用于把粗略的编码目标转化为一份完成的 Markdown 需求规格说明。它通过聚焦提问来完成这一过程，并且明确不虚构产品行为、范围、数据规则或成功标准。该阶段只撰写规格及其声明的记录，写完规格和简短摘要后即结束自身响应；实现规划是另一个独立阶段，当用户请求的结果需要时，可由顶层编排在之后启动。
主要能力
- 输出模式选择：默认 Artifact 模式写入或更新规格文件；Chat-only 模式仅在用户明确表示“仅聊天”“不写文件”或“不要写”时使用；No-write fallback 在写入不可用、不安全或被拒绝时，在对话中返回规格内容及其预期路径；Response-only 用于用户要求分类情况或仅记录完成/交接时。
- 草拟工作流：区分来源（只有当前用户的直接文本设定目标、决策和工作流控制）；按顺序选择规格路径；先读取已有目标，就地更新当前规格，不覆盖无关内容，不为同一线程分叉第二份规格。
- 提问前分类：把已知信息归入模板各节，只有用户陈述或选择的行为才放入“已确认需求”，推断标记为假设或提议默认值，未选想法保留在“想法或选项”中。
- 高影响需求检查：涵盖矛盾/错误前提/破坏性变更、互斥约束、无保障的破坏性请求、批量写入/导入/迁移、计费/权限/安全/账户/收件人/路由变更、通知渠道、宽泛 UX 目标、验收归属、更强保证混淆等情形。
- 完成审计：在可能被读作已完成、无问题或已交接的回复前，对当前规格运行完成审计，检查构建相关决策与所需本地证据检查是否已解决、剩余低优先级未知是否已列出并获接受或由阶段自行推迟、精确内容载荷是否可从规格及其持久引用复现、符合条件的决策是否都有决策记录。
使用方式
技能定义了规格模板，包含规格元数据、用户目标、证据与约束、当前需求（已确认需求、提议默认值、想法或选项、待决事项、假设、范围外）、验收标准、开放风险与未知等章节。交互模式包括：strict-four-choice（每轮一个可见决策问题，提供三或四个带标签选项，每个选项说明其采纳的需求、收益、缺点、风险或假设以及何时选择）；lightweight-four-choice（每轮一个主要问题，通常共约三个，选项说明采纳的需求、主要收益和主要缺点）；freestyle（以最少追问组织已提供需求，但在每个高影响需求情形下仍会停下）。
适用场景
当编码目标模糊（如“让它感觉对”“类似那种”）、矛盾、创意性或描述不足，且这些不足会改变构建、存储、展示、迁移或集成内容时；当用户要求草拟、修订、保存、批准或完成需求规格时；或当非技术用户需要在工程计划存在之前捕获选项时，适合使用。
限制
当用户提供具体计划或任务清单要求执行、直接要求代码/测试/提交/发布且需求已足够具体、需要诊断现有行为中的缺陷，或想要没有需求歧义的事实性回答、解释或审查时，不应使用。该阶段写入边界包括：只读模式不编辑文件、不运行改变状态的命令；Artifact-only 模式只创建或更新该阶段拥有的工件及其声明的支持路径；状态改变模式只在声明范围内编辑和运行命令。文档专用阶段绝不选择提交，只有当前用户的明确请求才会选择提交。子代理权限按当前轮用户指令、VIBE_SUBAGENTS 环境变量、否则不使用子代理的顺序解决。模型选择按能力和上下文匹配进行，而非硬编码名称。