sdd-checklist

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Requirements quality checklist

需求质量检查清单

--strict

validation proves a spec is well-FORMED; it doesn't prove it's well-SPECIFIED. This skill generates a tailored checklist and grades the change against it, so gaps in clarity or coverage surface before code — not in review.

--strict

验证只能证明规范格式正确，但无法证明其内容规范合理。本技能会生成一份定制化的检查清单，并根据清单对变更进行评估，从而在代码编写前（而非代码审查阶段）发现清晰度或覆盖范围方面的漏洞。

When to use

使用场景

At the
```
sdd-feature-flow
```
human approval gate, to decide whether to approve the spec.
Before
```
/opsx:apply
```
or launching implementation on any non-trivial change.

在
```
sdd-feature-flow
```
人工批准环节，用于决定是否批准该规范。
在执行
```
/opsx:apply
```
或启动任何非微小变更的实施之前。

Procedure

流程步骤

Read the change:
```
openspec/changes/<id>/proposal.md
```
,
```
design.md
```
,
```
tasks.md
```
, and the delta spec(s); plus
```
openspec/project.md
```
(the constitution) if present.
Generate the checklist, tailored to what this change touches. Cover at least:
- Completeness — is every stated requirement addressed by the design AND the tasks? Are error/empty/edge cases specified, not just the happy path? Are non-goals explicit?
- Clarity — is each requirement testable and unambiguous (SHALL/MUST, concrete values)? Any "should probably / TBD / etc." that hides a real decision?
- Consistency — do proposal, design, tasks and delta agree? Any contradiction in scope, data model, or naming? Does anything violate the constitution?
- Testability — does each requirement have a scenario or a task that would fail if the requirement were unmet? Is the verification path concrete?
- Assumptions — is every load-bearing assumption either confirmed or flagged as an open question (NOT silently baked in)?
Grade each item pass / fail / n-a with a one-line reason, and list the fails first.
Recommend: approve as-is, approve with the listed fixes, or send back for revision.

阅读变更内容：查看
```
openspec/changes/<id>/proposal.md
```
、
```
design.md
```
、
```
tasks.md
```
以及增量规范文件；若存在
```
openspec/project.md
```
（章程文件）也需一并查看。
生成定制化检查清单：根据变更涉及的内容生成清单，至少涵盖以下方面：
- 完整性——所有明确提出的需求是否都在设计和任务中得到了体现？是否指定了错误/空值/边缘情况，而非仅考虑正常流程？是否明确列出了非目标内容？
- 清晰度——每项需求是否可测试且无歧义（使用SHALL/MUST等明确表述，包含具体数值）？是否存在诸如“可能应该/待定/等”这类回避实际决策的表述？
- 一致性——提案、设计、任务和增量内容是否一致？在范围、数据模型或命名方面是否存在矛盾？是否有内容违反章程规定？
- 可测试性——每项需求是否有对应的场景或任务，当需求未满足时该场景或任务会失败？验证路径是否具体明确？
- 假设条件——所有关键假设是否已得到确认或标记为待解决问题（而非默认隐含）？
为每个检查项评分：通过/不通过/不适用，并附上一行理由，且优先列出不通过的项。
给出建议：直接批准、修复列出的问题后批准，或退回修改。

Output

输出结果

A compact table (item · verdict · reason), fails first, then a one-line recommendation. Read-only — this skill changes no files; it produces the checklist and the verdict.

一份简洁的表格（检查项 · 结论 · 理由），优先展示不通过的项，随后附上一行建议。本技能为只读模式——不会修改任何文件；仅生成检查清单和评估结论。