Verify Review Findings
Independent false-positive verification. Assume every finding is false until proven by evidence.
Parse Arguments
$ARGUMENTS(required): Path to the review report file to verify
If no argument is provided, ask the user for the report path.
Step 1 — Read and Parse Report
- Read the report file at the provided path
- Detect review type from the header:
- "Pragmatic Code Review Report" → code review
- "Security Review Report" → security review
- Extract each finding into a structured list:
- Triage level (Blocker, Improvement, Question)
- File path and line number
- Description and confidence/severity scores
- For security: CWE, category, exploit scenario
- Skip Praise and Nit findings — only verify Blocker, Improvement, and Question
Step 2 — Verify Each Finding
For each extracted finding, perform independent verification. See WORKFLOW.md for detailed procedures.
Code Review Findings
- Read the flagged code at the specified line with ~50 lines of surrounding context
- Grep the codebase for the same pattern to check if it's an established convention
- Verify the cited principle — does SOLID/DRY/KISS/YAGNI actually apply here?
- Check framework handling — does the framework or library address this concern automatically?
- Assess concrete impact — is the problem demonstrable or theoretical?
Security Review Findings
- Read the flagged code and trace data flow from source to sink
- Grep for sanitizers/validators in the code path between source and sink
- Detect framework protections — React auto-escaping, Spring Security, Django ORM parameterization, etc.
- WebSearch the CWE/CVE for known false positive patterns and framework-specific mitigations
- Verify exploit feasibility — is the exploit scenario actually possible in this application context?
- Check code context — is this test-only code, behind authentication, or behind a feature flag?
Step 3 — Render Verdict
For each finding, assign one of:
| Verdict | Criteria | Action | |---------|----------|--------| | CONFIRMED | Evidence supports the finding | Keep in report, add verification note | | DISMISSED | Finding is a false positive | Move to Dismissed section with explanation | | DOWNGRADED | Valid but lower severity/confidence | Adjust scores, add explanation |
Decision rules: See WORKFLOW.md for the complete verdict decision matrix.
Default to CONFIRMED if uncertain after thorough investigation (conservative approach).
Step 4 — Generate Verified Report
- Create the verified report at:
{original-path-without-extension}.verified.md- Example:
reviews/code/2026-03-01_14-30-00_code-review.md→reviews/code/2026-03-01_14-30-00_code-review.verified.md
- Example:
- Preserve original structure — keep the same header, PR assessment, and format
- Add verification header:
**Verified by**: Claude Code (false-positive-verifier)
**Verification Date**: {ISO 8601 date}
## Verification Summary
| Metric | Count |
|--------|-------|
| **Findings Reviewed** | {N} |
| **Confirmed** | {N} |
| **Downgraded** | {N} |
| **Dismissed** | {N} |
| **Signal Ratio** | {confirmed / total reviewed}% |
- Annotate confirmed findings with verification notes:
> **Verification**: CONFIRMED — {evidence summary}
- Append Dismissed Findings section:
## Dismissed Findings
### Dismissed 1: `{file}:{line}` — {Original description}
- **Original Triage**: {Blocker/Improvement/Question}
- **Original Confidence**: {score}
- **Reason**: {Why this is a false positive}
- **Evidence**: {What was checked — grep results, framework docs, web research}
- Update Verdict with revised counts and recommendation
See WORKFLOW.md for the complete report template. See EXAMPLES.md for sample verified reports.
Output Instructions
- Save the verified report alongside the original
- Display the full verified report to the user
- Confirm: "Verified report saved to: {path}"
Resources
- WORKFLOW.md — Detailed verification procedures, verdict decision matrix, web research protocol, report template
- EXAMPLES.md — Sample verified reports for code and security reviews