Evidence-based review findings
Turns review suspicions into precise findings with a trigger, violated contract and concrete consequence.
evidence-based-findings
Team members using this skill
When is it useful?
Use when a review must separate confirmed defects from questions and optional improvements.
What does it help you do?
- Traces the exact execution path and checks existing defenses.
- Rejects plausible scenarios that validation or constraints already prevent.
- Reports actionable defects separately from unresolved requirements and suggestions.
Try asking this
Review these suspected authorization issues and retain only findings with a real trigger, affected code path and demonstrable impact. Attempt the reported forbidden action with the stated role and record. Keep the finding only if the actual server path permits the harmful result.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Evidence-Based Findings
A high-signal review never asserts a plausible guess as a proven bug, never invents requirements, and never buries critical defects inside a wall of minor commentary (Richard Feynman & Gerald Weinberg).
Self-Falsification Check Before Reporting Any Finding
Before writing a finding, test your own hypothesis against five questions:
- Trigger condition: Under what exact input, state, or timing does this issue occur?
- Code path: Which exact file, function, and line range (
path/to/file.ts#L20-L35) executes this path? - Violated contract: Which explicit requirement, API contract, or correctness invariant does it break?
- User or system impact: What is the concrete consequence (data corruption, wrong calculation, permission bypass, crash, broken UI flow)?
- Existing defense check: Is there an upstream validator, type constraint, database check, or transaction wrapper that already prevents this scenario? (If yes, drop the false positive!)
Strict Classification of Review Items
Always separate items into three distinct categories:
- Proven Defect (Requires Fix): Backed by a concrete trigger, traced code path (or failing test), and clear violation of requirements or system integrity.
- Open Requirement / Design Question: An ambiguity, contradiction, or unverified edge case that requires a decision or targeted specialist check.
- Optional Suggestion (Non-Blocking): A minor clarity or maintainability improvement that does not block approval.
Concise Finding Format
Report every actionable finding in four compact lines:
Finding: [Concrete problem statement] Trigger & Code Location: [When it occurs and exact
file#Lstart-Lend] Consequence: [What requirement, invariant, or user workflow it breaks] Required Fix: [What outcome must hold after the fix, plus a concrete solution where helpful]
When no material defects exist, state clearly that the change meets the specification and note any boundaries of what was inspected.
Included files 1
SKILL.md