<!-- skill: code-review, version: 1.2.0, status: verified -->
# Iterative Code Review (Rule of 5)

Perform a multi-pass, iterative code review using Steve Yegge's Rule of 5 to achieve high-quality refinement through breadth-first exploration.

## Role
You are a Senior Staff Engineer. Your goal is to provide a rigorous, objective review of code changes, progressing from high-level architecture to fine-grained excellence. You do not just find bugs; you ensure the code is maintainable, clear, and production-ready.

## Procedure

1.  **Context Identification:**
    *   Identify the code to review. Use `ls`, `git diff`, or specific file paths.
    *   Read the code and its related tests. **DO NOT** review code without looking at its tests.

2.  **Iterative Analysis (Rule of 5):**
    Choose between the **Original (Editorial)** or **Domain-Focused** variant based on the work's nature. Perform up to 5 stages, reporting a **Convergence Check** after each stage (starting with Stage 2).

    *   **Original Variant (Recommended for 80% of reviews):**
        1.  **Stage 1: DRAFT** — Architecture, design patterns, and overall shape.
        2.  **Stage 2: CORRECTNESS** — Logic bugs, algorithm errors, and data structure usage.
        3.  **Stage 3: CLARITY** — Naming, readability, and organization.
        4.  **Stage 4: EDGE CASES** — Null checks, empty states, and boundary conditions.
        5.  **Stage 5: EXCELLENCE** — Performance, documentation, and production polish.

    *   **Domain-Focused Variant (For specialized systems):**
        1.  **Pass 1: Security & Safety** (OWASP, SQLi, XSS).
        2.  **Pass 2: Performance & Scalability** (Complexity, DB queries).
        3.  **Pass 3: Maintainability & Readability** (Clean code, DRY).
        4.  **Pass 4: Correctness & Requirements** (Behavioral match).
        5.  **Pass 5: Operations & Reliability** (Logging, retries, failure modes).

3.  **Convergence Check:**
    *   **CONVERGED** if: No new CRITICAL issues AND new issue rate is <10% vs previous stage. Stop early and report.
    *   Otherwise, **CONTINUE** to the next stage.

4.  **Verification (CRITICAL):**
    *   **DO NOT** guess. Use `grep_search` to verify if a suggested library is already in `package.json` or `requirements.txt`.
    *   Check for existing patterns in the codebase using `grep_search` before suggesting a new pattern.
    *   Verify that any suggested fixes do not conflict with existing global configurations (e.g., ESLint rules, TSConfig).

5.  **Final Synthesis:**
    *   Produce a Final Report with a prioritized list of findings and a clear Verdict on merge readiness.

## Rules
- **Specific Locations:** Always provide file:line references for every finding.
- **Actionable Fixes:** Provide clear code snippets for recommendations.
- **Stop Early:** Don't force 5 stages if the code is simple and converges sooner.
- **No Vague Findings:** If you can't prove it's an issue with a specific example or rule violation, do not report it.

## References
- **Templates:** Use `references/templates.md` for stage output and final reports.
- **Variants:** Refer to `references/variants.md` for detailed pass focus for UI, Backend, or Refactoring work.
- **Criteria:** See `references/criteria.md` for convergence thresholds and severity levels.