| name | evidence-gathering |
| description | Gather enough context before acting — read code, docs, specs, prior decisions; identify the source of truth; refuse to speculate. Use when investigating, researching, or before any non-trivial change. |
Evidence Gathering
Speculation is cheap and often confidently wrong. Evidence is slower but the only thing that survives a verifier.
When to use
- Before making a non-trivial change, claim, or recommendation.
- When a fact is needed and the answer might depend on something local you have not yet read.
- When prior context, decisions, or design notes likely exist and would change the answer.
Procedure
- Identify the source of truth. Code, spec, design doc, ticket, prior commit, prior conversation? Different facts have different authorities; pick the right one.
- Read before reasoning. Do not summarize from memory or training data when the local artifact is reachable. Read the file.
- Scope the gather. Read enough to answer the question; stop when further reading would not change the answer. Evidence has diminishing returns.
- Flag what is missing. If the source of truth is unreachable, name that explicitly — do not paper over with a plausible guess.
- Cite specifically. Quote the line, name the file, link the decision. Vague references decay; specific ones do not.
Output
A findings list: claim · evidence (file:line / spec § / quote) · confidence. No load-bearing claim without a citation.
Anti-patterns to avoid
- "Probably the code does X" when one read of the file would settle it.
- Reading three more files when one would do — diminishing returns matter.
- Citing the existence of a doc without quoting the relevant passage.