메뉴
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: