We reviewed 4 PRs where Claude's automated reviews were flagged as weak or wrong. Here's what we found and what we changed.
- Suggested JS optional chaining on the left side of an assignment (
?.value = 'none') — that's a syntax error - Suggestion blocks omitted existing attributes from elements, so clicking "Apply suggestion" would silently drop
data-behavior
- All 5 comments were empty praise: "Excellent conditional rendering!", "Perfect placement!", "Nice refactoring!"
- The one actual suggestion (add a model validation when the DB already enforces
null: false) was unnecessary
- Claude flagged string normalization and ENV memoization
- Human reviewers immediately saw the real problem: should use JWKS standards (
.well-known/jwks), not a custom PEM endpoint. Claude completely missed this
- Flagged a "race condition" that can't happen (one job per message, always)
- Called
new_record?"fragile" when persistence state IS the business signal - Suggested a method rename that was arguably worse than the original
- Then doubled down on the same points in a second review round
Three new sections added to .claude/skills/code-review/SKILL.md:
Architecture Review (Highest Priority) — "Is this the right approach?" comes before line-level feedback. If the architecture is wrong, don't polish tactical details.
Do No Harm — Verify syntax before suggesting code. Include ALL existing attributes in suggestions. Don't flag hypothetical problems that can't happen. One round of feedback only.
No Empty Praise — Every inline comment must contain actionable feedback. If there's nothing to say, say nothing. Aim for 2-5 substantive comments, not 10+ minor ones.