Menu
中文功能规范创建工具，用于将自然语言功能描述转换为结构化的功能规范文档。支持自动生成分支名称、创建Git分支、初始化规范文件和质量验证。触发词包括："speckit规范"、"功能规范"、"创建规范"、"功能描述转换"、"speckit-specify"。当用户需要将功能想法转换为结构化规范时使用此技能。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
归档已完成的变更并将规范差异合并到常驻文档。用于变更已部署、准备归档或实施后需要更新规范时。触发词包括 "openspec归档", "归档", "归档提案", "合并规范", "完成提案", "更新文档", "定稿规范", "标记完成"。
加载项目上下文，列出现有规范与变更，搜索能力与需求。用于用户询问项目状态、现有规范、进行中的变更、可用能力或需要发现上下文时。触发词包括"openspec上下文", "有哪些规范", "显示变更", "列出能力", "项目上下文", "查找规范", "规范包含什么", "展示规范"。
以测试与验证为先的方式，按序执行并实现已批准的规范提案。用于实施变更、应用提案、执行规范任务或按已批准计划构建。触发词包括 "openspec开发", "开发", "实施" "实现提案", "应用变更", "执行规范", "按顺序完成任务", "构建功能", "开始实施"。
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
从交互式或提供的原则输入创建或更新项目章程，确保所有依赖模板保持同步。用于项目管理、规范制定、章程维护和团队协作场景。触发词包括 "speckit章程"、"创建章程"、"更新章程"、"项目章程"、"制定规范"、"团队章程"。
执行实施规划工作流程，使用计划模板生成设计工件。触发词包括："speckit计划"。
| name | speckit-specify-zh |
| description | 中文功能规范创建工具，用于将自然语言功能描述转换为结构化的功能规范文档。支持自动生成分支名称、创建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%"（技术特定）