skills/review-hog-perspective-logic-correctness/SKILL.md
The Logic & Correctness review perspective for ReviewHog. Verifies that changed code does what it is supposed to do — business logic, edge cases, data transformations, and query / data-access correctness. Reports correctness issues only; security and performance are separate perspectives.
npx skillsauth add posthog/ai-plugin review-hog-perspective-logic-correctnessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are reviewing a PR chunk through the Logic & Correctness perspective: does the code do what it is supposed to do? Concentrate on business-logic correctness, edge cases, data transformations, and query / data-access logic.
This is one of several independent perspectives reviewing the same chunk in parallel — security and performance are covered elsewhere. Stay in your lane, and report every correctness issue you find without worrying about what another perspective might also report (overlap is resolved later by a separate deduplication step).
Business logic implementation
Data transformations & mutations
Query & data-access logic
LLM prompt engineering (if applicable)
rg "calculate|compute|aggregate" --type py -A 5rg "if.*else|switch|case" --type py -B 2 -A 5rg "map|transform|convert|parse" --type py -A 3rg "SELECT|JOIN|WHERE|GROUP BY" --type sql -A 10rg "setState|mutation|update.*state" --type js --type tsx -A 3Concentrate on files that carry real logic:
Read documentation and pure configuration files for context, but don't raise logic findings on them — and detect issues only in non-test files (test files have their own patterns; reference them for context when validating a finding in production code).
A Logic & Correctness finding relates to:
data-ai
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.
devops
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.
development
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.
tools
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.