Review Hog Blind Spots General

by PostHog469d1773e9cbNo licenseListed Oct 8, 2026Updated Oct 8, 2026

The general blind-spot check for PostHog Review, the final sweep that runs after every enabled review perspective has reviewed a chunk. Hunts for real, high-value issues that ALL of the perspectives missed, conditioned on what they actually found; returns an empty list over padding.

Instructions onlySoftware Development
AI-generated overview

Final blind-spot sweep of a code-review chunk, reporting only high-value issues that all prior review perspectives missed.

What it does
This skill acts as the last pass in a chunked pull-request review. It reads what the specialist review perspectives already reported for the same chunk, then hunts for genuinely new, concrete problems they did not raise, such as untested edge cases, error paths, unhandled inputs and cross-file interactions. It returns a list of new issues, or an empty list when nothing was missed.
When to use it
Use it after all enabled review perspectives have finished reviewing a chunk, as the closing sweep before the review is considered complete. It fits when you want coverage of gaps rather than a repeat of findings already reported.
Requirements
Instructions only; no scripts or assets are included. It needs the review prompt listing which perspectives ran and what they found, plus the chunk under review.

Blind-spot check

You are the blind-spot check — the final sweep of a PR-chunk review. Several specialist perspectives have each already reviewed this exact chunk in parallel: which ones ran is listed in your review prompt, along with what they found (or a note that they found nothing on this chunk). Your job is to catch the real, high-value issues that ALL of them missed. You are conditioned on their actual output, so hunt where they did not look instead of re-walking their ground.

How to hunt

  • Study the covered findings first (when there are any): they show where the perspectives spent their attention. Your value is everywhere else.
  • Dig into what the prior findings did NOT touch — untested edge cases, error and failure paths, unhandled inputs, cross-file interactions, and assumptions that break under load or hostile input.
  • You are not scoped to one specialty: a real issue is in scope no matter which lens it belongs to, as long as no perspective already raised it.

What to report

  • Only genuinely NEW problems. Do not re-report, restate, or minorly reword anything already covered in the findings above or in the PR's inline comments.
  • The bar is the same as any perspective's: a real, concrete problem with a nameable trigger and a nameable consequence, anchored to this chunk's changes.
  • If the perspectives were thorough and nothing was missed, return an empty issues list. An empty sweep is a valid, good outcome — padding is not.

Source and attribution

Source:PostHog/ai-plugininskills/review-hog-blind-spots-generalat commit469d177

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from PostHog/ai-plugin

Writing Simplified Technical English

PostHog

Applies ASD-STE100 simplified technical English rules to make agent-written prose unambiguous and actionable.

Writing & ContentOct 8, 2026

Working With Task Comments

PostHog

Reads and interprets comments on PostHog tasks, artifacts, and canvases through the PostHog MCP exec dispatcher.

Productivity & WorkflowOct 8, 2026

Working With Skills

PostHog

Guides agents in using PostHog's skill-* MCP tools to discover, read, create, update, and refactor skills.

AI & AgentsOct 8, 2026

Working With Scouts

PostHog

Operating manual for delegating watching jobs to PostHog Signals scouts, acting on their reports, and steering the fleet over time.

AI & AgentsOct 8, 2026

Validating And Publishing Canvases

PostHog

Validate and publish a canvas source project safely: the source-project shape, declared capabilities, reading the current version pointer, iterating on validation diagnostics, guarded publishing with expected_current_version_id, staging a draft build and promoting it, waiting out the queued build, and recovering from a 409 version_conflict or a 429 capacity limit without overwriting concurrent work. Use whenever a canvas edit is ready to save, a draft build is wanted, a canvas publish or build returns diagnostics or a conflict, or a task needs to understand canvas version history.

Awaiting classificationOct 8, 2026

Understanding Billing Usage

PostHog

Explains PostHog billing usage and spend from the customer's visible Billing MCP tools. Use when the user asks why usage or spend is high, which product or project is driving usage, what a usage type means, how to reduce usage, what changed over time, why they got a usage change alert, or whether a spike/drop alert was real or noisy. Also use before product-specific analytics skills when the user names a billable PostHog product metric such as events, recordings, feature flag requests, exceptions, survey responses, synced rows, logs, AI events, AI credits, or Inbox credits. Starts from Billing usage/spend tools, then routes to customer-visible product MCP surfaces for deeper investigation.

Awaiting classificationOct 8, 2026