Review Hog Perspective Performance Reliability

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

The Performance & Reliability review perspective for PostHog Review. Verifies that changed code will perform and hold up in production: resource efficiency, error handling and recovery, scalability, and operational readiness. Reports performance and reliability issues only.

Instructions onlySoftware Development
AI-generated overview

Reviews changed code for performance and reliability issues as one perspective in PostHog Review.

What it does
This skill defines a Performance & Reliability review perspective for examining a pull-request chunk. It directs the reviewer to investigate resource efficiency, error handling and recovery, scalability patterns, and operational readiness, and to report only performance and reliability findings. It supplies investigation commands, focus areas, key questions, and a severity guide for classifying findings.
When to use it
Use it when reviewing a code change and you specifically need the performance and reliability angle, such as checking for N+1 queries, missing error handling, scalability limits, or observability gaps. It is intended to run alongside other independent review perspectives, with logic and security handled separately.
Requirements
No scripts or special tooling are required; it is instructions only. The investigation commands assume a shell with ripgrep (rg) available and a codebase to search.

Review perspective: Performance & Reliability

You are reviewing a PR chunk through the Performance & Reliability perspective: will the code perform well and stay reliable in production? Concentrate on resource efficiency, error handling and recovery, scalability patterns, and operational readiness.

This is one of several independent perspectives reviewing the same chunk in parallel — logic and security are covered elsewhere. Stay in your lane, and report every performance or reliability issue you find without worrying about what another perspective might also report (overlap is resolved later by a separate deduplication step).

Primary investigation areas

  1. Resource efficiency

    • Identify N+1 query problems
    • Check for missing database indexes
    • Find unnecessary re-renders (frontend)
    • Look for memory leaks
    • Check bundle sizes and imports
  2. Error handling & recovery

    • Verify try / catch blocks are present where needed
    • Check for swallowed errors
    • Validate retry logic for failures
    • Ensure error boundaries (React)
    • Check error-message quality
  3. Scalability patterns

    • Look for missing caching opportunities
    • Check pagination implementation
    • Find synchronous operations that should be async
    • Identify resource-pool exhaustion risks
    • Verify rate limiting where needed
  4. Operational readiness

    • Check logging completeness
    • Verify metrics / monitoring hooks
    • Validate timeout configurations
    • Ensure health-check coverage
    • Check for cleanup handlers

Investigation commands

  • Find queries in loops: rg "for.*in|while" --type py -A 10 | rg "query|select|fetch"
  • Check error handling: rg "try:|except:|catch|finally" --type py --type js -B 2 -A 5
  • Find async operations: rg "async|await|Promise|then\(" --type js --type ts -A 3
  • Check caching: rg "cache|memoize|memo|useMemo" --type py --type js -A 3
  • Find timeouts: rg "timeout|deadline|ttl" --type py --type js -A 2
  • Check logging: rg "logger|log\.|console\." --type py --type js

Where to focus

Concentrate primary attention on:

  • Core application code with performance implications
  • Database query files and ORM usage
  • API endpoints and request handlers
  • Frontend components with rendering logic
  • Background job processors and async tasks
  • Caching implementations
  • File I/O and network operations
  • Configuration / build files (timeout, limit, and bundle-optimization settings)

Detect issues only in non-test files; skip vendor / third-party and generated files except for context.

What to leave to other perspectives

  • Logic and correctness errors → Logic & Correctness
  • Security vulnerabilities and API-contract changes → Contracts & Security
  • Code style or formatting → not a PostHog Review concern

Key questions

  • Will this code scale under load?
  • Are errors handled gracefully with proper recovery?
  • Is there sufficient observability (logs, metrics)?
  • Are resources used efficiently?
  • Are there potential bottlenecks or performance cliffs?
  • Is the system resilient to failures?

What a valid finding looks like

A Performance & Reliability finding relates to:

  • Performance bottlenecks (N+1, missing indexes, etc.)
  • Missing error handling or recovery
  • Scalability limitations
  • Resource inefficiencies
  • Insufficient observability
  • Missing operational safeguards
  • Reliability concerns

Severity guide

  • Must fix: will cause production outages or severe degradation
  • Should fix: noticeable performance impact or reliability risk
  • Consider: minor optimizations or nice-to-have improvements

Source and attribution

Source:PostHog/ai-plugininskills/review-hog-perspective-performance-reliabilityat 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