review-hog-validation-criteria

Validates flagged pull request issues against keep-or-drop correctness and noise criteria.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill review-hog-validation-criteria
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: review-hog-validation-criteria
Source: https://github.com/PostHog/posthog-foss/tree/main/products/review_hog/skills/review-hog-validation-criteria
Command: npx skills add https://github.com/PostHog/posthog-foss --skill review-hog-validation-criteria

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Automated PR review pipelines often generate noisy findings that erode reviewer trust. This Skill acts as the final judgment gate, deciding whether each flagged issue is a real, user-affecting problem worth surfacing or noise that should be dropped.

Core Features & Use Cases

  • Keep/Drop Verdicts: Returns an is_valid decision for each flagged issue based on concrete criteria covering correctness, security, data loss, contract breaks, performance, and reliability defects.
  • Noise Filtering: Drops overengineering suggestions, speculative what-ifs, defensive-coding paranoia, unreachable edge cases, pure style comments, and issues already handled elsewhere.
  • Evidence-Based Reasoning: Requires reading the flagged code in full context, tracing call sites and input flows, and recording a focused argumentation with a category for each verdict.
  • Use Case: A multi-stage PR review pipeline flags 20 candidate issues; this Skill investigates each against the live codebase and keeps only the 4 that name a concrete trigger and consequence, such as an N+1 query on a dashboard path.

Quick Start

Apply the review validation criteria to each flagged PR issue and return a keep-or-drop verdict with reasoning for every finding.

Frequently Asked Questions about review-hog-validation-criteria

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

FAQPage Schema
How do I filter noise from automated code review findings?

Apply a keep-or-drop validation pass that checks each flagged issue against concrete criteria: correctness bugs, security issues, data loss, contract breaks, and real performance problems. Drop anything speculative, stylistic, or already handled elsewhere.

What criteria should a PR review bot use to keep an issue?

Keep an issue only if it names a concrete trigger and consequence, such as an IndexError on empty input or an N+1 query on a hot path. If you cannot name both the trigger and the impact, the finding should be dropped.

Should automated reviewers prioritize precision or recall?

Precision over recall. A reviewer that raises noise gets muted, so when genuinely unsure whether an issue matters, drop it. A small set of real, actionable findings outweighs a long list of maybes.

What kinds of code review comments should be dropped as noise?

Drop overengineering suggestions, speculative what-ifs, defensive-coding paranoia, unreachable edge cases, pure style or formatting opinions, issues already prevented by callers or frameworks, and findings disproven by reading the actual code.

How do I verify a flagged bug is actually reachable in code?

Read the flagged file and surrounding code in full, then trace call sites, types, validation, and input flow to confirm the problem can occur. If existing guards or invariants prevent it, mark the issue invalid.