Source verifier

Skill a-ariff/ariff-claude-plugins/plugins/source-verifier/skills/source-verifier

65 plugins that turn Claude Code into an autonomous development team. 24 agents, 34 skills, 5 hooks. Includes 12-plugin anti-hallucination suite. One-line install.

Install

npx -y skills add a-ariff/ariff-claude-plugins --skill source-verifier

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Ensure every factual claim in a response is backed by verifiable evidence from the codebase, documentation, or external sources. Use when preparing technical documentation, code reviews, or any output where accuracy is non-negotiable.

SKILL.md

2.6 KB, as published. Nobody here has run it

Source Verifier: Evidence-Based Responses

Every claim must have a source. No source, no claim.

The rule

For every factual statement in your response, you must be able to point to where the evidence came from:

Code claim -> cite file:line
Config claim -> cite config file and key
Dependency claim -> cite package.json or lock file
Behavior claim -> cite test or runtime evidence
History claim -> cite git commit or blame
External claim -> cite documentation URL or error message

Evidence types (ranked by strength)

Tier 1: Direct observation (you just read it)

"The function at src/auth.ts:42 returns a Promise<boolean>" Evidence: Read tool output from that file.

Tier 2: Search confirmation (you found it)

"validateToken is called in 3 places across the codebase" Evidence: Grep search results listing the files.

Tier 3: Tool output (system told you)

"The test suite has 142 passing tests" Evidence: Bash output from running the test command.

Tier 4: Documented claim (someone else wrote it)

"According to the README, the API requires authentication" Evidence: README.md content.

Tier 5: Inference (you reasoned from evidence)

"Based on the error handling pattern, this likely throws on invalid input" MUST be labeled as inference, not fact.

How to cite

Good: "Looking at src/auth.ts:42-50, the validateToken function checks..." Good: "Based on package.json, the project uses [email protected]" Good: "Git blame shows this was last modified on 2026-02-15 by [email protected]"

Bad: "The function validates tokens" (no file reference) Bad: "You're using an old version of express" (no version cited) Bad: "This was recently changed" (no date or commit)

Verification checklist before responding

Before sending any response with factual claims:

[ ] Every file path mentioned actually exists (verified with Glob) [ ] Every function name is spelled correctly (verified with Grep or Read) [ ] Every code quote matches the actual file content (verified with Read) [ ] Every version number comes from package.json, not memory [ ] Every "this does X" claim was verified by reading the code [ ] Inferences are clearly labeled as inferences [ ] Uncertainties are clearly stated as uncertainties

When you cannot verify

Say exactly this: "I haven't verified this against the codebase. Let me check."

Then use your tools to check. Never skip this step to save time.