| name | code-review |
| description | Review AALC uncommitted changes, staged diffs, commits, branches, pull requests, upstream contributions, or downstream sync branches for confirmed defects, regressions, automation safety, i18n drift, upstream-style mismatch, unnecessary defaults, one-use underscore variables, and maintainability risks. Use for initial review and every re-review after changes or feedback. |
AALC Code Review
Act as the review coordinator. Establish the target, collect enough source context, route domains to named specialist reviewers, verify findings, deduplicate them, and issue one evidence-based verdict. Do not treat a raw diff or a passing test as sufficient review context.
Resolve the target
| Intent | Evidence to collect |
|---|
| Uncommitted work | git status --short, unstaged and staged stats/diffs |
| Staged work | git diff --cached --stat and full staged diff |
| Commit | git show --stat <sha> and full patch |
| Branch | base/head SHAs, commit list, three-dot stat and full diff |
| Pull request | PR metadata, base/head SHAs, full PR diff, checks, prior reviews and unresolved threads |
| Re-review | prior reviewed SHA, current SHA, delta since prior review, full current diff, stable finding ledger and prior decisions |
If no target is specified, review both staged and unstaged changes. Preserve unrelated user work and perform no edits unless the user separately asks for fixes.
Build review context
Before dispatching reviewers:
- identify the stated intent and expected behavior;
- read the full changed definitions, not only patch fragments;
- read direct callers, API signatures, config schemas, tests, or generators that determine correctness;
- distinguish changed behavior from pre-existing code;
- note verification already performed and gaps still open.
For very large diffs, batch by coherent subsystem or behavior. Diff size controls batching depth, not which domain reviewers apply.
Domain-based reviewer routing
Always run the general correctness review. Add specialists when their domain is touched:
| Reviewer | Select when |
|---|
code-reviewer | Always |
automation-reviewer | module/automation/**, module/game_and_screen/**, tasks/**, app/my_app.py, config mutation, input, retry/wait, task lifecycle, singleton, or stop behavior |
i18n-reviewer | user-visible UI strings, QWidget lifecycle, translations, localized images, assets/config/config.example.yaml, or translation scripts |
For upstream contributions, also provide .agents/skills/upstream-contribution/references/upstream-style-review.md to the general reviewer and require comparison with the upstream target tree.
In OpenCode, invoke the custom agents by their exact names. Do not dispatch a general agent and ask it to impersonate a named reviewer. In another environment, use equivalent dedicated reviewers when available; otherwise perform the domain checklist synchronously and state that fallback.
Pass each reviewer:
- target and base/head SHAs;
- intent or behavior contract;
- changed-path list and complete diff;
- locations of the full source context already identified;
- relevant prior findings for a re-review;
- only the domain-specific reference it needs.
Review generated and non-code files proportionally
Do not ignore a file merely because it is generated or binary:
- lockfiles: verify they correspond to intentional dependency-manifest changes and flag unexplained churn;
- compiled translations: verify the source translation and generator relationship rather than line-reviewing binary output;
- images: verify key, language/theme placement, dimensions, and code references when the change depends on them;
- changelog/release metadata: check accuracy when part of release scope;
- minified or bundled output: verify source/generator provenance and unexpected inclusion;
- CI, build scripts, example config, migrations, and update manifests: review as behavior-bearing artifacts.
Coordinator verification
For every proposed finding:
- locate the changed line or directly impacted behavior;
- reproduce the trigger path from source, test, or specification;
- reject speculative, pre-existing, or preference-only comments;
- calibrate severity by user impact and reachability;
- merge duplicates while preserving the clearest trigger and fix direction.
For a re-review, also verify that a new finding is caused by a changed line, newly affected behavior, or a newly evidenced interaction. A pre-existing path that the diff does not newly invoke, change, or rely on is not an eligible blocker.
Do not suppress a concrete defect because it crosses reviewer domains. Assign it to the most relevant domain and keep one finding.
AALC-specific checks
Confirm changed code respects project invariants, including:
- singleton reuse and
cfg.set_value() versus cfg.unsaved_set_value() semantics;
- mediator-based cross-component communication;
- cooperative stop propagation and bounded waiting;
- PySide6 UI, translation, and theme lifecycle;
- image loading and template-matching pipeline;
- config typing/example synchronization;
- ASCII-only output in
scripts/build.py;
- no explicit repetition of API defaults without a concrete reason.
For ported code, additionally check one-use underscore-prefixed variables, constants, parameters, and helpers; wrapper-only abstractions; downstream-only scaffolding; and mismatch with adjacent target-tree naming, logging, error handling, or test style.
Guidance freshness
When a change alters package management, test/build workflow, required environment, directory structure, CI/CD, cross-module contracts, or durable project invariants, assess whether AGENTS.md, skills, agents, or mechanical checks need an update. Use agent-guidance-health for substantive guidance changes; do not inflate AGENTS.md with one-off details.
Re-review protocol
On every PR or branch update:
- retain stable finding IDs and verify which prior items are fixed, still present, superseded, disputed, or rejected with evidence;
- review the delta for regressions introduced by the fix;
- review the complete current diff for interaction effects;
- require every genuinely new finding to identify its changed or directly affected trigger path;
- bind the result to the current head SHA;
- do not repeat unchanged prose as a new finding or reopen a settled item without new evidence—update its existing state instead.
If a proposed correction widens timeout/retry semantics, lifecycle ownership, public APIs, dependencies, configuration, or explicit non-goals, classify it as a scope decision before asking an implementer to change code. Reviewer severity alone does not authorize scope expansion.
A re-review is required after conflict resolution, maintainer edits, rebase, or any pushed fix that changes reviewed code.
Verdict matrix
| Highest remaining result | Verdict |
|---|
| Confirmed Critical or High defect | Block |
| Confirmed Medium production risk, or a repeated pattern of Medium defects | Warning |
| Only Low/Suggestion items or non-blocking verification gaps | Approve with comments |
| No actionable findings and verification is adequate for the risk | Approve |
If verification is materially incomplete, do not use plain Approve. Human override instructions may change the merge decision, but record the unresolved technical risk.
Output
## 审阅概览
- 目标与 base/head：
- 意图与风险面：
- 实际调度：
- 已读上下文：
- 已执行验证：
## 发现
- [RV-01] [Critical/High/Medium/Low/Suggestion] `文件:行` [领域] — 触发条件、影响、证据和修复方向。
## 复审状态
- [RV-01] 已修复 / 仍存在 / 新增 / 不再适用：
## 指引保鲜
- 无需更新，或应更新的常驻规则 / skill / 检查：
## 验证缺口与假设
- 只列影响结论的内容。
**裁决：Block / Warning / Approve with comments / Approve**
When there are no findings, say so explicitly and still report meaningful verification gaps and the reviewed head SHA.
