skills.rest
ZaxbyHub
ZaxbyHubOFFICIAL
Explore all skills by this author →
GitHub

review-finding-validator

Validates code review findings against current worktree evidence before implementation.

Updated Mar 30, 2026
Search Tags:#code review#pull request#validation#evidence#triage#git diff#findings
One-click install
npx skills add https://github.com/ZaxbyHub/ragappv3 --skill review-finding-validator-zaxbyhub
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-finding-validator
Source: https://github.com/ZaxbyHub/ragappv3/tree/main/.opencode/skills/review-finding-validator
Command: npx skills add https://github.com/ZaxbyHub/ragappv3 --skill review-finding-validator-zaxbyhub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Review findings from external reviewers, CI audits, or PR comments are often stale, overstated, or wrong, and acting on them blindly wastes effort or introduces regressions. This Skill forces every finding to be treated as a claim and classified with concrete evidence before any code is changed. ## Core Features & Use Cases - Evidence-Based Classification: Labels each finding as CONFIRMED, PARTIALLY_VALID, DISPROVED, UNVERIFIED, PRE_EXISTING, or OUT_OF_SCOPE based on source, diff, runtime, or test evidence. - Scoped Review Workflow: Establishes the reviewed scope via branch, base, PR number, and git diff before validating any claim. - Behavior-Level Validation: Prefers running the smallest safe command and checking callers over trusting source-string matches or stale line numbers. - Use Case: Given a bundle of 12 requested-changes comments on a pull request, classify each one with cited evidence, fix only the confirmed items, and document why the rest were rejected. ## Quick Start Validate these review findings against the current branch and classify each one with evidence before making any changes.

Frequently Asked Questions about review-finding-validator

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate code review findings before fixing them?▼

Treat each finding as a claim and verify it against the current worktree by opening the cited file, checking callers, and running the smallest safe command. Classify it as CONFIRMED, DISPROVED, or another label only after recording concrete evidence.

How to triage PR requested-changes comments efficiently?▼

Establish the review scope first with the base branch and git diff, then classify each comment with evidence. Fix only CONFIRMED or accepted PARTIALLY_VALID items and document the exact rejection reason for the rest.

What classifications should review findings get?▼

Each finding gets exactly one label: CONFIRMED, PARTIALLY_VALID, DISPROVED, UNVERIFIED, PRE_EXISTING, or OUT_OF_SCOPE. This separates real defects from stale, overstated, or unrelated claims.

Can review findings be trusted based on cited line numbers?▼

No. Line numbers in reviews often go stale as the branch evolves, so the current file must be opened and checked directly. Tests that only assert source strings or mocks are also not accepted as proof.

When should a valid finding not be fixed?▼

Findings classified as PRE_EXISTING or OUT_OF_SCOPE are valid but unrelated to the current branch or requested change. They are documented rather than fixed, and the patch is not broadened to adjacent cleanup.

Related Skills

Explore More Software Engineering Skills→
gittowergittower
413

code-review

Review Git changes and pull requests against project-specific coding guidelines.

Official
Advanced
refined-prunrefined-prun
35

resolve-review

Apply review resolutions from PR review files with per-finding commits.

Official
Advanced
Euraika-LabsEuraika-Labs
14

test-flakiness

Detect flaky tests in CI logs from GitHub Actions, Unity, Godot, or Unreal.

Official
Advanced
gaebalaigaebalai
8

kiro-verify-completion

Validate task completion claims using evidence from the current code state.

Community
Intermediate