rhdh-pr-review: restore useful guidance in natural voice

- Bring back follow-up summary exception (scope changed, different revision)
- Bring back severity tiering (substantial findings get full comments,
  nits can be grouped as one-liners)
- Bring back calling out good decisions by name (not generic praise)

Author: schultzp2020

skills/rhdh-pr-review/workflows/review-code.md

@@ -59,15 +59,15 @@ The posted review should read like a person wrote it, not a report generator. Th
 
 Keep it short and direct — frame what the inline comments are about so the author knows the scope at a glance. Include a requirements coverage note if linked issues were checked. Skip performative praise; it reads as filler.
 
-If `existing_reviews` shows you've already left a top-level comment on this PR, a new one is often unnecessary — consider posting only the inline findings to reduce noise.
+If `existing_reviews` shows you've already left a top-level comment on this PR, a new one is often unnecessary — consider posting only the inline findings. A follow-up summary is still warranted if the scope of feedback changed significantly or the prior review was on a different revision.
 
 ### Inline comments
 
-Post one inline comment per finding worth raising — no artificial cap. Never leave a comment just to show you noticed something.
+Post one inline comment per finding worth raising — no artificial cap. Never leave a comment just to show you noticed something. Not every finding needs the same weight — substantial issues get a full comment, nits can be grouped into a single comment as one-liners.
 
 Write each comment as natural prose — a short paragraph explaining the issue and why it matters. Avoid bullet lists, bold headers, and over-structured formatting. Keep just enough information for the author to understand the problem and act on it. Code suggestions and code blocks are fine since they're functional, not formatting.
 
-Assume deliberate choices. Ask why before suggesting alternatives. Explain reasoning only when the fix isn't obvious.
+Assume deliberate choices. Ask why before suggesting alternatives. Explain reasoning only when the fix isn't obvious. Call out specific things done well when genuine — name the pattern or decision, not generic praise.
 
 **If nothing significant survives verification**, that's a valid outcome. Produce a short approving review. Don't manufacture issues.