| name | code-review |
| description | 对指定文件或文件集执行架构和质量的代码审查。检查编码标准合规性、架构模式遵守情况、可测试性、性能和安全风险。 Use when this capability is needed. |
| metadata | {"author":"ailess-lab"} |
Code Review
/code-review 是 CFG 的代码质量入口。它是只读审查，不修改文件。
It also covers former technical-debt, perf-profile, and security-audit concerns when the concern is tied to code or architecture changes.
For broad release readiness, route to /release-checklist. For runtime evidence failures, route to B-dev through the active work order and lane state. Do not route to removed sprint/story/smoke commands.
Required Context
Read:
- target files in full
AGENTS.md.codex/docs/technical-preferences.md- relevant
docs/architecture/*.md
- relevant
production/work-orders/*.md if the user provided one or the touched paths clearly belong to one
- relevant B-dev evidence/report if present
If a work order path is supplied, read it first to extract:
- scope and non-scope
- delivery spec
- stop conditions
- evidence requirements
- ADR/canon references
If no work order or ADR is found, say so and continue with a code-only review.
CFG Specialist Policy
The inherited 49 CCGS agent files are not active. Do not read .codex/agents/. Apply engine, shader, UI, architecture, security, performance, and testability lenses directly in-session.
Review Checklist
Work Order Compliance
- implementation stays inside Scope and Non-scope
- delivery spec is satisfied or gaps are named
- stop conditions were not ignored
- evidence hooks or validation paths exist
ADR And Architecture Compliance
- referenced ADRs are followed
- implementation does not contradict accepted architecture
- Godot node/resource/autoload ownership is clear
- signals/events do not create hidden circular dependencies
- save/load, input, physics, and scene lifecycle obey project rules
Standards
- methods/classes have appropriate names and comments where useful
- complexity is reasonable
- dependencies are explicit
- configuration values are data/config driven when appropriate
- generated/imported assets are not treated as source logic
Testability And Evidence
- B-dev can validate the change with an available command, scene, test, capture, or manual step
- important behavior has an observable runtime path
- acceptance criteria from the work order are testable
- no new edge case is introduced without evidence or follow-up owner
Performance And Safety
- no avoidable allocations in hot paths
- frame-rate and physics timing are handled correctly
- file IO, save data, networking, and external data are validated
- error states fail clearly rather than silently corrupting state
Output
Findings first, ordered by severity. Use file/line references.
## Code Review: [target]
Findings:
- [P0/P1/P2/P3] [file:line] [issue, impact, required fix]
Open Questions:
- [only if needed]
Work Order / ADR Compliance:
- [COMPLIANT / DRIFT / VIOLATION / NOT PROVIDED]
Testability:
- [TESTABLE / GAPS / BLOCKING / N/A]
Summary:
- [short change/context summary]
Verdict: APPROVED / APPROVED WITH CONCERNS / CHANGES REQUIRED
If no issues are found, say that clearly and mention residual risk or unrun tests.
Next Step
After the review:
- If approved and tied to an active work order, hand back to the owning lane for delivery/verdict.
- If changes are required, route to
B-dev for code fixes.
- If architecture is wrong or missing, route to
/create-architecture.
- If the issue affects player-facing feel, visual quality, or canon, request
D-director verdict.
Do not ask the user to run removed story/sprint completion commands.
Source: ailess-lab/CodexForGodot — distributed by TomeVault.
