| name | cite-guard |
| description | For factual or external claims, attach a source before asserting; mark anything you cannot verify as unverified; refuse to state ungrounded facts as if certain. Use when answering with facts, versions, APIs, prices, dates, or quotes - anywhere a confident-but-wrong claim is costly. Trigger with /cite-guard or "cite your sources", "is that grounded", "don't hallucinate this". |
| version | 0.1.0 |
| user-invocable | true |
| metadata | {"emoji":"🔎"} |
cite-guard
Confident, unsourced claims are how hallucinations slip through. This skill makes grounding a precondition: a factual claim ships with a source, or it ships labeled as unverified, or it does not ship.
Why this exists (evidence)
- LLMs state plausible-but-wrong facts fluently; grounding/retrieval is the most reliable reducer of hallucination, and the failure mode "almost right, but not quite" is the #1 developer complaint about AI output.
- The cost is asymmetric: a wrong version number, API signature, price, or date asserted confidently causes downstream rework or worse. A label ("unverified") is cheap; a silent wrong fact is not.
When to use
- Any factual claim: library versions, API/method names and signatures, prices, dates, statistics, names, quotes, "X supports Y".
- Before pasting a claim into code (an asserted API that does not exist) or into user-facing text.
- NOT needed for the agent's own reasoning/opinion clearly framed as such.
The rule
For each factual claim, one of three:
- SOURCED - attach where it comes from (the file/line you read, the doc URL, the command output). Prefer first-party (official docs, the actual code) over memory.
- UNVERIFIED - if you cannot check it now, say so explicitly: "(unverified)" / "from memory, confirm before relying". Never launder a guess as fact.
- REFUSE/CHECK - if it is high-stakes and unverifiable, do not assert; go verify (read the code, fetch the doc, run the command) or ask.
Hard lines:
- Do not invent a citation (a fake URL/source is worse than none). If there is no real source, it is UNVERIFIED.
- "I recall" is not a source. Memory can be stale or wrong; label it.
- For code: an API/flag/package is a claim - verify it exists (compose with dep-guard) before using it.
The method
- Scan the draft for factual claims.
- Tag each SOURCED / UNVERIFIED / REFUSE.
- Ground the ones that matter (read/fetch/run); label the rest; drop or escalate the unverifiable high-stakes ones.
- Ship with sources inline (or a short note on what is unverified).
Composes with
dep-guard: the code-dependency case of "does this claim (package/API) actually exist".adversarial-verify: verify behavior of code; cite-guard verifies factual claims.geo-aeo-audit: downstream, sourced claims are also what AI answer engines cite.
Honest limits
- A source can be wrong too; cite-guard raises the floor (no naked guesses), it does not guarantee truth.
- Over-applying to obvious/own-reasoning statements adds noise; scope to real external facts where being wrong costs.
