Review Ruby Performance

Review the actual changed code before making recommendations. Prefer diff-first review against the default branch when the request is about a branch or PR.

Focus on findings, not generic advice. For each finding, cite file and line, explain the performance impact, and give concrete improvement options.

When checking Ruby core APIs or standard-library behavior, verify them instead of relying on memory alone. Use Dash MCP lookups against the installed Ruby docset first, then Context7 if needed, and only then official API docs or primary sources. Prioritize verifying Enumerable, Enumerator::Lazy, Set, Hash, Array, and Data.define semantics when they materially affect the recommendation.

Review Workflow

1. Establish scope.

• Identify the target diff or files under review.
• Distinguish committed branch changes from unrelated local edits.
• Read the relevant code before forming conclusions. Gather enough local context to understand call sites, surrounding helpers, data flow, and whether the path is plausibly hot.
• If the user asked for a review, do not start editing unless they explicitly ask for fixes.

2. Find hot paths and repeated work.