specify

用户输入

$ARGUMENTS

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

语言要求

• 所有面向用户的生成内容，包括 spec.md、检查清单、澄清问题、摘要和状态报告，都必须使用简体中文。
• 分支名、文件路径、ID 和其他机器导向标识在兼容性需要时保持 ASCII。
• 如果用户提供英文术语，应在必要时保留原词，并以中文补充说明。

概述

用户在触发消息中 /speckit.specify 后输入的文本就是功能描述。即使下面字面显示 {ARGS}，也应假设你始终可以在本次对话中访问该描述。除非用户输入为空，否则不要要求用户重复描述。

基于该功能描述，请执行以下操作：

1. 为功能生成简洁的短名称（2-4 个单词），作为分支名：

   • 当用户使用中文描述需求时，根据功能含义生成对应的 ASCII 短名称；分支名不得包含中文字符
   • 分析功能描述，提取最有意义的关键词
   • 创建一个 2-4 个单词的短名称，概括功能要点
   • 尽量采用"动词-名词"格式（如 add-user-auth、fix-payment-bug）
   • 保留技术术语和缩写（OAuth2、API、JWT 等）
   • 名称应简洁，同时足以让人一眼理解功能含义
   • 示例：
     • "我想添加用户身份验证" → user-auth
     • "Implement OAuth2 integration for the API" → oauth2-api-integration
     • "创建分析仪表板" → analytics-dashboard
     • "修复支付处理超时 Bug" → fix-payment-timeout

2. 创建功能分支：运行脚本时传入 --short-name（以及 --json），不要传入 --number（脚本会自动检测全局下一个可用编号）：

   • Bash 示例：{SCRIPT} --json --short-name "user-auth" "Add user authentication"
   • PowerShell 示例：{SCRIPT} -Json -ShortName "user-auth" "Add user authentication"

   重要说明：

   • 不要传入 --number — 脚本会自动确定正确的下一个编号
   • 始终包含 JSON 标志（Bash 用 --json，PowerShell 用 -Json），以便可靠地解析输出
   • 每个功能只运行一次此脚本
   • JSON 输出包含 BRANCH_NAME 和 SPEC_FILE 路径，始终参考这些路径获取实际内容
   • 对于包含单引号的参数（如 "I'm Groot"），使用转义语法：'I'\''m Groot'（或尽可能使用双引号）

3. 加载 templates/spec-template.md 以了解所需章节结构。

4. 遵循以下执行流程：

   1. 从用户输入中解析功能描述 若为空：报错"未提供功能描述"
   2. 从描述中提取关键概念 识别：参与者、操作、数据、约束条件
   3. 对于不明确的内容：
      • 基于上下文和行业惯例做出合理推断
      • 仅在以下情况下标记 [NEEDS CLARIFICATION: 具体问题]：
        • 该选择对功能范围或用户体验有重大影响
        • 存在多种合理解读，且各自有不同含义
        • 没有合理的默认值
      • 限制：最多 3 个 [NEEDS CLARIFICATION] 标记
      • 按影响程度排列澄清优先级：范围 > 安全/隐私 > 用户体验 > 技术细节
   4. 填写用户场景与测试章节 若无法确定用户流程：报错"无法确定用户场景"
   5. 生成功能需求 每条需求必须可测试 对未明确的细节使用合理默认值（在"假设"章节中记录）
   6. 定义成功标准 创建可量化、与技术无关的结果指标 同时包含定量指标（时间、性能、数量）和定性指标（用户满意度、任务完成率） 每条标准无需了解实现细节即可验证
   7. 识别关键实体（如涉及数据）
   8. 返回：成功（规范已可进入规划阶段）