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.
1---2name: game-systems-code-review3description: 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.4---5
6# Game Systems Code Review
7
8## Overview
9
10Perform focused code reviews for game/engine systems, emphasizing correctness, performance, threading safety, and adherence to AGENTS.md standards.
11
12## Workflow
13
14### 1. Intake and scope
15
16- Ask for the diff/PR scope if not provided, or identify it via `git diff`/targeted files.
17- Confirm the standards source: read `AGENTS.md` in the repo root for required patterns and constraints.
18- Identify the subsystem(s) involved (engine loop, AI, input, resource, world, etc.).
19
20### 2. Review focus areas (Game Systems Engineer lens)
21
22- **Correctness and regressions**: fixed timestep behavior, update/render sequencing, deterministic ordering.
23- **Threading and safety**: no background rendering, no static vars in threaded code, ThreadSystem usage.
24- **Performance**: avoid per-frame allocations, reuse buffers, reserve capacity, batch where expected.
25- **API and ownership**: `std::string_view` vs `std::string`, RAII, smart pointers, lifetime safety.
26- **Consistency with architecture**: manager patterns, buffer swaps, event batching, camera usage.
27- **Platform pitfalls**: SDL subsystem cleanup pattern, cross-platform guards, SDL boundary usage.
28- **Style and naming**: Allman braces, C++20, naming conventions, header/inline rules.
29
30### 3. Findings output format
31
32Use a code-review-first response:
33
34- Findings ordered by severity with file/line references.
35- Call out behavior regressions, race risks, or perf traps before style issues.
36- If no findings, say so explicitly and mention remaining risks or testing gaps.
37- Include open questions/assumptions after findings.
38- Provide a brief change summary only after findings.
39
40### 4. Testing suggestions
41
42Recommend targeted tests relevant to the changes (unit, system, or scripts). Do not run tests unless asked.
43
44## Notes
45
46- Prefer minimal, concrete recommendations over broad refactors.
47- Avoid modifying code; focus on review and guidance.
48- If the user only says “review my changes,” ask which files/PR or use `git diff` to scope.