Audit Verify Explain Grade 5
Audit work, verify claims with concrete evidence, and explain the result in simple...
Install
npx skills add MengTo/Skills --skill audit-verify-explain-grade-5 -g -a claude-code -y- Repository
- MengTo/Skills7.2k
- Category
- Testing
- Updated
- 3d ago
- License
- MIT
- Context cost
- Lightabout 824 tokens
- Runs scripts
- No, instructions only
What it does
Audit work, verify claims with concrete evidence, and explain the result in simple grade-5 language. Use when the user asks to review, audit, check, verify, explain a change, explain a fix, summarize test results, validate whether something works, or translate technical findings into plain language for non-technical readers.
Audit, Verify, Explain
Core Rule
Treat every answer as three jobs:
- Audit what changed or what is being claimed.
- Verify it with direct evidence.
- Explain it like the reader is smart but new to the topic.
Do not skip verification when local files, commands, logs, tests, screenshots, or source data are available. Do not pretend something was verified if it was only inferred.
Workflow
1. Audit
Start by finding the real source of truth:
- For code changes, inspect the diff, touched files, related call sites, and existing tests.
- For bug fixes, identify the before/after behavior and the user-facing path.
- For performance claims, separate measured evidence from likely improvement.
- For release or app behavior, check the packaged/running artifact when possible.
- For documents or content, compare the user request against the actual produced artifact.
Look for:
- obvious bugs or regressions
- missing edge cases
- stale assumptions
- unverified claims
- mismatches between implementation and user intent
- risks that a grade-5 explanation might accidentally hide
2. Verify
Prefer evidence in this order:
- Automated tests, builds, linters, typechecks, or validators.
- Running the actual app or workflow.
- Logs, process checks, screenshots, generated artifacts, or live output.
- Static code inspection when execution is impractical.
- Clearly labeled inference when nothing stronger is available.
When verification fails, report the blocker and what it means. When verification is partial, say exactly what was and was not checked.
For performance work, avoid overclaiming. Say "this removes repeated work" only when the code clearly does so. Say "should improve" only when no timing trace was captured. Say "measured faster" only when before/after measurements exist.
3. Explain Simply
Use grade-5 language without talking down to the user:
