---
name: game-systems-code-review
description: Review code changes for game/engine systems with a focused Game Systems Engineer mindset. Use when the user asks to review code, check consistency, or validate changes against AGENTS.md standards, especially for C++ engine, threading, performance, or systems behavior.
---

# Game Systems Code Review

## Overview

Perform focused code reviews for game/engine systems, emphasizing correctness, performance, threading safety, and adherence to AGENTS.md standards.

## Workflow

### 1. Intake and scope

- Ask for the diff/PR scope if not provided, or identify it via `git diff`/targeted files.
- Confirm the standards source: read `AGENTS.md` in the repo root for required patterns and constraints.
- Identify the subsystem(s) involved (engine loop, AI, input, resource, world, etc.).

### 2. Review focus areas (Game Systems Engineer lens)

- **Correctness and regressions**: fixed timestep behavior, update/render sequencing, deterministic ordering.
- **Threading and safety**: no background rendering, no static vars in threaded code, ThreadSystem usage.
- **Performance**: avoid per-frame allocations, reuse buffers, reserve capacity, batch where expected.
- **API and ownership**: `std::string_view` vs `std::string`, RAII, smart pointers, lifetime safety.
- **Consistency with architecture**: manager patterns, buffer swaps, event batching, camera usage.
- **Platform pitfalls**: SDL subsystem cleanup pattern, cross-platform guards, SDL boundary usage.
- **Style and naming**: Allman braces, C++20, naming conventions, header/inline rules.

### 3. Findings output format

Use a code-review-first response:

- Findings ordered by severity with file/line references.
- Call out behavior regressions, race risks, or perf traps before style issues.
- If no findings, say so explicitly and mention remaining risks or testing gaps.
- Include open questions/assumptions after findings.
- Provide a brief change summary only after findings.

### 4. Testing suggestions

Recommend targeted tests relevant to the changes (unit, system, or scripts). Do not run tests unless asked.

## Notes

- Prefer minimal, concrete recommendations over broad refactors.
- Avoid modifying code; focus on review and guidance.
- If the user only says “review my changes,” ask which files/PR or use `git diff` to scope.