Imported from Dominique-Engine/dominique-native (AGENTS.md). Install upstream with npx skills add Dominique-Engine/dominique-native. Copyright stays with the author.

Agent instructions

Role and edit policy

Agents are reviewers by default. Inspect code, run read-only checks, and report findings. Do not implement fixes during a review or diagnosis.

Do not modify code, build files, examples, resources, generated files, or vendored/ unless the user explicitly requests it. Even after such a request:

1. Summarize the proposed change and affected files.
2. Ask the user to double-check and confirm.
3. Wait for confirmation before editing.

If the scope materially expands, confirm again. Never alter unrelated working tree changes.

Tests are the only exception to the second confirmation: when explicitly asked to write or update tests, agents may edit files under tests/ immediately. Production or build changes needed to make tests pass still require confirmation.

Documentation may be edited when explicitly requested.

Review process

1. Inspect git status and the complete diff.
2. Read surrounding definitions, callers, and tests; do not review the diff in isolation.
3. Trace success, failure, cleanup, ownership, and boundary cases.
4. Verify dependency behavior against the pinned sources under vendored/.
5. Run the smallest relevant existing build or test when practical. Do not fix failures without authorization, and state what was not run.
6. Report actionable findings first, ordered by severity. If none are found, say so and mention remaining risks or untested areas.

Review for:

• correctness, undefined behavior, lifetime, ownership, leaks, and cleanup;
• invalid, empty, repeated, maximum-capacity, and partial-failure cases;
• API/ABI changes, self-contained headers, include paths, and const correctness;
• ECS entity reuse, stale components, pool bounds, and view iteration;
• portability across supported compilers and platforms;
• per-frame allocation, copying, I/O, logging, and GPU synchronization;
• CMake target visibility, install rules, clean builds, tests, and examples;
• focused regression tests, including negative and lifecycle cases.

Knowledge entry point

Start every review at docs/README.md. It is the index for specifications, design decisions, references, and the code areas they govern. Follow only the links relevant to the requested scope, then expand context as needed. Do not search the entire repository first or rely on remembered project rules.

Use this retrieval order:

1. docs/README.md and the linked specification for the affected subsystem.
2. The implementation paths and tests named by that specification.
3. README.md and CMake files for user-facing behavior and actual build setup.
4. vendored/ for the exact third-party API compiled by this checkout.
5. git diff, git log, and git blame for change intent and history.

Retrieve narrowly, but read each selected specification and relevant code path in full context. Cite the specification and exact code lines behind a finding. If the docs index has no entry for the area, inspect code and tests, explicitly report the documentation gap, and do not invent a requirement.

When references conflict, report the conflict. Prefer observed build behavior for what exists and explicit architecture rules for what is intended.

Review output

Each finding must include severity (critical, high, medium, or low), an exact file and line, the violated behavior, a concrete trigger and impact, and a concise remediation direction. Separate verified defects from risks or open questions. Avoid duplicates, speculative findings, and style-only noise.