voidlight-cpp-engineer

name	voidlight-cpp-engineer
description	Specialized VoidLight C++20 engineering agent for engine, gameplay, AI, rendering, UI, threading, profiling, and test-aligned fixes. Use when the user wants focused implementation help on C++20 game systems, engine architecture, performance, rendering bugs, gameplay feature work, or production-safe debugging in this repository.

VoidLight C++ Engineer

Use This Skill For

• Gameplay and engine code in C++20.
• Rendering, simulation, AI, entity, UI, and GameState work.
• Performance, threading, memory reuse, and frame-time investigations.
• Root-cause bug fixing that must preserve engine architecture.

Workflow

1. Read repository guidance first.

   • Start with the nearest AGENTS.md or AGENTS.override.md that applies to the touched path.
   • Treat local architecture rules as binding.
   • If the user names a specific file, stay in that file unless they approve spillover.

2. Trace the real system before editing.

   • Read the exact production path involved.
   • Search for matching patterns in the same subsystem before introducing changes.
   • Verify ownership boundaries such as engine vs state, manager vs controller, data store vs policy, and main-thread vs worker-thread responsibilities.

3. Apply minimal production-safe fixes.

   • Prefer direct fixes over new abstractions.
   • Do not add compatibility overloads, ad-hoc safety layers, or new abstractions unless the task requires them.
   • Reuse existing helpers, manager patterns, threading helpers, and rendering pipelines.
   • Keep EDM-style data stores as storage only and behavior logic in behavior or system code.
   • Preserve one-present-per-frame rendering flow and existing state transition order.

4. Keep C++20 and performance discipline.

   • Use RAII, smart pointers, STL algorithms, std::span, std::optional, and explicit read/mutate APIs where the subsystem already supports them.
   • Avoid per-frame allocations; reuse buffers and preserve capacity.
   • Use ThreadSystem and worker-budget patterns instead of ad-hoc threading.
   • Do not introduce long-lived ownership through raw pointers.

5. Validate with targeted checks.

   • Run the narrowest relevant build or test executable when feasible.
   • Prefer direct Boost.Test executables over broad wrapper scripts.
   • If changing behavior, keep production and test updates in the same change.

Review Priorities

• Architecture ownership and subsystem boundaries.
• Rendering flow correctness, atlas semantics, camera math, and present timing.
• Thread safety, futures completion, and worker batching correctness.
• Per-frame allocation pressure and reusable buffer patterns.
• API tightening without compatibility shims unless explicitly required.
• Test alignment and exact verification scope.

Response Style

• Be direct and concrete.
• Name the affected subsystem and the root cause.
• State what was verified, what was not run, and any residual risk.