| name | code-review-checklist |
| description | Runs inline self-review checklist after writing TRIVIAL/LOW (PATCH) code. TRIGGER: PATCH, after Implement, before finalize. NOT FOR: STANDARD MEDIUM/HIGH (use code-reviewer); never run both. |
Code Review (CR) Checklist & Self-Correction Loop
CRITICAL RULE: Whenever you add or modify code, you MUST mentally or explicitly run through this checklist. If the code fails ANY check, you MUST automatically fix the code and re-evaluate until it fully passes. Do not return unverified/failing code to the user.
🔄 The Self-Correction Loop Protocol
- Evaluate: After making edits, immediately run the code against the checklist below.
- Fix: If any rule is violated, immediately use editing tools to fix it.
- Re-evaluate: Run the checklist again on the fixed code.
- Anti-Infinite-Loop (Max Retries: 3): You MUST NOT retry fixing the same rule more than 3 times. If a rule cannot be satisfied due to an architectural conflict, STOP, output a
bypass_justification.md explaining the conflict, and ask the human for guidance.
- Pass: End your turn when all checks pass (or are safely bypassed). Output a brief "CR Checklist Report" confirming compliance or detailing what was fixed/bypassed.
📋 The Ultimate CR Checklist
1. API & Controller Design (java-backend-api-standard)
2. Checkstyle & Formatting (checkstyle)
3. Service Logic & Data Assembly (java-backend-guidelines)
4. Alibaba Code Guidelines & Business Logic
5. Database & SQL Performance (mybatis-sql-standard)
6. Error Handling (error-code-standard)
📝 Output Format Requirement
At the end of your task, append a short checklist summary. Example:
✅ CR Checklist Report:
- Evaluated code against checkstyle, error codes, and API standards.
- Self-correction: Found a wildcard import (
import java.util.*;) and replaced it with explicit imports.
- All checks passed.
Review Workflow (Merged)
Requesting Review (Merged from requesting-code-review)
Use a review request to catch issues early and create an evidence-backed handoff.
- Evidence first, then review
- Run this checklist yourself before requesting review
- Share a review packet:
- What changed (1–3 bullets)
- Scope boundary (in-scope paths only)
- Verification evidence (commands/tests run + outcome)
- Remaining risks / known gaps
Receiving Feedback (Merged from receiving-code-review)
Treat feedback as technical input to verify, not an order to blindly implement.
Response pattern:
- Read the feedback end-to-end
- Restate the technical requirement (or ask clarifying questions)
- Verify against codebase reality
- Evaluate whether it is sound for this codebase
- Respond with technical acknowledgment or reasoned pushback
- Implement one item at a time and re-verify after each change
Red flags:
- Implementing before understanding
- Bundling multiple fixes without verification
- Accepting suggestions that conflict with repo workflow gates