Review Code Quality
Inspect the declared review subject and produce a concise report using
templates/review-report.md.
Workflow
- Bind the review to the declared diff, commit, pull request, patch, file set,
or module and identify its expected behavior.
- Read enough surrounding code, tests, and repository conventions to judge
the change in context.
- Report only actionable findings. For each finding, give severity, location,
observed problem, impact, and correction direction.
- Mark an uncertain concern as a verification gap. Keep unrelated
pre-existing debt separate from the scored change.
- Score all five dimensions independently with integer values from 1 to 5.
- Return the verdict. Do not edit the reviewed code.
Five Scores
- Correctness: expected behavior, edge cases, state changes, and error
semantics.
- Simplicity and readability: clear control flow, necessary complexity,
duplication, dead code, and avoidable abstraction.
- Error handling and fallback integrity: swallowed failures, false
success, silent degradation, unjustified defaults, unbounded retries, and
unobservable or untested fallback.
- Design and maintainability: responsibility boundaries, coupling,
change isolation, consistency with repository patterns, and future repair
cost.
- Tests and risk control: meaningful verification plus relevant security,
data, performance, concurrency, compatibility, and operational risk.
Use the same scale for every dimension:
5: reliable and clear; no substantive issue found.4: good; only minor improvement remains.3: acceptable; clear quality debt or verification gap remains.2: material problem; change is required.1: severe or systemic failure.
Do not deduct without evidence. Do not score code length by itself. Do not
penalize a fallback merely for existing; penalize it when it is implicit,
unbounded, contract-changing, unobservable, or untested. Avoid counting one
problem as several independent defects.
Verdict
approve: no required-change finding and all scores are 4 or 5.approve_with_comments: no critical or major finding, no score below 3,
and at least one minor issue or score of 3.changes_required: any critical or major finding, or any score of 1 or 2.blocked: the review subject, expected behavior, or essential evidence is
missing or cannot be inspected.
The total out of 25 is informational. Never let it override the verdict rules.
1---2name: review-code-quality3description: Review a declared code change or code scope with evidence-backed findings and five independent quality scores. Use for pull requests, diffs, commits, patches, file sets, modules, bug fixes, refactors, and implementation-review requests.4---56# Review Code Quality78Inspect the declared review subject and produce a concise report using9`templates/review-report.md`.1011## Workflow12131. Bind the review to the declared diff, commit, pull request, patch, file set,14 or module and identify its expected behavior.152. Read enough surrounding code, tests, and repository conventions to judge16 the change in context.173. Report only actionable findings. For each finding, give severity, location,18 observed problem, impact, and correction direction.194. Mark an uncertain concern as a verification gap. Keep unrelated20 pre-existing debt separate from the scored change.215. Score all five dimensions independently with integer values from 1 to 5.226. Return the verdict. Do not edit the reviewed code.2324## Five Scores25261. **Correctness**: expected behavior, edge cases, state changes, and error27 semantics.282. **Simplicity and readability**: clear control flow, necessary complexity,29 duplication, dead code, and avoidable abstraction.303. **Error handling and fallback integrity**: swallowed failures, false31 success, silent degradation, unjustified defaults, unbounded retries, and32 unobservable or untested fallback.334. **Design and maintainability**: responsibility boundaries, coupling,34 change isolation, consistency with repository patterns, and future repair35 cost.365. **Tests and risk control**: meaningful verification plus relevant security,37 data, performance, concurrency, compatibility, and operational risk.3839Use the same scale for every dimension:4041- `5`: reliable and clear; no substantive issue found.42- `4`: good; only minor improvement remains.43- `3`: acceptable; clear quality debt or verification gap remains.44- `2`: material problem; change is required.45- `1`: severe or systemic failure.4647Do not deduct without evidence. Do not score code length by itself. Do not48penalize a fallback merely for existing; penalize it when it is implicit,49unbounded, contract-changing, unobservable, or untested. Avoid counting one50problem as several independent defects.5152## Verdict5354- `approve`: no required-change finding and all scores are 4 or 5.55- `approve_with_comments`: no critical or major finding, no score below 3,56 and at least one minor issue or score of 3.57- `changes_required`: any critical or major finding, or any score of 1 or 2.58- `blocked`: the review subject, expected behavior, or essential evidence is59 missing or cannot be inspected.6061The total out of 25 is informational. Never let it override the verdict rules.
seemseam