evidence-based-analysis
Skill1 starsChanged 23 days agoApache-2.0View on GitHub
Use when analysing code, explaining how something works, writing or updating documentation, reviewing a change, debugging, tracing a CI or CD pipeline, or making any claim about the codebase. Also use when asked whether something is used, called, or dead code.
In this repository11 other files it gives its agents.
- bias-analysisSkill
- c4-graphSkill
- code-reviewSkill
- create-grafana-dashboardsSkill
- debugSkill
- git-conventionsSkill
- planSkill
- retroSkill
- skillSkill
- software-engineerSkill
- tddSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
No assumptions: - If you cannot find direct evidence (grep match, file content, explicit reference), do not state it as fact
- Distinctive: line 23
Show your work: - When making claims, cite the file and line number
- Distinctive: line 24
Distinguish facts from inferences: - If you must infer, explicitly say "I infer..." or "This appears to..." and explain why
- Distinctive: line 25
Verify references: - When you see something defined (function, script, variable), verify it's actually used before claiming it's part of …
- Distinctive: line 27
Verify before documenting: - When updating documentation or source-of-truth files based on a claim about command output, test results, or …
- Distinctive: line 31
Before documenting any behavior:
- Distinctive: line 56
Ask the user if they have additional context
- Distinctive: line 57
Never fill gaps with assumptions
- Distinctive: line 64
If no citation possible, either find evidence or remove/qualify the statement
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Evidence Based Analysis
Overview
You must verify every claim with concrete evidence from the codebase before stating it as fact. Never infer behavior without proof.
When to use
- Any statement about what the code does, calls, or produces
- Documentation, explanations, reviews, debugging (
debugrequires it) - Pipeline or build analysis
- Claims about test results or command output
Instructions
Core Rules
- No assumptions - If you cannot find direct evidence (grep match, file content, explicit reference), do not state it as fact
- Show your work - When making claims, cite the file and line number
- Distinguish facts from inferences - If you must infer, explicitly say "I infer..." or "This appears to..." and explain why
- Verify references - When you see something defined (function, script, variable), verify it's actually used before claiming it's part of the workflow
- Trace the full path - For CI/CD pipelines, trace job → script → reference chain completely
- Verify before documenting - When updating documentation or source-of-truth files based on a claim about command output, test results, or runtime behavior, run the command yourself to confirm before writing it as fact. Never take stated results at face value when you can verify them directly
Verification Checklist
Before documenting any behavior:
- Did I find the definition? (where it's declared)
- Did I find the usage? (where it's called/referenced)
- Did I verify the connection? (the caller actually invokes it)
- Can I cite file:line for each claim?
Language Rules
DO say:
- "In
file.yml:42, the jobbuildcalls..." - "I found the script
.tag_deployment_branchdefined at line 27, but I cannot find any job that references it" - "Based on lines 10-15 of
config.yml, this appears to..." - "I could not find evidence of X in the codebase"
DO NOT say:
- "The pipeline automatically creates tags" (without showing which job does it)
- "This script is used for..." (without showing where it's called)
- "The system does X" (without citing evidence)
- "All tests pass" (without running the tests yourself to confirm)
When Uncertain
- State what you found
- State what you could not find
- Ask the user if they have additional context
- Never fill gaps with assumptions
Documentation Tasks
When writing documentation:
- Draft the content
- For each claim, mentally check: "Can I cite where I found this?"
- If no citation possible, either find evidence or remove/qualify the statement
- Flag uncertain sections with "⚠️ Needs verification:" prefix
Example
Bad (hallucination risk): "Git tags are automatically created on production release"
Good (evidence-based):
"I found .tag_deployment_branch script in ci.deploy.scripts.yml:27-34 that creates git tags, but I cannot find any job in the pipeline that calls this script. The tagging functionality appears to be unused."
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

