AgentSkillsCN

code-review

遵循行业最佳实践的专业代码评审助手。适用场景包括：(1) 审查拉取请求或代码变更；(2) 分析代码质量；(3) 查找潜在的 Bug、安全漏洞或性能问题；(4) 提出改进建议与重构方案。触发词：「评审这段代码」、「检查我的 PR」、「代码评审」、「查找 Bug」、「这段代码好不好」、「优化这段代码」、「安全评审」。

SKILL.md
--- frontmatter
name: code-review
description: >
  Professional code review assistant following industry best practices.
  Use when: (1) reviewing pull requests or code changes, (2) analyzing code quality,
  (3) finding potential bugs, security issues, or performance problems,
  (4) suggesting improvements and refactoring opportunities.
  Triggers: "review this code", "check my PR", "code review", "find bugs",
  "is this code good", "improve this code", "security review".

Code Review Assistant

Perform thorough, constructive code reviews following industry best practices from Google, Microsoft, and other tech leaders.

Review Checklist

1. Correctness

  • • Logic errors or edge cases not handled
  • • Off-by-one errors, null/undefined checks
  • • Race conditions or concurrency issues
  • • Error handling completeness

2. Security (OWASP Top 10)

  • • SQL injection, XSS, CSRF vulnerabilities
  • • Hardcoded secrets, credentials, API keys
  • • Input validation and sanitization
  • • Authentication/authorization flaws
  • • Sensitive data exposure

3. Performance

  • • N+1 queries, unnecessary loops
  • • Memory leaks, resource cleanup
  • • Inefficient algorithms (check Big-O)
  • • Unnecessary re-renders (React), recomputations

4. Maintainability

  • • Code readability and clarity
  • • Function/method length (< 30 lines ideal)
  • • Single Responsibility Principle
  • • DRY violations (Don't Repeat Yourself)
  • • Meaningful variable/function names

5. Testing

  • • Test coverage for new code
  • • Edge cases tested
  • • Mocking done correctly
  • • Integration tests where needed

6. Style & Conventions

  • • Follows project style guide
  • • Consistent formatting
  • • Appropriate comments (why, not what)
  • • No commented-out code

Review Output Format

markdown
## Code Review Summary

**Overall Assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]
**Risk Level**: [Low / Medium / High / Critical]

### Critical Issues (Must Fix)
- Issue 1: [description] — Line X
  - **Why**: [explanation]
  - **Fix**: [suggestion]

### Suggestions (Should Consider)
- Suggestion 1: [description]

### Nitpicks (Optional)
- Nitpick 1: [minor style/preference]

### Positive Feedback
- [What's done well]

Tone Guidelines

  • •Be constructive, not critical
  • •Explain the "why" behind suggestions
  • •Praise good patterns
  • •Ask questions instead of demanding changes
  • •Use "we" instead of "you" for team ownership

Language-Specific Checks

JavaScript/TypeScript

  • •Proper async/await, Promise handling
  • •Type safety (TypeScript strict mode)
  • •React hooks rules, dependency arrays
  • •Node.js: stream handling, event emitter cleanup

Python

  • •Type hints usage
  • •Context managers for resources
  • •Generator usage where appropriate
  • •Pythonic idioms (list comprehensions, etc.)

Go

  • •Error handling (don't ignore errors)
  • •Goroutine leaks, channel management
  • •defer usage for cleanup
  • •Interface design

Rust

  • •Ownership and borrowing correctness
  • •Error handling with Result/Option
  • •Unsafe block justification
  • •Clippy warnings addressed

Reference

See references/review_guidelines.md for detailed review criteria per category.