Menu
基于用户需求为当前功能生成定制检查清单的专业工具。专门用于需求质量验证，生成"英语的单元测试"，验证需求的完整性、清晰度和一致性。触发词：speckit-checklist、检查清单、需求验证、质量检查、checklist、requirements validation、质量审查、spec review
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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]
主要区别：
归档已完成的变更并将规范差异合并到常驻文档。用于变更已部署、准备归档或实施后需要更新规范时。触发词包括 "openspec归档", "归档", "归档提案", "合并规范", "完成提案", "更新文档", "定稿规范", "标记完成"。
加载项目上下文，列出现有规范与变更，搜索能力与需求。用于用户询问项目状态、现有规范、进行中的变更、可用能力或需要发现上下文时。触发词包括"openspec上下文", "有哪些规范", "显示变更", "列出能力", "项目上下文", "查找规范", "规范包含什么", "展示规范"。
以测试与验证为先的方式，按序执行并实现已批准的规范提案。用于实施变更、应用提案、执行规范任务或按已批准计划构建。触发词包括 "openspec开发", "开发", "实施" "实现提案", "应用变更", "执行规范", "按顺序完成任务", "构建功能", "开始实施"。
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
从交互式或提供的原则输入创建或更新项目章程，确保所有依赖模板保持同步。用于项目管理、规范制定、章程维护和团队协作场景。触发词包括 "speckit章程"、"创建章程"、"更新章程"、"项目章程"、"制定规范"、"团队章程"。
执行实施规划工作流程，使用计划模板生成设计工件。触发词包括："speckit计划"。