claim-checklisted

Weekly verification that a comparison page's competitor claims are still true. Fetches the primary sources each claim depends on, renders a verdict per claim, updates claims.yaml, and writes a dated report of only what changed. Use when asked to run a claim check, verify competitor comparison pages, refresh a battlecard, or check whether a competitor shipped something that breaks a published claim.
eric-hastie/claim-check · ★ 0 · AI & Automation · score 72

Install: claude install-skill eric-hastie/claim-check

# Claim check A comparison page is a list of assertions about competitors. Each assertion has a primary source that would settle it. This skill re-checks those sources on a schedule and reports only the assertions whose status changed. **It is not a page-change monitor.** Watching whole pages for diffs produces noise (testimonial rotation, nav edits, A/B copy) and misses the changes that matter (a competitor ships a feature and never edits the page you watch). Claims are the unit. ## Inputs - `claims.yaml` is both the input and the state. Each claim carries `status`, `evidence` and `last_verified`. The job of a run is to update that file. - `references/sources.md` says which URL is authoritative for which kind of claim, per competitor. Read it before fetching anything. ## Procedure ### 1. Select Build the run list. Include a claim if any of: - it has never been verified, - `last_verified` is more than 30 days ago, - `status` is anything other than `CONFIRMED` (unresolved claims get rechecked every run), - the operator named it explicitly. Claims flagged `frozen: true` are skipped. Use that for strategic claims that only change when a competitor reverses a public position. Print the run list with counts before fetching: total claims, selected, skipped, and why. ### 2. Fetch Collect the deduplicated set of source URLs across selected claims, then fetch each one once. Prefer changelogs and pricing pages over marketing pages: they are dated and specific. Record fo