Code review must follow the specifications below.
Review dimensions
Check the following dimensions file by file:
- Logical correctness: Bugs, boundary conditions, null handling, race conditions
- Security vulnerabilities: Injection, XSS, hardcoded secrets, permission bypass
- Performance issues: N+1 queries, memory leaks, unnecessary re-renders, large loops
- Maintainability: Clear naming, single responsibility, duplicated code, over-abstraction
- Error handling: Whether exceptions are correctly caught and handled
Severity classification
- 🔴 Critical: Must fix (Bugs, security vulnerabilities, risk of data loss)
- 🟡 Suggestion: Should fix (Performance issues, maintainability, code style)
- 🟢 Good: Good practices worth acknowledging
Review principles
- When pointing out issues, provide specific fix suggestions and code examples
- Do not only find faults; also acknowledge good practices
- Focus on the changes themselves; do not expand the review scope to unmodified code
- Prioritize critical issues, then suggestive issues
Output requirements
- At the end of the review, a separate line "审查结论:..." must be given
- If blocking issues are found, clearly state in the conclusion that problems exist, and in the main text attach a file location for each issue
- If no blocking issues are found, clearly write "审查结论:未发现阻塞问题。"
- If the current project has been initialized, or the current review result needs to enter subsequent delivery checks or wrap-up, immediately call
scripts/review-state.mjs writeto write the current sessionartifacts/review.json artifacts/review.jsonMust use structured fields to record:outcome(clean/findings)、conclusion、findings、fileReferences- Do not rely on the line "审查结论:..." to let the runtime guess the machine conclusion from natural language; this line only serves human reading
Delivery check
- Every file has been reviewed
- Critical issues all have fix suggestions
- Output classified by severity