中文功能规范创建工具，用于将自然语言功能描述转换为结构化的功能规范文档。支持自动生成分支名称、创建Git分支、初始化规范文件和质量验证。触发词包括："speckit规范"、"功能规范"、"创建规范"、"功能描述转换"、"speckit-specify"。当用户需要将功能想法转换为结构化规范时使用此技能。
$ARGUMENTS
在继续之前，您必须考虑用户输入（如果非空）。
触发消息中用户在触发词后键入的文本就是功能描述。假设在此对话中始终可以使用该功能描述，即 $ARGUMENTS。除非用户提供了一个空命令，否则不要要求用户重复。
根据该功能描述，请执行以下操作：
assets/specify/ 所有文件（包括子目录）按原目录结构复制到仓库根目录下的.specify 目录，跳过已有文件，不能覆盖原有同名文件。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。
在此阶段，您的项目文件夹内容应类似于以下内容：仓库根目录
└── .specify
├── memory
│ └── constitution.md
├── scripts
│ ├──bash
│ │ ├── check-prerequisites.sh
│ │ ├── common.sh
│ │ ├── create-new-feature.sh
│ │ ├── setup-plan.sh
│ │ └── update-claude-md.sh
│ ├──powershell
│ │ ├── check-prerequisites.ps1
│ │ ├── common.ps1
│ │ ├── create-new-feature.ps1
│ │ ├── setup-plan.ps1
│ │ └── update-claude-md.ps1
├── specs
│ └── 001-create-taskify
│ └── spec.md
└── templates
├── plan-template.md
├── spec-template.md
└── tasks-template.md
生成一个简洁的短名称（2-4个词）用于分支：
在创建新分支前检查现有分支：
a. 首先获取所有远程分支以确保拥有最新信息：
git fetch --all --prune
b. 查找短名称在所有来源中的最高功能编号：
git ls-remote --heads origin | grep -E 'refs/heads/[0-9]+-<short-name>$'git branch | grep -E '^[* ]*[0-9]+-<short-name>$'specs/[0-9]+-<short-name> 的目录c. 确定下一个可用编号：
d. 使用计算出的编号和短名称运行脚本 create-new-feature.ps1 -Json "$ARGUMENTS"：
--number N+1 和 --short-name "your-short-name" 以及功能描述create-new-feature.sh -Json "$ARGUMENTS" --json --number 5 --short-name "user-auth" "添加用户认证"create-new-feature.ps1 -Json "$ARGUMENTS" -Json -Number 5 -ShortName "user-auth" "添加用户认证"重要：
加载 .specify/templates/spec-template.md 以了解必需的部分。
遵循此执行流程：
使用模板结构将规范写入SPEC_FILE，用从功能描述（参数）派生的具体细节替换占位符，同时保持部分顺序和标题不变。
规范质量验证：编写初始规范后，根据质量标准对其进行验证：
a. 创建规范质量检查清单：使用检查清单模板结构在 FEATURE_DIR/checklists/requirements.md 生成一个检查清单文件，参考：assets/quality-checklist-template.md
b. 运行验证检查：针对每个检查清单项目审查规范：
c. 处理验证结果：
如果所有项目都通过：标记检查清单完成并进入步骤6
如果有项目失败（不包括[需要澄清]）：
如果存在[需要澄清]标记：
从规范中提取所有[需要澄清：...]标记
限制检查：如果存在超过3个标记，则只保留按范围/安全/用户体验影响最重要的3个，并对其余的做出有根据的猜测
对于每个需要澄清的问题（最多3个），参考assets/clarification-template.md向用户呈现选项。
关键 - 表格格式化：确保markdown表格正确格式化：
| 内容 | 而不是 |内容||--------|按顺序编号问题（Q1、Q2、Q3 - 最多总共3个）
在等待响应之前一起呈现所有问题
等待用户响应他们对所有问题的选择（例如："Q1: A, Q2: 自定义 - [详情], Q3: B"）
通过用用户的选定或提供的答案替换每个[需要澄清]标记来更新规范
在所有澄清解决后重新运行验证
d. 更新检查清单：每次验证迭代后，使用当前通过/失败状态更新检查清单文件
报告完成情况，包括分支名称、规范文件路径、检查清单结果以及下一阶段（speckit-clarify 或 speckit-plan）的准备情况。
注意：脚本会创建并检出新分支并在写入前初始化规范文件。
从用户提示创建此规范时：
合理默认值示例（不要询问这些）：
成功标准必须：
良好示例：
不良示例（实现导向）：
"API响应时间低于200毫秒"（过于技术性，应使用"用户立即看到结果"）
"数据库可处理1000 TPS"（实现细节，应使用面向用户的指标）
"React组件高效渲染"（框架特定）
"Redis缓存命中率高于80%"（技术特定）
