Receber por email
← Voltar para o catálogo

source-verifier

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.

12estrelas
Atualizado há 7 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add a-ariff/ariff-claude-plugins

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/source-verifier/svg)](https://www.skillteca.com.br/skills/source-verifier)
#ai

Skills relacionadas

Ver todas de Documentos →

Alerta por categoria

Receba novas skills de Documentos toda segunda

1 email curto, só com as skills novas de Documentos. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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 express@4.18.2" Good: "Git blame shows this was last modified on 2026-02-15 by user@example.com"

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.

Compartilhar X LinkedIn