home / skills / phodal / auto-dev / code-review

code-review skill

/examples/skills/code-review

This skill performs comprehensive Kotlin code reviews, applying best practices, design patterns, and security checks to improve quality and maintainability.

npx playbooks add skill phodal/auto-dev --skill code-review

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
732 B
---
name: code-review
description: Perform comprehensive code review with best practices
---

# Code Review

You are an experienced software engineer performing a code review.

## Review Request

$ARGUMENTS

## Review Criteria

1. **Code Quality**: Readability, maintainability, complexity
2. **Best Practices**: Design patterns, SOLID principles, DRY
3. **Performance**: Efficiency, resource usage, scalability
4. **Security**: Input validation, auth, data protection
5. **Testing**: Test coverage, edge cases

## Output Format

For each issue:
- Severity: Critical/High/Medium/Low
- Category: Quality/Performance/Security/Testing
- Location: File and line
- Issue: Description
- Recommendation: How to fix

Project: $PROJECT_NAME

Overview

This skill performs comprehensive code reviews focused on Kotlin and multiplatform projects. It evaluates readability, maintainability, performance, security, and test coverage, then returns prioritized, actionable findings. Reviews use standard software engineering criteria and produce clear recommendations tied to file locations.

How this skill works

Provide the repository context and target files or diffs to review. The skill analyzes code for quality, best practices (SOLID, DRY), performance issues, security vulnerabilities, and test completeness, then maps each issue to severity, category, location, a concise problem statement, and a practical fix. Results are prioritized so teams can act on critical blockers first.

When to use it

  • Before merging a pull request to catch regressions and design issues
  • During architecture or refactor proposals to validate patterns and trade-offs
  • In CI pipelines to enforce quality gates and prevent security regressions
  • When adding features to ensure performance and test coverage remain adequate
  • During release preparation to identify high-risk defects and edge-case gaps

Best practices

  • Target small, focused reviews to reduce context switching and increase accuracy
  • Include file paths and line ranges in the request for precise, actionable feedback
  • Request both high-level design feedback and low-level implementation fixes
  • Prioritize fixes by severity and provide reproduction steps for security issues
  • Add unit and integration test suggestions for each uncovered edge case

Example use cases

  • Review a Kotlin Multiplatform feature branch for API design, concurrency, and platform-specific pitfalls
  • Audit authentication and data handling code for injection, serialization, and privacy issues
  • Assess a refactor for SOLID compliance and identify places to reduce coupling
  • Evaluate performance hotspots like unnecessary allocations, blocking IO, and inefficient collections
  • Verify test suite covers boundary conditions, error paths, and platform variations

FAQ

What input do you need to run a review?

Provide the project name, relevant files or diff, and any focus areas (security, performance, tests). Include line ranges for targeted feedback.

How are severities determined?

Severities map to impact and likelihood: Critical blocks functionality or leaks sensitive data; High causes major defects or performance problems; Medium affects maintainability; Low is stylistic or minor improvement.