Verify Findings

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

1. Read the report file at the provided path 2. Detect review type from the header:

• "Pragmatic Code Review Report" → code review
• "Security Review Report" → security review

3. 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

4. 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

1. Read the flagged code at the specified line with ~50 lines of surrounding context 2. Grep the codebase for the same pattern to check if it's an established convention 3. Verify the cited principle — does SOLID/DRY/KISS/YAGNI actually apply here? 4. Check framework handling — does the framework or library address this concern automatically? 5. Assess concrete impact — is the problem demonstrable or theoretical?

Security Review Findings

1. Read the flagged code and trace data flow from source to sink 2. Grep for sanitizers/validators in the code path between source and sink 3. Detect framework protections — React auto-escaping, Spring Security, Django ORM parameterization, etc. 4. WebSearch the CWE/CVE for known false positive patterns and framework-specific mitigations 5. Verify exploit feasibility — is the exploit scenario actually possible in this application context? 6. 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:

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

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

2. Preserve original structure — keep the same header, PR assessment, and format 3. 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}% |

4. Annotate confirmed findings with verification notes:

> **Verification**: CONFIRMED — {evidence summary}

5. 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}

6. Update Verdict with revised counts and recommendation

See WORKFLOW.md for the complete report template. See EXAMPLES.md for sample verified reports.

Output Instructions

1. Save the verified report alongside the original 2. Display the full verified report to the user 3. 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
• TROUBLESHOOTING.md — Common issues with input parsing, verification quality, and output

Verification Examples

Example 1: Code Review Verification

Input: Original Code Review Report

# Pragmatic Code Review Report

**Date**: 2026-02-28T14:30:00Z
**Branch**: feature/user-profile
**Commit**: a1b2c3d
**Reviewer**: Claude Code (multi-agent code review)
**Review Mode**: Multi-Agent Orchestration (4 reviewers, confidence threshold: 80)

## PR Assessment

| Attribute | Value |
|-----------|-------|
| **Risk Level** | Medium |
| **Change Type** | Feature |
| **Atomicity** | Atomic |
| **Breaking Changes** | None |

## Findings

### Blockers

- **[Blocker]** `src/services/userService.ts:45` — SQL injection vulnerability in user search (Confidence: 95/100, Source: Security)
  - **Principle**: Security — Input Validation
  - **Current**: `db.query(\`SELECT * FROM users WHERE name LIKE '%${query}%'\`)`
  - **Suggested**: `db.query('SELECT * FROM users WHERE name LIKE $1', [\`%${query}%\`])`

### Improvements

- **[Improvement]** `src/components/UserProfile.tsx:112` — XSS risk: user-supplied content rendered without sanitization (Confidence: 82/100, Source: Security)
  - **Principle**: Security — Output Encoding
  - **Current**: `<div>{user.bio}</div>`
  - **Suggested**: Use a sanitization library before rendering

- **[Improvement]** `src/utils/cache.ts:23` — Cache invalidation missing for user updates (Confidence: 85/100, Source: Bug Scan)
  - **Principle**: DRY — Single Source of Truth
  - **Current**: Cache is set on read but never invalidated
  - **Suggested**: Add cache invalidation in `updateUser()` and `deleteUser()`

- **[Improvement]** `src/services/userService.ts:78` — N+1 query in user list with roles (Confidence: 81/100, Source: Bug Scan)
  - **Principle**: Performance — Efficient Data Access
  - **Current**: `users.forEach(u => db.query('SELECT * FROM roles WHERE user_id = ?', [u.id]))`
  - **Suggested**: `db.query('SELECT * FROM roles WHERE user_id IN (?)', [userIds])`

## Verdict
- **Recommendation**: Request Changes
- **Blockers**: 1
- **Improvements**: 3

Output: Verified Report

# Pragmatic Code Review Report (Verified)

**Date**: 2026-02-28T14:30:00Z
**Branch**: feature/user-profile
**Commit**: a1b2c3d
**Reviewer**: Claude Code (multi-agent code review)
**Review Mode**: Multi-Agent Orchestration (4 reviewers, confidence threshold: 80)
**Verified by**: Claude Code (false-positive-verifier)
**Verification Date**: 2026-02-28T14:45:00Z

## Verification Summary

| Metric | Count |
|--------|-------|
| **Findings Reviewed** | 4 |
| **Confirmed** | 2 |
| **Downgraded** | 1 |
| **Dismissed** | 1 |
| **Signal Ratio** | 50% |

---

## PR Assessment

| Attribute | Value |
|-----------|-------|
| **Risk Level** | Medium |
| **Change Type** | Feature |
| **Atomicity** | Atomic |
| **Breaking Changes** | None |

---

## Verified Findings

### Blockers

- **[Blocker]** `src/services/userService.ts:45` — SQL injection vulnerability in user search (Confidence: 95/100, Source: Security)
  - **Principle**: Security — Input Validation
  - **Current**: `db.query(\`SELECT * FROM users WHERE name LIKE '%${query}%'\`)`
  - **Suggested**: `db.query('SELECT * FROM users WHERE name LIKE $1', [\`%${query}%\`])`
  - > **Verification**: CONFIRMED — Data flow traced: `query` parameter originates from `req.query.search` in `userController.ts:12`, passed directly to `userService.searchUsers()` at line 43, then interpolated into SQL string at line 45. No parameterization, no input sanitization found between controller and query. The `pg` driver is used (confirmed in package.json) which supports parameterized queries.

### Improvements

- **[Improvement]** `src/utils/cache.ts:23` — Cache invalidation missing for user updates (Confidence: 85/100, Source: Bug Scan)
  - **Principle**: DRY — Single Source of Truth
  - **Current**: Cache is set on read but never invalidated
  - **Suggested**: Add cache invalidation in `updateUser()` and `deleteUser()`
  - > **Verification**: CONFIRMED — Grepped for `cache.del`, `cache.invalidate`, `cache.clear` across the codebase: 0 results in `userService.ts`. The `updateUser()` function at line 67 and `deleteUser()` at line 89 both modify the database without touching the cache set at line 23. Stale data will be served until TTL expires.

- **[Improvement]** `src/services/userService.ts:78` — N+1 query in user list with roles (Confidence: 55/100, was 81/100, Source: Bug Scan)
  - **Principle**: Performance — Efficient Data Access
  - > **Verification**: DOWNGRADED — The N+1 pattern exists but the `getUsersWithRoles()` function is only called from the admin dashboard (`adminController.ts:34`), which has a `limit: 20` parameter. With max 20 users, the performance impact is negligible. Additionally, the roles table has an index on `user_id` (confirmed in `migrations/003_add_roles.sql`). Downgraded from 81/100 to 55/100.

---

## Dismissed Findings

### Dismissed 1: `src/components/UserProfile.tsx:112` — XSS risk: user-supplied content rendered without sanitization

- **Original Triage**: Improvement
- **Original Confidence**: 82/100
- **Original Source**: Security
- **Reason**: React auto-escapes JSX expressions by default. The `{user.bio}` expression renders as text content, not as HTML. XSS via JSX text interpolation is not possible unless unsafe HTML rendering APIs are used.
- **Evidence**: Grepped for unsafe HTML rendering APIs in `UserProfile.tsx` and all imported components: 0 results. React 18.3.1 confirmed in `package.json`. The `user.bio` field is rendered inside a `<div>` as a text node — React's virtual DOM escapes the content automatically.

---

## Verdict (Revised)

- **Recommendation**: Request Changes
- **Risk Level**: Medium
- **Blockers**: 1
- **Improvements**: 2 (1 downgraded)
- **Questions**: 0
- **Nits**: 0
- **False Positives Removed**: 1

---

Example 2: Security Review Verification

Input: Original Security Review Report

# Security Review Report

**Date**: 2026-02-28T15:00:00Z
**Branch**: feature/api-v2
**Commit**: d4e5f6g
**Reviewer**: Claude Code (security-review)
**Framework**: OWASP Top 10 2025 + API Top 10 + LLM Top 10

## Summary
- **Blocker**: 2 findings
- **Improvement**: 1 finding
- **Total**: 3 actionable findings

## Findings

### [Blocker] Vuln 1: A05 Injection: `src/api/search.ts:34`

* **Severity**: HIGH
* **Confidence**: HIGH
* **Category**: A05:2025 Injection
* **CWE**: CWE-89
* **Description**: User input from query parameter interpolated directly into MongoDB query
* **Exploit Scenario**: Attacker sends `{"$gt": ""}` as search parameter to extract all records
* **Recommendation**: Use MongoDB's built-in query sanitization or `mongo-sanitize` package

### [Blocker] Vuln 2: A01 Access Control: `src/api/users.ts:67`

* **Severity**: HIGH
* **Confidence**: HIGH
* **Category**: A01:2025 Broken Access Control
* **CWE**: CWE-639
* **Description**: IDOR vulnerability — user can access other users' profiles by changing the ID parameter
* **Exploit Scenario**: Authenticated user changes `/api/users/123` to `/api/users/456` to access another user's data
* **Recommendation**: Add authorization check comparing `req.user.id` with the requested resource owner

### [Improvement] Vuln 3: A04 Cryptographic Failures: `src/utils/token.ts:12`

* **Severity**: MEDIUM
* **Confidence**: MEDIUM
* **Category**: A04:2025 Cryptographic Failures
* **CWE**: CWE-326
* **Description**: JWT signed with HS256 which is vulnerable to brute-force attacks on weak secrets
* **Exploit Scenario**: Attacker brute-forces the JWT secret and forges authentication tokens
* **Recommendation**: Switch to RS256 or use a strong secret (256+ bits of entropy)

Output: Verified Report

# Security Review Report (Verified)

**Date**: 2026-02-28T15:00:00Z
**Branch**: feature/api-v2
**Commit**: d4e5f6g
**Reviewer**: Claude Code (security-review)
**Framework**: OWASP Top 10 2025 + API Top 10 + LLM Top 10
**Verified by**: Claude Code (false-positive-verifier)
**Verification Date**: 2026-02-28T15:20:00Z

## Verification Summary

| Metric | Count |
|--------|-------|
| **Findings Reviewed** | 3 |
| **Confirmed** | 1 |
| **Downgraded** | 1 |
| **Dismissed** | 1 |
| **Signal Ratio** | 33% |

---

## Summary (Revised)
- **Blocker**: 1 finding (was 2)
- **Improvement**: 1 finding (downgraded from Blocker)
- **Total**: 2 actionable findings
- **False Positives Removed**: 1

---

## Verified Findings

### [Blocker] Vuln 1: A01 Access Control: `src/api/users.ts:67`

* **Severity**: HIGH
* **Confidence**: HIGH
* **Category**: A01:2025 Broken Access Control
* **CWE**: CWE-639
* **Description**: IDOR vulnerability — user can access other users' profiles by changing the ID parameter
* **Exploit Scenario**: Authenticated user changes `/api/users/123` to `/api/users/456` to access another user's data
* **Recommendation**: Add authorization check comparing `req.user.id` with the requested resource owner
* > **Verification**: CONFIRMED — Traced the request handler at `users.ts:67`. The `getUserById` endpoint extracts `req.params.id` at line 68 and queries `User.findById(id)` at line 70. No authorization middleware applied to this route (checked `routes/users.ts:15` — only `authMiddleware` which verifies authentication but not authorization). The `req.user.id` is available but never compared to the requested ID. Any authenticated user can access any profile.

### [Improvement] Vuln 2: A05 Injection: `src/api/search.ts:34` (Downgraded from Blocker)

* **Severity**: MEDIUM (was HIGH)
* **Confidence**: MEDIUM (was HIGH)
* **Category**: A05:2025 Injection
* **CWE**: CWE-89
* **Description**: User input from query parameter used in MongoDB query
* **Recommendation**: Add explicit type checking or use `mongo-sanitize`
* > **Verification**: DOWNGRADED — The NoSQL injection concern is valid but overstated. The `mongoose` ODM (v8.1.0, confirmed in package.json) is used with a schema-validated model. The `search` parameter is passed to `Model.find({ name: { $regex: query } })` at line 36. While `$regex` injection is possible, Mongoose's query casting rejects object-type inputs for string fields by default (verified via Mongoose 8.x docs: "Query casting prevents most NoSQL injection when schemas have typed fields"). The field `name` is typed as `String` in the schema at `models/item.ts:8`. Severity downgraded to MEDIUM because exploitation requires bypassing Mongoose's type casting, which is non-trivial. Confidence downgraded to MEDIUM.

---

## Dismissed Findings

### Dismissed 1: `src/utils/token.ts:12` — JWT signed with HS256

- **Original Triage**: Improvement
- **Original Confidence**: MEDIUM
- **Reason**: HS256 is not inherently weak — it depends on the secret's entropy. The JWT secret is loaded from `process.env.JWT_SECRET` at `config.ts:5`. The `.env.example` specifies `JWT_SECRET=<generate-with-openssl-rand-base64-64>` with a comment requiring 512-bit minimum. The actual secret length cannot be verified (environment variable), but the project's security documentation (`docs/SECURITY.md:23`) mandates 64-byte secrets generated via `openssl rand -base64 64`.
- **Evidence**: Searched OWASP JWT cheat sheet: "HS256 is acceptable when combined with a sufficiently strong secret (256+ bits)." The project enforces this via documentation and `.env.example` template. No evidence of a weak secret. CWE-326 (Inadequate Encryption Strength) does not apply when the key has sufficient entropy.

---

## Verdict (Revised)

- **Recommendation**: Request Changes
- **Risk Level**: Medium (was High)
- **Blockers**: 1 (was 2)
- **Improvements**: 1
- **Questions**: 0
- **Nits**: 0
- **False Positives Removed**: 1

Verify Findings Troubleshooting

Common issues when using the verify-findings skill.

---

Input Issues

"No report path provided"

Cause: The skill requires a report file path as an argument.

Fix: Provide the path to the review report:

/review:verify-findings ./reviews/code/2026-03-01_14-30-00_code-review.md

Report format not recognized

Symptoms: Skill cannot detect review type (code or security).

Cause: The report header doesn't match expected patterns ("Pragmatic Code Review Report" or "Security Review Report").

Fix: Ensure the report was generated by the code-review or security-review skills. Manual reports need matching headers for automatic detection.

---

Verification Issues

All findings dismissed

Symptoms: Every finding marked as DISMISSED, signal ratio is 0%.

Cause: Findings may reference code that has changed since the review, or framework protections are correctly suppressing issues.

Fix:

• Check if the code has been modified since the review was generated
• Re-run the original review on the current code state
• Review the dismissal reasons — if they cite valid framework protections, the original review produced false positives

All findings confirmed without investigation

Symptoms: Every finding marked CONFIRMED with minimal verification notes.

Cause: The verifier defaults to CONFIRMED when uncertain (conservative approach).

Fix: Check verification notes for depth. Good verification includes:

• Code context read (surrounding lines)
• Framework protection checks
• Grep results for patterns/conventions
• Web research for CWE/CVE (security reviews)

---

Output Issues

Verified report overwrites existing file

Cause: A .verified.md file already exists from a previous verification run.

Fix: The skill overwrites by design — each verification is a fresh analysis. Archive previous verified reports if you need to preserve them.

Verified report missing dismissed section

Symptoms: No "Dismissed Findings" section in the output.

Cause: No findings were dismissed — all were confirmed or downgraded.

Fix: This is expected behavior. The dismissed section only appears when findings are actually dismissed.

Verification Workflow

Detailed procedures for independently verifying code review and security review findings.

Code Review Verification Procedures

Architecture & Integrity Findings

1. Read the flagged code and its module/package context 2. Check if the architectural pattern is used consistently elsewhere in the codebase 3. Verify if the concern is about an actual SRP violation or just a large file 4. Assess modularity — are the responsibilities actually coupled or just co-located?

Functionality & Correctness Findings

1. Read the complete function/method containing the flagged line 2. Trace the logic path — does the claimed edge case actually occur? 3. Check if guard clauses or validation exist upstream 4. Verify race condition claims by checking concurrency primitives (locks, atomics, channels) 5. Test idempotency claims by checking if the operation has side effects

Security Findings (in code reviews)

Defer to the security verification procedure below.

Maintainability & Readability Findings

1. Grep for the naming convention in question — is it established in the codebase? 2. Check if the "complexity" concern is inherent to the domain or artificial 3. Verify that cited DRY violations are actually duplicated logic, not similar but distinct code 4. Assess YAGNI claims — is the flagged abstraction actually used in one place?

Testing Strategy Findings

1. Check if tests exist for the flagged code (grep for test files, describe/it blocks) 2. Verify if the claimed missing edge case is realistic in production 3. Check if integration tests cover what unit tests supposedly miss 4. Assess test isolation — does the test actually depend on external state?

Performance & Scalability Findings

1. Check if the N+1 query claim is valid — is the ORM doing eager loading? 2. Verify bundle size concerns with actual dependency analysis 3. Check if caching is already applied at a different layer 4. Assess memory leak claims — is the reference actually retained?

Dependencies & Documentation Findings

1. Verify claimed license issues with the actual package license 2. Check if the dependency is a well-maintained package (not abandoned) 3. Assess if missing docs are actually needed (simple, self-documenting code doesn't need docs)

Security Review Verification Procedures

Data Flow Tracing

For each security finding, trace the complete data flow:

1. Identify the source: Where does user input enter? (request params, headers, body, file uploads, environment variables) 2. Trace propagation: Follow the data through variable assignments, function calls, and transformations 3. Identify the sink: Where does the data reach a sensitive operation? (SQL query, shell command, HTML output, file system, network request) 4. Check for sanitizers: Between source and sink, look for:

• Input validation (regex, schema validation, type checking)
• Output encoding (HTML encoding, URL encoding, SQL parameterization)
• Framework auto-protection (ORM parameterization, template auto-escaping)
• Security middleware (CSRF tokens, auth checks, rate limiting)

Framework Protection Detection

Check for these common framework-level protections:

How to detect: Grep for framework imports, check package.json/requirements.txt/pom.xml for framework versions, read configuration files.

CWE/CVE Web Research Protocol

For each security finding with a CWE reference:

1. Search: "{CWE-XXX}" false positive {framework} and "{CWE-XXX}" {language} mitigation 2. Check CWE entry: Confirm the weakness actually applies to the code pattern 3. Trusted sources (prioritize in order):

• CWE/MITRE (cwe.mitre.org)
• OWASP documentation (owasp.org)
• Official framework security documentation
• NVD/CVE databases (nvd.nist.gov)
• Framework-specific security advisories

4. Avoid relying solely on: Blog posts, StackOverflow answers, or AI-generated content (unless corroborated by official sources)

Exploit Feasibility Assessment

For each claimed exploit scenario:

1. Is the entry point accessible? — Is the endpoint public, authenticated, or admin-only? 2. Is the payload deliverable? — Can the attacker actually craft the required input? 3. Does the exploit path exist? — Are all intermediate steps in the chain present? 4. What's the actual impact? — Does exploitation lead to the claimed consequence? 5. Are there compensating controls? — WAF, rate limiting, monitoring, authentication

Verdict Decision Matrix

Verified Report Template

# {Original Title} (Verified)

**Date**: {original date}
**Branch**: {original branch}
**Commit**: {original commit}
**Reviewer**: {original reviewer}
**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}% |

---

{Original PR Assessment / Summary section — preserved as-is}

---

## Verified Findings

### Blockers

- **[Blocker]** `{file}:{line}` — {Description} (Confidence: {N}/100)
  - **Principle**: {principle}
  - **Current**: `{code snippet}`
  - **Suggested**: `{fix snippet}`
  - > **Verification**: CONFIRMED — {evidence summary, e.g., "Data flow traced from request.body.email at line 12 through to db.query() at line 45 with no parameterization or sanitization in the path."}

### Improvements

- **[Improvement]** `{file}:{line}` — {Description} (Confidence: {N}/100)
  - **Principle**: {principle}
  - **Current**: `{code snippet}`
  - **Suggested**: `{fix snippet}`
  - > **Verification**: CONFIRMED — {evidence summary}

{For DOWNGRADED findings, show the adjusted confidence/severity with note}

- **[Improvement]** `{file}:{line}` — {Description} (Confidence: {adjusted}/100, was {original}/100)
  - > **Verification**: DOWNGRADED — {reason for adjustment}

### Questions

{Preserved as-is from original — questions don't need verification}

### Praise

{Preserved as-is from original}

### Nitpicks

{Preserved as-is from original}

---

## Dismissed Findings

Findings removed during verification. Each includes the reason for dismissal.

### Dismissed 1: `{file}:{line}` — {Original description}

- **Original Triage**: {Blocker/Improvement/Question}
- **Original Confidence**: {N}/10
- **Reason**: {Detailed explanation}
- **Evidence**: {What was checked — grep results, framework docs, web research findings}

### Dismissed 2: `{file}:{line}` — {Original description}

- **Original Triage**: {Blocker/Improvement/Question}
- **Original Confidence**: {N}/10
- **Reason**: {Detailed explanation}
- **Evidence**: {What was checked}

---

## Verdict (Revised)

- **Recommendation**: {Approve / Request Changes / Approve with Nits}
- **Risk Level**: {may change from original}
- **Blockers**: {revised count}
- **Improvements**: {revised count}
- **Questions**: {count}
- **Nits**: {count}
- **False Positives Removed**: {count}

Security Review Verified Report Template

For security reviews, the Verified Findings section uses the security format:

### [Blocker] Vuln N: {Category Code}: `{file}:{line}`

* **Severity**: {CRITICAL|HIGH|MEDIUM}
* **Confidence**: {HIGH|MEDIUM}
* **Category**: {OWASP category}
* **CWE**: CWE-XXX
* **Description**: {vulnerability description}
* **Exploit Scenario**: {attack path}
* **Recommendation**: {fix}
* > **Verification**: CONFIRMED — {evidence: data flow trace, sink reachability confirmed, no sanitizer found between lines X-Y}