Review perspective: Performance & Reliability

SkillDev tools

This is a review perspective skill for PostHog Review. It directs an AI agent to examine a pull request chunk for performance and reliability concerns: resource efficiency, error handling and recovery, scalability, and operational readiness. It reports only performance and reliability findings, leaving logic and security to other parallel perspectives.

Then ask your AI: use the Review perspective: Performance & Reliability skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Have a pull request or code change ready for review.

What your AI can do with it

  • Identify N+1 query problems and missing database indexes
  • Check for swallowed errors and missing try/catch blocks
  • Find missing caching opportunities and pagination gaps
  • Verify logging, metrics, timeouts, and health-check coverage
  • Assign each finding a severity from must-fix to consider
  • Use search commands to inspect code for performance patterns

Getting started

  1. Have a pull request or code change ready for review.
  2. Add the review-hog-perspective-performance-reliability skill to your agent setup.
  3. Configure the agent to run this perspective on the pull request chunk.
  4. Review the performance and reliability findings it reports, with severities.

What this skill tells your AI

The instructions your AI receives, as published by posthog/posthog in products/review_hog/skills/review-hog-perspective-performance-reliability/SKILL.md and read by Ahel’s review.

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

Signals

GitHub stars
40k
Forks
3k
Last commit
Oct 2026

Questions

What does this skill report?
It reports performance and reliability issues only, such as slow queries, missing error handling, scalability risks, and operational readiness gaps. Logic and security findings are left to other review perspectives.
Does it check logic or security?
No. This perspective stays in its lane and covers performance and reliability. Logic and security are handled by other independent perspectives reviewing the same chunk in parallel.
What severity levels does it assign?
Each finding gets a severity from must-fix to consider.
Does it review test files?
No. It detects issues only in non-test files and skips vendor, third-party, and generated files.
Advanced
Item type
skill
Key
review-hog-perspective-performance-reliability-posthog
Source
github.com/posthog/posthog