メニュー
中文功能规范创建工具，用于将自然语言功能描述转换为结构化的功能规范文档。支持自动生成分支名称、创建Git分支、初始化规范文件和质量验证。触发词包括："speckit规范"、"功能规范"、"创建规范"、"功能描述转换"、"speckit-specify"。当用户需要将功能想法转换为结构化规范时使用此技能。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
归档已完成的变更并将规范差异合并到常驻文档。用于变更已部署、准备归档或实施后需要更新规范时。触发词包括 "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%"（技术特定）