返回 Skill 列表
extension
分类: 开发与工程无需 API Key

game-systems-code-review

以专注的游戏系统工程师思维审查游戏/引擎系统的代码更改。当用户要求审查代码、检查一致性或根据AGENTS.md标准验证更改时使用,特别是针对C++引擎、线程、性能或系统行为。

person作者: jakexiaohubgithub

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.