kkkirito-123/zlagent/code-review-quality

code-review-quality

Trigger

Activate after writing or editing code and BEFORE running the final verification step. Also activate when the user pastes code and asks for a review, or when the agent wants to gate a skill update.

Principle

Reviews catch what tests cannot see: intent drift, silent regressions,

and code that technically works but will break the next editor.

Inputs

• changed_files: the files / hunks to review.
• purpose: one-line statement of what the change should achieve.
• reference: original spec, issue, or plan the change maps to.

Steps

1. Intent check — does each edit map back to a line in purpose?

Flag hunks that drift.

1. Scope creep — unrelated renames / formatting mixed into a

focused fix? Split if non-trivial.

1. Error handling — new call sites to I/O / HTTP / subprocess have

explicit error paths (not just except Exception: pass)?

1. Tests — did any existing assertion weaken (broader tolerance,

deleted edge case)? Restore or justify.

1. Invariants — was a class invariant (e.g. "every tool row has a

permission tier") maintained?

1. Dead paths — code added that is never reachable from the

feature's entry point? Drop.

1. Logging / observability — significant state change logged? On

the happy path only, or also on failure?

1. Names — any new symbol that will be misleading in 3 months?

Rename if yes, keep if no.

1. Non-goal check — the change should NOT accidentally handle

something out of scope (e.g. a skill refactor that changes memory policy).

Output Format

Grade each finding as:

• 🟥 must-fix: blocks merge.
• 🟧 should-fix: merge allowed but tracked.
• 🟩 nit: optional polish.

### code-review-quality findings
 
- 🟥 _<file>:<line>_  <one-line issue>  — _why it matters_
- 🟧 ...
- 🟩 ...
 
(零 must-fix 时写 "✅ no blocking issues found")

Verification

• Every finding cites <file>:<line>.
• Must-fix items are addressed before declaring done.
• No finding is vague ("looks weird") — each has a concrete trigger.

Failure Signals

• 0 findings on a 300-line diff: review was rubber-stamped.
• "nit" storm with no must-fix on a patch that later breaks: the

gradient is wrong — recalibrate severity thresholds.

• The same class of issue appears repeatedly across reviews: promote

it to a guardrail (skill, hook, or lint rule).