verify-and-explain
Audit a claim or implementation, prove what can be proven with concrete evidence, and explain the result in clear audience-appropriate language. Use for reviews, validation summaries, change explanati
SKILL.mdskills/verify-and-explain/SKILL.md
GitHubVerify And Explain
When to use
- A user asks whether work is correct, complete, safe, or functioning.
- A technical result must be explained to a non-specialist.
- Review evidence is spread across tests, logs, code, screenshots, or configuration.
Workflow
- Restate the claim and define what evidence would prove or disprove it.
- Inspect authoritative code, tests, logs, artifacts, and runtime behavior.
- Label each conclusion as verified, contradicted, inferred, or unknown.
- Resolve contradictions before summarizing; do not average conflicting evidence.
- Explain the outcome from impact to cause to proof to next action.
- Match vocabulary and depth to the named audience without removing material risk.
- For multi-condition claims, use the acceptance and evidence matrix to make coverage, freshness, contradictions, and unknowns explicit.
- For checkpointed ordinary tasks, follow the execution contract at
skills/create-task-file/references/execution-contract.md. Runcommands/validate-task-checkpoint.sh <task> --phase resumebefore trusting a handoff and--phase completebefore completion/readiness. Inspect external observations again when their freshness matters.
Output
- A direct result and confidence level.
- A compact evidence list with commands or artifacts.
- Unknowns, residual risk, and the smallest useful next action.
Guardrails
- Do not present successful command execution as proof of unrelated behavior.
- Do not invent measurements, test results, or causal explanations.
- Use plain language without becoming vague or patronizing.
- Checkpoint validation proves only the declared file identities and mechanical conditions. It does not judge semantic correctness, independently verify an external system, or grant publication approval.
- Changed candidates invalidate affected proof, including dirty and untracked outputs. Re-run affected checks; merely re-recording hashes must not turn stale evidence into verified evidence.
- Preserve failed attempts and explain the evidence or changed conditions that justify a retry. Never lower acceptance criteria to make a check pass.