posthog/review-hog-blind-spots-general
skills/review-hog-blind-spots-general/SKILL.md
The general blind-spot check for ReviewHog — 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.
$ install --global
skillsauthnpx skillsauth add posthog/ai-plugin review-hog-blind-spots-generalInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 16, 2026, 6:44 AM168.9s1 file scanned
SKILL.md
- name:
- review-hog-blind-spots-general
- description:
- >
- owner_team:
- review_hog
- skill_type:
- blind_spots
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.
Related Skills
posthog/signals-scout-tasks
data-ai
VerifiedTrustedCommunity
Signals scout for PostHog Tasks, the agent work items a project runs. Two lenses: delivery health (runs failing, clustered by repository and error class, and retry storms) every run, and on a slower rotation demand (recurring asks across human-authored tasks that point at a product gap). Skips the scout fleet's own run rows.
65SKILL.mdUpdated Jul 29, 2026
posthog/signals-scout-conversations
devops
VerifiedTrustedCommunity
Signals scout for the PostHog Conversations (support inbox) product. Watches the `$conversation_*` ticket-lifecycle events for support-delivery regressions — SLA breach-rate steps, first-response latency blowouts, backlog inflow-vs-resolution imbalance, and channel / assignment concentration — and files each dated regression as a report. Complements the per-ticket product-feedback signals the emission pipeline already fires; does not re-surface individual ticket content.
65SKILL.mdUpdated Jul 29, 2026
posthog/setting-up-data-catalog
development
VerifiedTrustedCommunity
Populates and maintains a project's data catalog (semantic layer): canonical metrics, trust marks (certifications) on warehouse tables/views, and reviewed table relationships. Use when asked to set up / seed / bootstrap the data catalog or semantic layer, to catalog a project's metrics, to certify or deprecate data sources, to propose or review table joins, or to work through the proposal review queue. To *use* an existing catalog to answer a business-number question, see querying-posthog-data instead. Trigger terms: data catalog, semantic layer, canonical metric, certify table, deprecate source, relationship proposal, metric drift, review queue.
65SKILL.mdUpdated Jul 29, 2026
posthog/investigating-logs
tools
VerifiedTrustedCommunity
Investigate logs in a PostHog project: verify a service or deployment is healthy, explain an error spike, triage an incident, or understand what a log stream is saying. Use when the user asks to "check the logs", asks whether a service, deploy, release, or change is working or broke anything, asks why errors are up or what changed, or wants the root cause of failures visible in logs. Routes the logs MCP tools (services overview, pattern mining, before/after pattern diffing, bucketed counts, facets, raw rows) so investigations start from summaries instead of raw rows or hand-written SQL over the logs table.
65SKILL.mdUpdated Jul 29, 2026