review-hog-authoring

name	review-hog-authoring
description	How to author custom ReviewHog skills — the review perspectives, blind-spot checks, and validation criteria that drive ReviewHog's automated PR reviews. Use when a user wants a new review perspective (a specialist lens on their PRs), a custom blind-spot sweep, or their own validation bar for which findings get published. Trigger on "create a ReviewHog perspective", "custom review perspective", "my own blind-spot check", "custom validation criteria", "tune what ReviewHog publishes".
metadata	{"owner_team":"review_hog","skill_type":"authoring"}

Authoring ReviewHog skills

ReviewHog is PostHog's automated PR reviewer. A review splits the PR into chunks, then for each chunk runs every enabled perspective in parallel (independent specialist lenses), a single blind-spot check afterwards (a final sweep conditioned on what the perspectives found), and finally judges every surviving candidate finding against one validation criteria skill — only findings that pass get published to the pull request.

All three kinds are team LLMSkill rows the review agents pull over MCP at run time. PostHog ships canonicals; this skill is the guide for authoring custom ones. The skill itself is team-level; whether it runs is a per-user setting in Inbox → Code review.

Kind	Name contract	Cardinality per user	Canonical example
Review perspective	review-hog-perspective-<slug>	Multi-enable, at least one stays on	review-hog-perspective-logic-correctness
Blind-spot check	review-hog-blind-spots-<slug>	Exactly one active; selecting swaps	review-hog-blind-spots-general
Validation criteria	review-hog-validation-<slug>	Exactly one active; selecting swaps	review-hog-validation-criteria

Authoring flow

1. Ground yourself. Using the PostHog MCP skill tools, skill-list the team's review-hog-* skills and skill-get the canonical of the kind you're authoring (see the table above) — it is the reference for structure and tone. For a perspective, skim the descriptions of every existing review-hog-perspective-* so the new lens doesn't re-cover ground an enabled one already owns (overlap gets deduplicated later, but it wastes review passes).
2. Interview the user. Ask what the skill should focus on, and offer a few concrete directions the current set doesn't cover — grounded in what you saw in step 1 and, when useful, in the project itself. Don't start writing until the direction is picked.
3. Draft the body following the per-kind guidance below. Keep it a focused instruction set the review agent can apply to one chunk in one pass — not an essay.
4. Create the skill yourself with posthog:skill-create — actually create the team LLMSkill row; never hand the user a body to copy-paste. Pass the exact name per the contract above (lowercase slug), a one-paragraph description of what the lens/sweep/bar is, and the body. The name prefix is the whole identity — it is how the Code review tab and the review runs discover the skill. There is no category parameter on the skill tools and you don't need one: the backend stamps the review_hog grouping category itself (it only affects grouping on the Skills page) — do not spend turns trying to set or verify it. Iterate with posthog:skill-update if the user wants changes. Author fresh — don't skill-duplicate a canonical to edit: seeded metadata rides along with the copy, and the canonical sync may overwrite or prune it.
5. Tell the user how to activate it. A custom skill starts inactive for them:
   • Perspective — toggle it on under Inbox → Code review → Perspectives (it appears disabled until they enable it; at least one perspective must stay on).
   • Blind-spot check / validation criteria — select it under the matching section; exactly one runs at a time, so selecting it swaps out the current one for their reviews only. Reviews pin skill versions when a run starts, so an edit mid-review applies from the next run.

Writing a review perspective

The body instructs one specialist review pass over one PR chunk. Match the canonical logic-correctness skill's shape:

• The lane — one sentence on what this lens is responsible for; report everything in lane and leave the rest to the other perspectives.
• Hunting grounds — a numbered handful of concrete places to look, each a specific check the agent can walk against the chunk ("transaction boundaries that split writes that must land together"), not an abstract virtue ("ensure correctness").
• Lane boundary — which perspective owns each adjacent concern this lens must leave alone.
• The finding bar — a publishable finding names the concrete trigger and the concrete consequence; close with a completion criterion ("done when every changed file is flagged or cleared against every hunting ground").

The review harness already tells the agent the pipeline mechanics — parallel perspectives, later deduplication, severity levels, the non-test-files rule — so the skill carries only the lens; restating harness rules dilutes it.

Writing a blind-spot check

The body instructs the final sweep that runs after every enabled perspective finished a chunk. It is conditioned on the covered findings (the prompt lists which perspectives ran and what they found), so the body should say how to use that: the covered findings map where attention already went, and the sweep's value is the negative space — error paths, unhandled inputs, cross-file interactions, assumptions. It is not scoped to one specialty, and an empty result beats padding. A custom sweep narrows or re-weights this hunt (e.g. toward a domain the team keeps getting burned by).

Writing validation criteria

The body defines the keep/drop bar every candidate finding is judged against before publishing. Precision over recall is the house default — a reviewer that raises noise gets muted — so define: what makes a finding real and worth an author's attention (user-affecting correctness, security, data loss, contract breaks, performance), what gets dropped (overengineering, speculation, defensive paranoia, unreachable edges, style), and how to treat genuine uncertainty (default: drop). A custom bar shifts strictness or re-weights concerns; it should still demand evidence from the live codebase, not vibes.