| name | source-grounding |
| description | Verify version-sensitive facts against live authoritative sources before asserting them in code or answers. Triggers on: "/source-grounding", "source-grounding", "sourcing". Standing rule — always active via CLAUDE.md. Invoke for deep verification work (API signatures, CVEs, model IDs, auth flows, deprecated patterns, security advisories). |
Source Grounding
Standing rule — active every response. No invocation needed for routine use.
What to verify (not memory)
- CRITICAL (always fetch or flag): API/SDK call signatures · library versions & deprecations · CVEs/security advisories · auth/crypto specs · LLM model IDs & params
- MEDIUM (verify when unsure): package names · config keys · CLI flags · protocol specs
- LOW/stable: math, algorithms, language syntax → memory fine
How
- Identify the version-sensitive claim.
- Name the authoritative source (official docs, advisory DB, package registry, spec, source code).
- Fetch (WebSearch/WebFetch/docs MCP) — or flag
⚠️ unverified: check [source].
- Cite at CRITICAL/MEDIUM. Don't over-verify stable facts.
Per-claim-type authoritative source map: read references/sources.md when choosing where to verify.
Source hierarchy
- Source code / spec / RFC — primary ground truth
- Official/vendor docs — authoritative secondary (honor
.coalmine.json trustedDomains if set: treat those domains as additional authoritative / tier-2 sources)
- Multiple reputable third-party sources — triangulated
- Single blog — weak; corroborate first
- Training memory — weakest for volatile facts
Non-interactive runs: log unfetchable claims as ⚠️ UNVERIFIED and continue — never block. Interactive: when sources cannot be fetched, confirm how to proceed via ask_question.
Output
- Verified:
✅ [claim] — source: [link/file]
- Unverified:
⚠️ unverified — check [exact source]
- Stable fact: no annotation needed
AUTHORITATIVE vs DIVERSE
- AUTHORITATIVE (one ground truth): API/version/config/spec → go to the actual source code or official docs.
- DIVERSE (triangulate ≥ 3): "what's best" / landscape / patterns → multiple repos + docs + community; note conflicts.
