Skip to main content

cite-guard

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".

설치로 이동

소스 정보

저장소
Zavelinski/cite-guard
최근 소스 활동
2026년 6월 30일 02:57
감지된 SKILL.md 언어
영어
스타
0
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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: 1. **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. 2. **UNVERIFIED** - if you cannot check it now, say so explicitly: "(unverified)" / "from memory, confirm before relying". Never launder a guess as fact. 3. **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 1. Scan the draft for factual claims. 2. Tag each SOURCED / UNVERIFIED / REFUSE. 3. Ground the ones that matter (read/fetch/run); label the rest; drop or escalate the unverifiable high-stakes ones. 4. 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.
GitHub에서 보기