thedixitjain Dev Verify
Completion gate for evidence-based status. The goal is to make every “done / fixed / ready” claim traceable to a fresh command or direct inspection.
This skill does not review code quality (dev-code-review) and does not decide merge / PR / cleanup (dev-finish). It verifies claims before those steps.
Step 0 — Load baseline
执行前先加载 references/dev-baseline.md。不假设、最小代码、外科手术式改动、可验证成功标准 全程生效。
baseline 与本 skill 的关联:
- 可验证成功标准 —— 每个成功声明必须有命令或检查证据。
- 不假设 —— 不把局部测试通过外推成整套系统通过。
- 外科手术式改动 —— 验证 scope 必须对应本次实际改动,不伪装成全量质量背书。
Step 1 — List claims
先列你准备声明的内容,不要直接说完成。
格式:
Claims to verify:
1. <claim> — proof needed: <command / inspection>
2. <claim> — proof needed: <command / inspection>
常见 claim 对照:
| Claim | 需要的 proof |
|---|---|
| Tests pass | fresh test command, exit 0, failure count 0 |
| Build succeeds | fresh build command, exit 0 |
| Lint clean | fresh lint command, exit 0 |
| Bug fixed | original repro / regression test passes |
| Regression test is meaningful | red → green 或临时反转 fix 后会 fail |
| Requirements met | spec / plan AC 逐项对照 |
| Ready for commit | tests/build as appropriate + dev-code-review verdict |
Step 2 — Choose verification commands
用最小充分命令组合:
- 针对本次改动的窄测试。
- 受影响模块的测试。
- 项目标准 lint/build/test,如果存在且成本合理。
- 对文档 / skill 改动,跑仓库提供的结构校验脚本或 grep/JSON parse 检查。
如果找不到验证命令,明确写:
无法自动验证: <原因>
手动检查: <检查了什么>
残余风险: <具体风险>
Step 3 — Run fresh commands
必须在当前回合运行,不能引用旧输出。
记录:
Command: <exact command>
Result: PASS | FAIL
Evidence: <关键输出摘要,含 exit code / tests count / failure count>
如果失败:
- 停止完成声明
- 报告真实状态
- 回到实现或
dev-fix
Step 4 — Requirement checklist
对照用户请求、spec、plan 或 fix artifact,逐项检查:
Requirement checklist:
- [x] <requirement> — verified by <command / file inspection>
- [ ] <requirement> — missing / not verified because <reason>
任何未验证项都不能包装成完成。
SDD artifact mapping
如果存在匹配 artifact,优先按下面顺序映射验证项:
.claude/artifacts/fixes/<slug>.md的Verification/Regression test。.claude/artifacts/plans/<slug>.md的Verification steps/ ADR 风险。.claude/artifacts/designs/<slug>.md的Acceptance criteria。
无法映射的完成声明要单独列为 Unmapped claim,并说明它来自用户当前请求、代码检查还是实现过程中的新增发现。
Step 5 — Final statement
只有 Step 3 和 Step 4 支持时,才能说完成。
合格输出:
Verified:
- <command>: PASS (<evidence>)
- <command>: PASS (<evidence>)
Status: ready for dev-code-review / ready for dev-finish / blocked by <failure>
Hard rules
- 没有新鲜验证,不说完成。
- 局部测试通过不能声称全量通过。
- 不能把“看起来没问题”写成证据。
- agent / 工具报告成功后,仍要独立检查文件或命令输出。
- 验证失败时,如实报告失败,不要弱化措辞。
Multi-Agent Profile
Recommended agent_type: worker
Use when:
- Implementation is complete enough to check.
- The main agent needs independent evidence before claiming done / fixed / ready.
- Verification can run without changing project files.
Do:
- Stay read-only unless the main agent explicitly assigns a fix.
- List claims first, then map each claim to proof.
- Run fresh commands and report exact results.
- Use
../../docs/multi-agent-policy.mdfor verifier independence expectations.
Do not:
- Rubber-stamp another agent's claim.
- Turn local success into a broader claim than the commands support.
- Hide or soften failed commands.
Output:
- Claims checked
- Commands run
- PASS / FAIL evidence
- Requirement checklist
- Residual risks
Source: hashgraph-online/awesome-codex-plugins → plugins/Jason-chen-coder/dev-skills/skills/dev-verify/SKILL.md