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.

cite-guard

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.