---
name: review-ruby
user-invokable: true
argument-hint: "[file paths, directory paths, branch name, or focus area]"
description: This skill should be used when the user asks to "review ruby code", "audit ruby codebase", "find over-engineering in ruby", "simplify ruby classes", "review lib/", or wants to analyze Ruby code (libraries, gems, CLI tools) for unnecessary abstractions with actionable refactoring steps.
---

# Ruby Code Review & Refactoring Guide

Analyze Ruby code for unnecessary custom objects, class bloat, and insufficient usage of Ruby's generic data structures. Provide specific refactoring steps with before/after code examples for libraries, gems, CLI tools, and Ruby applications.

## Scope Determination

Determine scope from the user's request:

- **File paths** (e.g., `lib/parser.rb`): analyze only those files
- **Directory paths** (e.g., `lib/services/`): analyze all Ruby files in that directory
- **Branch name**: compare current branch against it to review only changed files
- **No scope specified**: perform full codebase audit of `lib/` directory
- **Focus area** (e.g., "command objects", "data structures"): prioritize that aspect

## Required Skill

**MANDATORY: Load the `simplifying-ruby-code` skill** and apply its principles throughout the analysis. Reference specific patterns explicitly (e.g., "Pattern 1: Command Objects -> Module Functions").

## Anti-Patterns to Scan

### Unnecessary Class Hierarchies
- Deep inheritance trees (>2 levels) for simple behavior
- Abstract base classes with single implementations
- Classes that could be modules or simple functions
- Template method pattern where blocks would suffice

### Over-Engineered Data Objects
- Custom classes for simple data pairs (coordinates, ranges, tuples)
- Value objects without behavior, validation, or transformation
- Missing Ruby protocol implementations (`each`, `to_h`, `to_a`, `to_json`, `to_s`)
- Data objects that should be Struct, Data, or Hash

### Stateful Objects Where Functions Would Work
- Classes with only class methods (should be modules)
- Single-method classes (`call`, `run`, `execute`, `perform`)
- Builder patterns for simple object construction
- Stateful service objects that could be pure functions

### Complexity That Could Be Simplified
- Custom DSLs that reinvent Ruby syntax
- Wrapper classes around standard library
- Complex metaprogramming where simple code would work
- Unnecessary dependencies (pulling in gems for simple tasks)

## Output Format

For each issue found, provide:

1. **File and location** with line numbers
2. **Problem** — why it violates simplicity principles
3. **Before code** — current implementation
4. **After code** — refactored version
5. **Migration steps** — how to safely refactor
6. **Test considerations** — what tests need updating

Structure findings into: Critical Issues (fix first), Improvements (consider for refactoring), Good Patterns Found, and Summary with recommended refactoring order and estimated complexity.

## Best Practices

1. Prefer data over objects — use Hashes, Arrays, Structs, and Data for simple data
2. Prefer functions over classes — use modules with `module_function` for stateless operations
3. Implement Ruby protocols — make objects work with Ruby's built-in methods and Enumerable
4. Use blocks effectively — blocks are Ruby's lambdas; use them instead of callback objects
5. Keep inheritance shallow — prefer composition and modules over deep inheritance
6. Leverage standard library — Ruby's stdlib is rich; do not reinvent Array, Hash, Set, etc.