agentleFS
itsaspacestationitsaspacestation/natural-intelligence/skills/evidence-based-analysis/SKILL.md

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.

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
  1. Distinctive:

    No assumptions: - If you cannot find direct evidence (grep match, file content, explicit reference), do not state it as fact

    line 22
  2. Distinctive:

    Show your work: - When making claims, cite the file and line number

    line 23
  3. Distinctive:

    Distinguish facts from inferences: - If you must infer, explicitly say "I infer..." or "This appears to..." and explain why

    line 24
  4. Distinctive:

    Verify references: - When you see something defined (function, script, variable), verify it's actually used before claiming it's part of …

    line 25
  5. Distinctive:

    Verify before documenting: - When updating documentation or source-of-truth files based on a claim about command output, test results, or …

    line 27
  6. Distinctive:

    Before documenting any behavior:

    line 31
  7. Distinctive:

    Ask the user if they have additional context

    line 56
  8. Distinctive:

    Never fill gaps with assumptions

    line 57
  9. Distinctive:

    If no citation possible, either find evidence or remove/qualify the statement

    line 64

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 (debug requires it)
  • Pipeline or build analysis
  • Claims about test results or command output

Instructions

Core Rules

  1. No assumptions - If you cannot find direct evidence (grep match, file content, explicit reference), do not state it as fact
  2. Show your work - When making claims, cite the file and line number
  3. Distinguish facts from inferences - If you must infer, explicitly say "I infer..." or "This appears to..." and explain why
  4. Verify references - When you see something defined (function, script, variable), verify it's actually used before claiming it's part of the workflow
  5. Trace the full path - For CI/CD pipelines, trace job → script → reference chain completely
  6. 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 job build calls..."
  • "I found the script .tag_deployment_branch defined 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

  1. State what you found
  2. State what you could not find
  3. Ask the user if they have additional context
  4. Never fill gaps with assumptions

Documentation Tasks

When writing documentation:

  1. Draft the content
  2. For each claim, mentally check: "Can I cite where I found this?"
  3. If no citation possible, either find evidence or remove/qualify the statement
  4. 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."

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.