/meta-reviewing-reviewing

name: meta-reviewing-reviewing
description: Code review patterns, feedback principles. Use when reviewing PRs, implementations, or making approval/rejection decisions. Covers self-correction, progress tracking, feedback principles, severity levels.

Reviewing Patterns

> **Quick Guide:** Read ALL files completely before commenting. Provide specific file:line references for every issue. Distinguish severity (Must Fix vs Should Fix vs Nice to Have). Explain WHY, not just WHAT. Suggest solutions following existing patterns. Acknowledge good work - positive reinforcement teaches what to repeat.

---

<critical_requirements>

CRITICAL: Before Any Review

**(You MUST read ALL files mentioned in the PR/spec completely before providing feedback)**

**(You MUST provide specific file:line references for every issue found)**

**(You MUST distinguish severity: Must Fix vs Should Fix vs Nice to Have)**

**(You MUST explain WHY something is an issue, not just WHAT is wrong)**

**(You MUST verify success criteria are met with evidence before approving)**

**(You MUST acknowledge what was done well - not just issues)**

</critical_requirements>

---

**Auto-detection:** code review, PR review, pull request, review code, check implementation, verify changes

**When to use:**

• Reviewing any code changes (PRs, implementations, specs)
• Providing structured feedback on code quality
• Making approval/rejection decisions
• Ensuring codebase standards are maintained

**When NOT to use:**

• When implementing code (use developer skills instead)
• For automated linting/type-checking (use CI/CD tooling)
• For deep security audits (use dedicated security review)
• For high-level architecture decisions (use planning/PM workflows)

**Key patterns covered:**

• Self-correction checkpoints for reviewers
• Post-action reflection after reviews
• Progress tracking for multi-file reviews
• Feedback principles (specific, explain why, suggest solutions, severity, acknowledge good)
• Decision framework for approval/rejection
• Review-specific anti-patterns (scope creep, refactoring, not using utilities)

**Detailed Resources:**

• [examples/core.md](examples/core.md) - All examples: progress tracking, feedback patterns, anti-patterns

---

<philosophy>

Philosophy

Code review is about **improving code quality while teaching good patterns**. Every piece of feedback should help the author become a better developer. Be direct but constructive.

**When reviewing code:**

• Always read the full context before commenting
• Base feedback on facts, not assumptions
• Distinguish blocking issues from improvements
• Teach through your feedback - explain the "why"
• Recognize good work to reinforce patterns

**When NOT to be harsh:**

• Don't nitpick style when code is functionally correct
• Don't request changes for personal preference
• Don't block PRs for minor issues that can be follow-ups
• Don't forget that the author worked hard on this

**Core principles:**

• **Evidence-based**: Base all feedback on what you actually read
• **Actionable**: Every issue should have a clear path to resolution
• **Proportional**: Match feedback severity to actual impact
• **Educational**: Help authors understand WHY, not just WHAT
• **Balanced**: Acknowledge good work alongside issues

</philosophy>

---

<patterns>

Core Patterns

Pattern 1: Self-Correction Triggers

These checkpoints prevent review drift and ensure thorough analysis. Check yourself throughout the review process.

**Self-Correction Checkpoints:**

| Trigger | Correction | | ------------------------------------------------- | ------------------------------------------ | | Providing feedback without reading full file | Stop. Read the complete file first. | | Saying "this needs improvement" without specifics | Stop. Provide file:line references. | | Approving without checking success criteria | Stop. Verify each criterion with evidence. | | Focusing only on issues | Stop. Add positive feedback. | | Making assumptions about code behavior | Stop. Read the actual implementation. | | Flagging issues without explaining WHY | Stop. Add rationale for each issue. | | Reviewing code outside your domain | Stop. Defer to specialist reviewer. |

---

Pattern 2: Post-Action Reflection

After completing your review, verify quality before finalizing.

**Reflection Questions:**

1. Did I read all relevant files completely before commenting? 2. Did I check against all success criteria in the spec? 3. Are my issues specific (file:line) and actionable? 4. Did I distinguish severity correctly (blocker vs improvement)? 5. Did I acknowledge what was done well? 6. Should any part go to a specialist reviewer? 7. Is my recommendation (approve/request changes) justified?

**Only finalize review when you can answer "yes" to all applicable questions.**

---

Pattern 3: Progress Tracking

For multi-file reviews, track your progress to maintain orientation.

**Track These Elements:**

1. **Files Examined:** [list of files read completely] 2. **Success Criteria Status:** [checked/unchecked for each criterion] 3. **Issues Found:** [categorized by severity] 4. **Positive Patterns Noted:** [what was done well] 5. **Deferred Items:** [what needs specialist review]

For tracking examples, see [examples/core.md](examples/core.md).

---

Pattern 4: Feedback Principles

All feedback should follow these principles for maximum effectiveness.

Be Specific

Every issue needs a precise location and actionable detail.

Explain Why

Don't just say what's wrong -- explain the impact so authors learn.

Suggest Solutions

Point to existing patterns when possible.

Distinguish Severity

Use clear markers to communicate priority:

| Marker | Category