verify-claims
GitHub用于审计报告或计划中的关键声明,通过从原始来源重新推导来验证其真实性。适用于信任子代理报告前、构建决策前或审查早期结论时,防止基于错误前提的推理。
Trigger Scenarios
Install
npx skills add happier-dev/happier --skill verify-claims -g -y
SKILL.md
Frontmatter
{
"name": "verify-claims",
"description": "Audit a report, plan, or handoff by re-deriving every load-bearing claim from primary sources. Use before trusting subagent\/lane reports, before building decisions on unverified claims, or when reviewing a conclusion written earlier (including your own). Distinct from running the app to verify behavior or reviewing a diff — this audits claims."
}
Verify Claims
Take a report — a subagent's, a lane's, a plan's, or your own from earlier — and re-derive its load-bearing claims instead of trusting how they sound. Full doctrine: docs/agent-craft.md §4.
Procedure
- Extract the load-bearing claims — those whose falseness would change the decision being made. Ignore decoration; auditing everything dilutes the audit.
- Re-derive each from a primary source. Source hierarchy: running code > tests > docs > comments > memory. Each step down the ladder is a step toward hearsay.
- Use a different path than the claim arrived by. Claim from reading code → check with a runtime observation. Claim from a test → read the code the test exercises. Two derivations sharing a path share that path's blind spot.
- Re-measure every decision-material number. Re-run test results, coverage, timings, counts, or measurements only when that numeric claim changes the decision. Use the exact immutable commit/artifact when the claim names one; for current dirty work, measure the relevant current paths and acknowledge concurrency. Decorative counts are not evidence and should be removed from the conclusion.
- Treat plausibility as zero evidence. Narrative fit is what generated the claim, so "sounds right" is correlated with exactly the error being hunted. Check the best-fitting claims first, not last.
- Downgrade what you cannot verify. If re-derivation is too expensive, do not skip and do not trust: relabel the claim as an assumption and carry it labeled.
For claims of backward, forward, mixed-version, upgrade, or rollback compatibility, use skills/happier-compatibility. Re-derive the claim against the exact released tag/artifact or applicable predecessor worktree basis, the real old/new component roles, and every claimed direction. A current-code fixture or mock that merely agrees with the current implementation is not independent compatibility evidence.
Output
Each audited claim in one of three bins, with the evidence:
- Confirmed — how it was re-derived, via which independent path.
- Refuted — the contradicting observation. Lead the report with these; a refuted claim is the headline.
- Assumption — why it is unverifiable right now, and what would verify it.
Failure this prevents
Confident propagation of a wrong premise: reasoning chains valid at every link and false in total because link one was hearsay.
Version History
- 98c86f2 Current 2026-08-20 01:01


