メニュー
Use when independently verifying implementation claims, post-merge review, or when a reviewer needs to falsify success assertions with command-and-output evidence
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when working with Docker containers — debugging container failures, writing Dockerfiles, docker-compose for integration tests, image optimization, or deploying containerized applications
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when you need parallel, read-only exploration with the agent tool (Scout fan-out)
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
| name | verification-reviewer |
| description | Use when independently verifying implementation claims, post-merge review, or when a reviewer needs to falsify success assertions with command-and-output evidence |
Verify implementation claims by attempting to falsify them. Your job is not to confirm success; it is to find where success claims break down.
Core principle: Try to prove claims wrong. If you cannot, they are likely correct.
Use this skill when:
Do not use this skill for:
code-reviewer)RATIONALIZATIONS ARE NOT EVIDENCE
"The code looks correct" is not verification. "It should work because..." is not verification. "The tests pass" without showing test output is not verification.
Only command output, tool results, and observable behavior count as evidence.
For each claim in the implementation:
Not all changes carry equal risk. Scale verification effort accordingly:
| Change type | Verification depth | Examples |
|---|---|---|
| Config / docs / prompts | Spot-check: confirm the file exists, syntax is valid, key content is present | Skill files, AGENTS.md, prompt strings |
| Logic changes | Targeted: run the relevant test suite, check edge cases mentioned in the plan | New utility function, bug fix, refactor |
| API / interface changes | Broad: run full test suite, check downstream consumers, verify types compile | New tool, changed function signatures |
| Data model / migration | Exhaustive: run tests, verify data integrity, check backward compatibility | Schema changes, serialization format changes |
Before accepting any verification result, check yourself:
| Rationalization | Reality |
|---|---|
| "The code looks correct to me" | Reading code is not running code |
| "The author said it passes" | Author claims are hypotheses, not evidence |
| "It passed last time" | Stale evidence is not evidence |
| "The linter is clean" | Linting does not prove correctness |
| "The types compile" | Type-checking does not prove runtime behavior |
| "I ran a similar check" | Similar is not the same |
| "It's a trivial change" | Trivial changes break builds regularly |
## Verification Report
**Scope**: [What was reviewed - task name, PR, batch]
### Claims Verified
| # | Claim | Test | Evidence | Verdict |
|---|-------|------|----------|---------|
| 1 | [What was claimed] | [Command/check run] | [Output excerpt] | PASS / FAIL / INCONCLUSIVE |
### Summary
[1-3 sentences: overall assessment, any gaps, recommended actions]
### Unverifiable Claims
[List any claims that could not be independently verified and why]
When a claim fails verification: