Menu
基于用户需求为当前功能生成定制检查清单的专业工具。专门用于需求质量验证，生成"英语的单元测试"，验证需求的完整性、清晰度和一致性。触发词：speckit-checklist、检查清单、需求验证、质量检查、checklist、requirements validation、质量审查、spec review
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-checklist-zh |
| description | 基于用户需求为当前功能生成定制检查清单的专业工具。专门用于需求质量验证，生成"英语的单元测试"，验证需求的完整性、清晰度和一致性。触发词：speckit-checklist、检查清单、需求验证、质量检查、checklist、requirements validation、质量审查、spec review |
关键概念：检查表是要求编写的单元测试 - 它们验证特定领域中要求的质量、清晰度和完整性。
不用于验证/测试：
用于要求质量验证：
比喻：如果您的规格是编写的代码，那么检查表就是它的单元测试套件。您正在测试要求是否编写良好、完整、明确并准备好实施 - 而不是测试实现是否有效。
$ARGUMENTS
您必须在继续之前考虑用户输入（如果不为空）。
scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json
设置：从仓库根目录运行 {SCRIPT} 并解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS 列表。
澄清意图（动态）：推导出最多三个初始上下文澄清问题（无预设目录）。它们必须：
$ARGUMENTS 中已经明确，则单独跳过生成算法：
问题格式规则：
无法交互时的默认值：
输出问题（标记 Q1/Q2/Q3）。回答后：如果≥2 个场景类别（替代/异常/恢复/非功能性领域）仍不清楚，您可以要求最多两个更有针对性的后续问题（Q4/Q5），每个问题附带一行理由（例如，"未解决的恢复路径风险"）。不要超过五个总问题。如果用户明确拒绝更多问题则跳过升级。
理解用户请求：结合 $ARGUMENTS + 澄清答案：
加载功能上下文：从 FEATURE_DIR 读取：
上下文加载策略：
生成检查表 - 创建"要求的单元测试"：
FEATURE_DIR/checklists/ 目录ux.md, api.md, security.md）[domain].mdspeckit-checklist 运行创建一个新文件（从不覆盖现有检查表）核心原则 - 测试要求，而不是实现： 每个检查表项目必须评估要求本身：
类别结构 - 按要求质量维度分组项目：
如何编写检查表项目 - "英语的单元测试"：
❌ 错误（测试实现）：
✅ 正确（测试要求质量）：
项目结构： 每个项目应遵循此模式：
[Spec §X.Y][Gap] 标记检查缺失的要求按质量维度的示例：
完整性：
清晰度：
一致性：
覆盖范围：
可测量性：
场景分类和覆盖（要求质量重点）：
可追溯性要求：
[Spec §X.Y]，或使用标记：[Gap]、[Ambiguity]、[Conflict]、[Assumption]表面和解决问题（要求质量问题）： 询问有关要求本身的问题：
内容整合：
🚫 绝对禁止 - 这些使其成为实现测试，而不是要求测试：
✅ 必需模式 - 这些测试要求质量：
结构参考：按照 .specify/templates/checklist-template.md 中的规范模板生成检查表，包括标题、元部分、类别标题和 ID 格式。如果模板不可用，使用：H1 标题、目的/创建的元行、包含 - [ ] CHK### <要求项目> 行的 ## 类别部分，全局递增 ID 从 CHK001 开始。
报告：输出创建的检查表的完整路径、项目计数，并提醒用户每次运行都会创建一个新文件。总结：
重要：每个 speckit-checklist 命令调用都使用简短的描述性名称创建检查表文件，除非文件已存在。这允许：
ux.md, test.md, security.md）checklists/ 文件夹中轻松识别和导航为避免混乱，使用描述性类型并在完成后清理过时的检查表。
用户体验要求质量： ux.md
示例项目（测试要求，而不是实现）：
API 要求质量： api.md
示例项目：
性能要求质量： performance.md
示例项目：
安全要求质量： security.md
示例项目：
❌ 错误 - 这些测试实现，而不是要求：
- [ ] CHK001 - 验证着陆页显示 3 个剧集卡片 [Spec §FR-001]
- [ ] CHK002 - 测试桌面端悬停状态是否正确工作 [Spec §FR-003]
- [ ] CHK003 - 确认徽标点击导航到主页 [Spec §FR-010]
- [ ] CHK004 - 检查相关剧集部分显示 3-5 个项目 [Spec §FR-005]
✅ 正确 - 这些测试要求质量：
- [ ] CHK001 - 是否明确定义了特色剧集的数量和布局？ [完整性, Spec §FR-001]
- [ ] CHK002 - 是否为所有交互元素一致定义了悬停状态要求？ [一致性, Spec §FR-003]
- [ ] CHK003 - 是否为所有可点击品牌元素明确了导航要求？ [清晰度, Spec §FR-010]
- [ ] CHK004 - 是否记录了相关剧集的选择标准？ [Gap, Spec §FR-005]
- [ ] CHK005 - 是否为异步剧集数据定义了加载状态要求？ [Gap]
- [ ] CHK006 - 是否可以客观测量"视觉层次"要求？ [可测量性, Spec §FR-001]
主要区别：