| name | claim-verifier |
| platforms | ["cowork","claude-code"] |
| description | Verify factual claims in a finished SEO article draft via web search. Use after de-slop and before publishing. Produces a structured claim-check report file alongside the article — does not modify the article itself. Trigger when the seo-writer pipeline reaches the verification step, or when a user asks to 'fact-check', 'verify claims', or 'check the article' before publishing. |
| references | [] |
Claim Verifier
This skill reads a finished article, extracts all verifiable factual claims, checks each one via web search, HTTP-checks all external links, and writes a structured report. The article file is never modified — the report is an editorial action list for the human reviewer.
When to use this skill
- The seo-writer pipeline has completed writing, review, revisions, and de-slop, and needs a verification pass before optimize-meta-tags
- A user asks to "fact-check," "verify claims in," or "check the stats in" a finished article
- An article contains competitor version claims, deprecation dates, customer proof points, or third-party benchmarks that should be confirmed before publishing
When NOT to use this skill
- Before de-slop is complete (de-slop may rewrite claims — always verify the final prose)
- For Tiger Data product features (Tiger Docs verification happens during seo-article-writer, not here)
- For internal Tiger Den links (seo-article-writer already verifies these)
Step 0: Pre-flight
Call marketing-preflight with args claim-verifier. Do not proceed until it completes successfully. If it stops with an error, follow its instructions and stop.
Step 1: Read the article and extract claims
Read the full article file. Identify every verifiable factual claim. Organize into five categories:
1. Statistical claims — specific numbers, percentages, ratios, benchmarks
Examples: "92% memory reduction", "10-20x better RAM efficiency", "query time dropped from 6.4s to 30ms", "90–95% compression"
2. Product and version claims — version numbers, release dates, feature availability, pricing model descriptions
Examples: "Mimir v3.0, released November 2025", "InfluxDB 3 uses InfluxQL and SQL, not Flux", "instance-based pricing billed hourly"
3. Deprecation and EOL claims — products deprecated, services closed, EOL dates announced
Examples: "AWS closed Timestream LiveAnalytics to new customers in June 2025", "Promscale was deprecated in 2023"
4. Competitive architectural claims — "X doesn't support Y", hard limits, capability gaps
Examples: "InfluxDB Cloud Serverless documents a soft limit of approximately 10 million unique series keys", "QuestDB does not support continuous aggregates natively"
5. Customer proof points — named customer quotes or attributed performance metrics
Examples: "FlightAware reduced query time from 6.4 seconds to 30 milliseconds", "Skylab went from a 64-core, 512 GB RAM machine to a 4-core, 16 GB RAM setup"
Do not include:
- Tiger Data's own product feature descriptions (verified by seo-article-writer via Tiger Docs)
- Claims already qualified with "reported", "community benchmarks suggest", or other hedging language that makes them non-assertive
- Internal Tiger Den links
Step 2: Verify each claim via web search
For each claim, run a targeted web search to find the most authoritative public source. Use official sources first:
- Official product documentation or changelog (e.g., Grafana Labs release notes for Mimir claims)
- Official press releases or announcements (e.g., AWS blog for Timestream deprecation)
- Case study pages on tigerdata.com for customer proof points
- GitHub repositories or READMEs for open-source project claims
Assign one of three verdicts to each claim:
- ✅ Verified — Found a reliable source that confirms the claim as stated. Record the source URL. If the article does not already link to an authoritative source at that point in the text, flag it as needing an inline citation.
- ⚠️ Needs attention — Found a source that contradicts the claim, or the claim is outdated/inaccurate. Provide the correct information and source URL.
- ❓ Unverifiable — No reliable public source found. The claim may be accurate but cannot be confirmed. Recommend softening language (e.g., "reported", "according to community benchmarks", "as of this writing").
Inline citation check: For every verified claim, check whether the article already provides a hyperlink to an authoritative source at or near that claim. Tiger Data internal links (tigerdata.com/blog, tigerdata.com/case-studies, etc.) count as citations for Tiger Data's own data and customer proof points. External claims (competitor stats, third-party benchmarks, product version facts) need external links. If a verified claim has no nearby link to its source, add it to a "Missing citations" section in the report.
Efficiency note: If multiple claims reference the same product or event (e.g., several claims about Mimir v3.0), search once and apply findings across all related claims.
Step 3: HTTP-check external links
For every external URL in the article (non-Tiger Data URLs — anything not on tigerdata.com or docs.timescale.com):
- Issue a HEAD request to check HTTP status
- Record the result: ✅ 200 OK, ⚠️ 301/302 redirect (note destination), ❌ 404/error
Use the Bash tool:
curl -s -o /dev/null -w "%{http_code}" -L --max-time 10 "{URL}"
Run these checks in parallel where possible to avoid slow sequential execution.
Step 4: Write the report
Determine the slug from the article filename (e.g., prometheus-alternatives.md → slug is prometheus-alternatives). Write the report to {article-directory}/{slug}-claim-check.md.
Use this exact format:
# Claim Verification Report — {Article H1 Title}
*Article: `{file_path}` | Verified: {YYYY-MM-DD}*
## Summary
- {N} claims verified ✅
- {N} claims need attention ⚠️
- {N} claims unverifiable — recommend softening ❓
- {N} missing inline citations
- {N} external links checked ({N} OK, {N} flagged)
## Verified claims
| Claim (as written in article) | Source | Status |
|---|---|---|
| "{exact quote}" | [Source title](URL) | ✅ Confirmed |
## Claims needing attention
| Claim (as written) | Issue | Recommended update |
|---|---|---|
| "{exact quote}" | {What's wrong} | Replace with: "{corrected text}" |
## Unverifiable claims — recommend softening
| Claim (as written) | Suggested revision |
|---|---|
| "{exact quote}" | "{softened version}" |
## Missing inline citations
Verified claims that have no nearby hyperlink to an authoritative source in the article body. Add a link at the point of the claim.
| Claim (as written) | Suggested source to link |
|---|---|
| "{exact quote}" | [Source title](URL) |
## External links
| URL | Status |
|---|---|
| https://... | ✅ 200 OK |
| https://... | ⚠️ 301 → {destination} |
| https://... | ❌ 404 — remove or replace |
If a category has no entries, omit that section entirely. Do not write empty tables.
Step 5: Return summary to calling agent
After writing the report, return this summary to the calling agent (seo-writer or user):
Claim verification complete — {N} verified, {N} flagged, {N} unverifiable, {N} missing inline citations.
Report: {claim-check-file-path}
[If any ⚠️, ❓, or missing citation items]: The following need attention before publishing:
- {Claim}: {one-line issue summary}
- ...
[If all clear]: All claims verified. No open items.
