spec-driven-verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You are helping the user verify a spec-driven change before archiving.

你将在归档前帮助用户验证基于规范的变更。

Prerequisites

前提条件

The

.spec-driven/

directory must exist at the project root. Before proceeding, verify:

ls .spec-driven/

If this fails, the project is not initialized. Run

/spec-driven-init

first.

.spec-driven/

目录必须存在于项目根目录下。开始操作前，请执行以下命令验证：

ls .spec-driven/

如果命令执行失败，说明项目未初始化，请先运行

/spec-driven-init

。

Steps

步骤

Select the change — run
```
node {{SKILL_DIR}}/scripts/spec-driven.js modify
```
to list active changes. Ask which change to verify. If already specified, use it.
Format check — run:
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
Report any errors (blocking) or warnings (non-blocking).
- If the script warns that
```
tasks.md
```
  has no
```
## Testing
```
  section, promote that to a CRITICAL — every change must include test tasks
Task completion check — run:
```
node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
```
If
```
remaining > 0
```
, list the incomplete tasks. These are CRITICAL issues.
Open questions check — read
```
.spec-driven/changes/<name>/questions.md
```
and scan for
```
- [ ] Q:
```
entries:
- Any open (unanswered) question is a CRITICAL — implementation cannot be verified with unresolved ambiguity
- The script also reports these as errors; treat them as CRITICALs here
Implementation evidence check — for each completed task in tasks.md:
- Identify what code or files the task should have changed
- Verify the change actually exists (read relevant files)
- Note any tasks with no visible evidence as WARNINGs
Spec alignment check — read
```
.spec-driven/specs/
```
,
```
.spec-driven/config.yaml
```
,
```
.spec-driven/changes/<name>/proposal.md
```
, and all files in
```
.spec-driven/changes/<name>/specs/
```
:
- Does the implementation match what was proposed?
- Do the delta files in
```
changes/<name>/specs/
```
  accurately describe what was implemented? Empty
```
specs/
```
  with real behavior changes is a CRITICAL.
- Does each delta file mirror its corresponding main spec file path? Mismatched paths mean the merge will fail.
- Do the delta files use the standard format (
```
### Requirement: <name>
```
  , RFC 2119 keywords,
```
#### Scenario:
```
  blocks)? Non-conforming format is a CRITICAL — the spec format is mandatory.
- If config.yaml has a
```
rules
```
  field (including any
```
fileMatch
```
  entries), check whether the implementation and artifacts comply — violations are WARNINGs
- If proposal.md has an Unchanged Behavior section with content, verify the implementation has not violated any listed behaviors — violations are CRITICALs
- Flag misalignments as WARNINGs or CRITICALs

Output a tiered report:

CRITICAL (blocks archive):
  - [list or "none"]

WARNING (should address):
  - [list or "none"]

SUGGESTION (optional improvements):
  - [list or "none"]

Recommend next step:
- If CRITICAL issues: address them before archiving
- If only WARNINGs: ask user if they want to address them or proceed
- If clean: suggest
```
/spec-driven-review <name>
```

选择变更 — 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js modify
```
列出当前活跃的变更。询问用户要验证哪一项变更。如果已指定变更名称，则直接使用该名称。
格式检查 — 运行以下命令：
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
报告所有错误（阻塞性）或警告（非阻塞性）。
- 如果脚本提示
```
tasks.md
```
  中没有
```
## Testing
```
  章节，将其升级为CRITICAL（严重问题）—— 每一项变更都必须包含测试任务
任务完成情况检查 — 运行以下命令：
```
node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
```
如果
```
remaining > 0
```
，列出未完成的任务。这些属于CRITICAL（严重问题）。
未解决问题检查 — 读取
```
.spec-driven/changes/<name>/questions.md
```
并扫描
```
- [ ] Q:
```
条目：
- 任何未回答的问题都属于CRITICAL（严重问题）—— 存在未解决的歧义时，无法验证实现的正确性
- 脚本也会将这些问题报告为错误，在此处同样将其视为CRITICAL（严重问题）
实现依据检查 — 针对
```
tasks.md
```
中的每一项已完成任务：
- 确定该任务应修改的代码或文件
- 验证变更是否实际存在（读取相关文件）
- 将任何无可见依据的任务标记为WARNING（警告）
规范一致性检查 — 读取
```
.spec-driven/specs/
```
、
```
.spec-driven/config.yaml
```
、
```
.spec-driven/changes/<name>/proposal.md
```
以及
```
.spec-driven/changes/<name>/specs/
```
下的所有文件：
- 实现是否与提案内容一致？
- ```
changes/<name>/specs/
```
  中的差异文件是否准确描述了已实现的内容？若实际存在行为变更但
```
specs/
```
  目录为空，属于CRITICAL（严重问题）。
- 每个差异文件的路径是否与对应的主规范文件路径一致？路径不匹配会导致合并失败。
- 差异文件是否使用标准格式（
```
### Requirement: <name>
```
  、RFC 2119关键词、
```
#### Scenario:
```
  块）？不符合规范的格式属于CRITICAL（严重问题）—— 规范格式为强制要求。
- 若
```
config.yaml
```
  包含
```
rules
```
  字段（包括任何
```
fileMatch
```
  条目），检查实现和工件是否符合要求—— 违反要求标记为WARNING（警告）
- 若
```
proposal.md
```
  包含Unchanged Behavior（未变更行为）章节且有内容，验证实现是否未违反任何列出的行为—— 违反标记为CRITICAL（严重问题）
- 将不一致项标记为WARNING（警告）或CRITICAL（严重问题）

输出分层报告：

CRITICAL (阻塞归档):
  - [列出问题或填写"无"]

WARNING (建议处理):
  - [列出问题或填写"无"]

SUGGESTION (可选优化):
  - [列出建议或填写"无"]

建议下一步操作:
- 若存在CRITICAL（严重问题）：在归档前解决这些问题
- 若仅存在WARNING（警告）：询问用户是否要处理这些问题或继续归档
- 若无问题：建议运行
```
/spec-driven-review <name>
```

Rules

规则

Be honest — don't pass a change just because tasks are checked off
CRITICALs are things that would make the change incorrect or incomplete
WARNINGs are things that reduce confidence but don't necessarily block
SUGGESTIONs are optional quality improvements

保持诚实——不要仅因任务已勾选就通过变更验证
CRITICAL（严重问题）是会导致变更不正确或不完整的问题
WARNING（警告）是会降低可信度但不一定阻塞归档的问题
SUGGESTION（建议）是可选的质量优化项