name: code-review-excellence description: | Provides comprehensive code review guidance for React 19, Vue 3, Rust, TypeScript, Java, Python, and C/C++. Helps catch bugs, improve code quality, and give constructive feedback. Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes, establishing review standards, mentoring developers, architecture reviews, security audits, checking code quality, finding bugs, giving feedback on code. allowed-tools: - Read - Grep - Glob - Bash # 執行 lint/test/build 命令驗證程式碼質量 - WebFetch # 查閱最新文件和最佳實踐

Code Review Excellence

Transform code reviews from gatekeeping to knowledge sharing through constructive feedback, systematic analysis, and collaborative improvement.

When to Use This Skill

• Reviewing pull requests and code changes
• Establishing code review standards for teams
• Mentoring junior developers through reviews
• Conducting architecture reviews
• Creating review checklists and guidelines
• Improving team collaboration
• Reducing code review cycle time
• Maintaining code quality standards

Core Principles

1. The Review Mindset

Goals of Code Review: - Catch bugs and edge cases - Ensure code maintainability - Share knowledge across team - Enforce coding standards - Improve design and architecture - Build team culture

Not the Goals: - Show off knowledge - Nitpick formatting (use linters) - Block progress unnecessarily - Rewrite to your preference

2. Effective Feedback

Good Feedback is: - Specific and actionable - Educational, not judgmental - Focused on the code, not the person - Balanced (praise good work too) - Prioritized (critical vs nice-to-have)

❌ Bad: "This is wrong."
✅ Good: "This could cause a race condition when multiple users
         access simultaneously. Consider using a mutex here."

❌ Bad: "Why didn't you use X pattern?"
✅ Good: "Have you considered the Repository pattern? It would
         make this easier to test. Here's an example: [link]"

❌ Bad: "Rename this variable."
✅ Good: "[nit] Consider `userCount` instead of `uc` for
         clarity. Not blocking if you prefer to keep it."

3. Review Scope

What to Review: - Logic correctness and edge cases - Security vulnerabilities - Performance implications - Test coverage and quality - Error handling - Documentation and comments - API design and naming - Architectural fit

What Not to Review Manually: - Code formatting (use Prettier, Black, etc.) - Import organization - Linting violations - Simple typos

Review Process

Phase 1: Context Gathering (2-3 minutes)

Before diving into code, understand: 1. Read PR description and linked issue 2. Check PR size (>400 lines? Ask to split) 3. Review CI/CD status (tests passing?) 4. Understand the business requirement 5. Note any relevant architectural decisions

Phase 2: High-Level Review (5-10 minutes)

1. Architecture & Design - Does the solution fit the problem?
2. For significant changes, consult Architecture Review Guide
3. Check: SOLID principles, coupling/cohesion, anti-patterns
4. Performance Assessment - Are there performance concerns?
5. For performance-critical code, consult Performance Review Guide
6. Check: Algorithm complexity, N+1 queries, memory usage
7. File Organization - Are new files in the right places?
8. Testing Strategy - Are there tests covering edge cases?

Phase 3: Line-by-Line Review (10-20 minutes)

更多技能請訪問小蔥技能站7w4.net。

For each file, check: - Logic & Correctness - Edge cases, off-by-one, null checks, race conditions - Security - Input validation, injection risks, XSS, sensitive data - Performance - N+1 queries, unnecessary loops, memory leaks - Maintainability - Clear names, single responsibility, comments

Phase 4: Summary & Decision (2-3 minutes)

1. Summarize key concerns
2. Highlight what you liked
3. Make clear decision:
4. ✅ Approve
5. 💬 Comment (minor suggestions)
6. 🔄 Request Changes (must address)
7. Offer to pair if complex

Review Techniques

Technique 1: The Checklist Method

Use checklists for consistent reviews. See Security Review Guide for comprehensive security checklist.

Technique 2: The Question Approach

Instead of stating problems, ask questions:

❌ "This will fail if the list is empty."
✅ "What happens if `items` is an empty array?"

❌ "You need error handling here."
✅ "How should this behave if the API call fails?"

Technique 3: Suggest, Don't Command

Use collaborative language:

❌ "You must change this to use async/await"
✅ "Suggestion: async/await might make this more readable. What do you think?"

❌ "Extract this into a function"
✅ "This logic appears in 3 places. Would it make sense to extract it?"

Technique 4: Differentiate Severity

Use labels to indicate priority:

• 🔴 [blocking] - Must fix before merge
• 🟡 [important] - Should fix, discuss if disagree
• 🟢 [nit] - Nice to have, not blocking
• 💡 [suggestion] - Alternative approach to consider
• 📚 [learning] - Educational comment, no action needed
• 🎉 [praise] - Good work, keep it up!

Language-Specific Guides

根據審查的程式碼語言，查閱對應的詳細指南：

Additional Resources

• Architecture Review Guide - 架構設計審查指南（SOLID、反模式、耦合度）
• Performance Review Guide - 效能審查指南（Web Vitals、N+1、複雜度）
• Common Bugs Checklist - 按語言分類的常見錯誤清單
• Security Review Guide - 安全審查指南
• Code Review Best Practices - 程式碼審查最佳實踐
• PR Review Template - PR 審查評論模板
• Review Checklist - 快速參考清單

這個 Skill 質量不錯，內容豐富實用，涵蓋多種程式語言的程式碼審查指南和現成模板，團隊拿來就能用。但它更像一本電子手冊，使用者需要自己翻閱查詢內容，缺乏智慧引導，不夠“貼心”。