ror-pr-review

name	ror-pr-review
description	Review a ReadonlyREST pull request with the depth of a senior Scala/Elasticsearch reviewer — not a rubber-stamp. Use when invoked as an automated PR reviewer, when the user asks for a PR review on this repo, or whenever the task is "review PR

ReadonlyREST PR Review

The goal is the level of insight a careful senior Scala/Elasticsearch reviewer would produce — not a rubber-stamp "No issues found."

Mandatory methodology

1. Read CLAUDE.md first. Then read the PR description and any prior review comments — they often contain context, previous findings, and the contributor's responses you must not duplicate or contradict without reason.
2. Pull the full diff and full context. Use gh pr diff <num> for the diff; gh pr view <num> --json title,body,commits,reviews for metadata; gh api repos/.../issues/<num>/comments for prior discussion. Do not rely on a truncated diff — if the diff is large, process it in chunks but cover every file.
3. Read the modified files in full (not just the hunks). Bugs usually live in the lines around the diff, not inside it. Use Read on each changed file before commenting on it.
4. Cross-reference call sites. When a function/type is touched, grep -rn for every caller and assess whether the change is safe for each. A behavioral change that compiles is not necessarily a behavioral change that's correct. The Scala compiler's variance and implicit-resolution machinery hides a lot of subtle behavior — always verify the runtime semantics.
5. Check the tests. For every behavioral change, ask: does a test cover this? If a test claims to cover it, does the test actually verify the new behavior, or does it pass for an incidental reason (false-confidence test)? Property-based tests with overly-narrow generators are a common variant.
6. Use and for any failing job. A failing integration test on a single ES module is often a hint that the code change broke a real flow on that ES version.