code-reviewer
Comprehensive code review for quality, architecture, and performance. Use when reviewing PRs, auditing code quality, checking coding standards, evaluating design patterns, identifying performance bottlenecks, or analyzing technical debt. Triggers on "review", "audit", "analyze code", "check quality", "code smell".
Works with
--- name: code-reviewer description: Comprehensive code review for quality, architecture, and performance. Use when reviewing PRs, auditing code quality, checking coding standards, evaluating design patterns, identifying performance bottlenecks, or analyzing technical debt. Triggers on "review", "audit", "analyze code", "check quality", "code smell". license: Apache-2.0 --- # Code Reviewer Perform thorough code reviews covering quality, architecture, and performance aspects. ## When to Use - Reviewing pull requests or code changes - Auditing codebase quality and maintainability - Evaluating architecture and design decisions - Identifying performance issues and bottlenecks - Checking adherence to coding standards - Finding code smells and technical debt ## Review Process ### 1. Understand Context Before reviewing, gather context: - What is the purpose of this code/change? - What are the project's conventions? (check CLAUDE.md, .eslintrc, etc.) - Are there existing patterns to follow? ### 2. Quality Review Check for: - **Readability**: Clear naming, appropriate comments, logical structure - **Maintainability**: Single responsibility, DRY principle, low coupling - **Error handling**: Proper try/catch, meaningful error messages - **Edge cases**: Null checks, boundary conditions, empty states - **Code smells**: Long methods, deep nesting, magic numbers ### 3. Architecture Review Evaluate: - **Design patterns**: Appropriate use, consistency with codebase - **Dependencies**: Minimal coupling, clear interfaces - **Modularity**: Components have clear boundaries and responsibilities - **Scalability**: Can this handle growth without major rewrites? - **Testability**: Is the code easy to unit test? ### 4. Performance Review Identify: - **Algorithmic efficiency**: Time/space complexity concerns - **Memory management**: Leaks, unnecessary allocations - **Render performance**: Unnecessary re-renders (React), DOM thrashing - **Network efficiency**: N+1 queries, missing caching, payload sizes - **Resource cleanup**: Event listeners, subscriptions, intervals ## Output Format Structure your review as: ```markdown ## Code Review: [File/Component Name] ### Summary [1-2 sentence overview of the review findings] ### Critical Issues [Must fix before merge - bugs, security issues, data loss risks] ### Recommendations [Should fix - quality, performance, maintainability improvements] ### Suggestions [Nice to have - style preferences, minor optimizations] ### Positive Highlights [Good patterns worth noting for team learning] ``` ## Severity Levels | Level | Description | Action | |-------|-------------|--------| | Critical | Bugs, security vulnerabilities, data corruption risk | Block merge | | High | Performance issues, maintainability problems | Should fix | | Medium | Code smells, minor inefficiencies | Recommend fix | | Low | Style preferences, nitpicks | Optional | ## Review Checklist See [CHECKLIST.md](CHECKLIST.md) for the complete review checklist. ## Examples See [EXAMPLES.md](EXAMPLES.md) for sample reviews demonstrating proper format and tone.
More Code Review skills
pr-to-video
heygen-com/hyperframes
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
receiving-code-review
obra/superpowers
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
public-relations
coreyhaines31/marketingskills
When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.

