specify

name	specify
description	从自然语言功能描述创建或更新功能规格说明。
disable-model-invocation	true
allowed-tools	["Bash(node */create-new-feature.mjs*)"]

用户输入

$ARGUMENTS

你必须在继续之前考虑用户输入（如果不为空）。

大纲

用户在触发消息中 /specify 后输入的文本就是功能描述。假设你在此对话中始终可以使用它，即使 $ARGUMENTS 在下面显示为字面值。除非用户提供空命令，否则不要要求用户重复。

根据该功能描述，执行以下操作：

1. 生成简短的分支名称（2-4个词）：

   • 分析功能描述并提取最有意义的关键词
   • 创建一个 2-4 个词的短名称来概括功能的本质
   • 尽可能使用"动词-名词"格式（例如 "add-user-auth"、"fix-payment-bug"）
   • 保留技术术语和缩写（OAuth2、API、JWT 等）
   • 保持简洁但足够描述性，以便一目了然地理解功能
   • 示例：
     • "我想添加用户认证" → "user-auth"
     • "为 API 实现 OAuth2 集成" → "oauth2-api-integration"
     • "创建分析仪表板" → "analytics-dashboard"
     • "修复支付处理超时错误" → "fix-payment-timeout"

2. 从仓库根目录运行脚本 node ${WAVE_PLUGIN_ROOT}/scripts/create-new-feature.mjs --json "$ARGUMENTS" 带上短名称参数，并解析其 JSON 输出获取 BRANCH_NAME 和 SPEC_FILE。所有文件路径必须是绝对路径。

   重要：

   • 将你在步骤 1 中创建的 2-4 个词的短名称追加到 node ${WAVE_PLUGIN_ROOT}/scripts/create-new-feature.mjs --json "$ARGUMENTS" 命令中
   • Bash：--short-name "your-generated-short-name"
   • PowerShell：-ShortName "your-generated-short-name"
   • 对于参数中的单引号如 "I'm Groot"，使用转义语法：例如 'I'''m Groot'（或尽可能使用双引号："I'm Groot"）
   • 你只能运行此脚本一次
   • JSON 作为输出在终端中提供——始终参考它获取你需要的实际内容

3. 加载 !node -e "console.log(require('path').resolve('${WAVE_PLUGIN_ROOT}/templates/spec-template.md'))" 以了解必需的章节。

4. 按照此执行流程：

   1. 从输入解析用户描述 如果为空：错误 "未提供功能描述"
   2. 从描述中提取关键概念 识别：参与者、操作、数据、约束
   3. 对于不明确的方面：
      • 根据上下文和行业标准做出合理推断
      • 仅在以下情况下标记 [需要澄清：具体问题]：
        • 该选择显著影响功能范围或用户体验
        • 存在多种合理解读，含义不同
        • 不存在合理的默认值
      • 限制：总共最多 3 个 [需要澄清] 标记
      • 按影响优先级排序澄清：范围 > 安全/隐私 > 用户体验 > 技术细节
   4. 填写用户场景与测试章节 如果没有明确的用户流程：错误 "无法确定用户场景"
   5. 生成功能需求 每个需求必须是可测试的 对未指定的细节使用合理的默认值（在假设章节记录假设）
   6. 识别关键实体（如果涉及数据）
   7. 返回：成功（规格已准备好进行规划）

5. 使用模板结构将规格说明写入 SPEC_FILE，用从功能描述（参数）派生的具体细节替换占位符，同时保留章节顺序和标题。

6. 规格质量验证：编写初始规格后，根据质量标准进行验证：

   a. 创建规格质量检查清单：使用检查清单模板结构在 FEATURE_DIR/checklists/requirements.md 生成检查清单文件，包含以下验证项目：

   # 规格质量检查清单：[功能名称]
   
   **目的**：在进入规划阶段之前验证规格说明的完整性和质量
   **创建日期**：[日期]
   **功能**：[../spec.md]
   
   ## 内容质量
   
   - [ ] 无实现细节（语言、框架、API）
   - [ ] 聚焦于用户价值和业务需求
   - [ ] 面向非技术利益相关者编写
   - [ ] 所有必需章节已完成
   
   ## 需求完整性
   
   - [ ] 无 [需要澄清] 标记残留
   - [ ] 需求可测试且无歧义
   - [ ] 所有验收场景已定义
   - [ ] 边界情况已识别
   - [ ] 范围边界清晰
   - [ ] 依赖和假设已识别
   
   ## 功能就绪性
   
   - [ ] 所有功能需求有明确的验收标准
   - [ ] 用户场景覆盖主要流程
   - [ ] 规格说明中无实现细节泄露
   
   ## 备注
   
   - 标记为未完成的项目需要在 `/clarify` 或 `/plan` 之前更新规格
   

   b. 运行验证检查：根据每个检查清单项目审查规格：

   • 对于每个项目，确定通过还是失败
   • 记录发现的具体问题（引用相关规格章节）

   c. 处理验证结果：

   • 如果所有项目通过：标记检查清单完成并继续步骤 6

   • 如果项目失败（不包括 [需要澄清]）：

     1. 列出失败项目和具体问题
     2. 更新规格以解决每个问题
     3. 重新运行验证直到所有项目通过（最多 3 次迭代）
     4. 如果 3 次迭代后仍然失败，在检查清单备注中记录剩余问题并警告用户

   • 如果 [需要澄清] 标记残留：

     1. 从规格中提取所有 [需要澄清：...] 标记

     2. 限制检查：如果超过 3 个标记，只保留 3 个最关键的（按范围/安全/用户体验影响排序），其余做出合理推断

     3. 对于每个需要的澄清（最多 3 个），以此格式向用户展示选项：

        ## 问题 [N]：[主题]
        
        **上下文**：[引用相关规格章节]
        
        **需要了解**：[来自需要澄清标记的具体问题]
        
        **建议答案**：
        
        | 选项 | 答案 | 影响 |
        |------|------|------|
        | A    | [第一个建议答案] | [这对功能意味着什么] |
        | B    | [第二个建议答案] | [这对功能意味着什么] |
        | C    | [第三个建议答案] | [这对功能意味着什么] |
        | 自定义 | 提供你自己的答案 | [解释如何提供自定义输入] |
        
        **你的选择**：_[等待用户响应]_
        

     4. 关键 - 表格格式：确保 markdown 表格格式正确：

        • 使用一致的间距，竖线对齐
        • 每个单元格内容周围应有空格：| 内容 | 而不是 |内容|
        • 表头分隔符必须至少有 3 个破折号：|--------|
        • 测试表格在 markdown 预览中正确渲染

     5. 按顺序编号问题（Q1、Q2、Q3 - 最多共 3 个）

     6. 在等待响应之前一起展示所有问题

     7. 等待用户回复所有问题的选择（例如，"Q1: A, Q2: 自定义 - [详情], Q3: B"）

     8. 通过将每个 [需要澄清] 标记替换为用户选择或提供的答案来更新规格

     9. 所有澄清解决后重新运行验证

   d. 更新检查清单：每次验证迭代后，使用当前通过/失败状态更新检查清单文件

7. 报告完成情况，包括分支名称、规格文件路径、检查清单结果以及下一阶段的就绪状态（/clarify 或 /plan）。

注意： 脚本会创建并检出新分支，并在写入之前初始化规格文件。

通用准则

快速准则

• 聚焦于用户需要什么以及为什么。
• 避免如何实现（无技术栈、API、代码结构）。
• 面向业务利益相关者而非开发者编写。
• 不要创建嵌入在规格中的检查清单。那将是一个单独的命令。

章节要求

• 必需章节：每个功能都必须完成
• 可选章节：仅在相关于功能时包含
• 当章节不适用时，完全删除它（不要保留为"不适用"）

AI 生成

从用户提示创建此规格时：

1. 做出合理推断：使用上下文、行业标准和常见模式填补空白
2. 记录假设：在假设章节记录合理的默认值
3. 限制澄清：最多 3 个 [需要澄清] 标记——仅用于以下关键决策：
   • 显著影响功能范围或用户体验
   • 有多种合理解读，含义不同
   • 缺乏任何合理的默认值
4. 优先级排序澄清：范围 > 安全/隐私 > 用户体验 > 技术细节
5. 像测试人员一样思考：每个模糊的需求都应该无法通过"可测试且无歧义"的检查清单项目
6. 常见需要澄清的领域（仅在没有合理默认值时）：
   • 功能范围和边界（包含/排除特定用例）
   • 用户类型和权限（如果存在多种冲突的解读）
   • 安全/合规要求（当涉及法律/财务重要性时）

合理默认值示例（不要询问这些）：

• 数据保留：领域的行业标准做法
• 性能目标：标准 Web/移动应用预期，除非另有说明
• 错误处理：用户友好的消息和适当的回退
• 认证方式：Web 应用的标准基于会话或 OAuth2
• 集成模式：RESTful API，除非另有说明