with one click
review-pr
// Review a PR on s3utils (S3 utility scripts for Scality S3C/Artesca operations)
// Review a PR on s3utils (S3 utility scripts for Scality S3C/Artesca operations)
| name | review-pr |
| description | Review a PR on s3utils (S3 utility scripts for Scality S3C/Artesca operations) |
| argument-hint | <pr-number-or-url> |
| disable-model-invocation | true |
| allowed-tools | Bash(gh repo view *), Bash(gh pr view *), Bash(gh pr diff *), Bash(gh pr comment *), Bash(gh api *), Bash(git diff *), Bash(git log *), Bash(git show *) |
You are an expert code reviewer. Review this PR:
Parse the argument to extract the repo and PR number:
REPO: and PR_NUMBER: (CI mode), use those values directly.https://github.com/), extract owner/repo and the PR number from it.gh repo view --json nameWithOwner -q .nameWithOwner.REPO: and PR_NUMBER:): post inline comments and summary to GitHub.gh pr view <number> --repo <owner/repo> --json title,body,headRefOid,author,files
gh pr diff <number> --repo <owner/repo>
Read changed files to understand the full context around each change (not just the diff hunks).
Analyze the changes against these criteria:
| Area | What to check |
|---|---|
| Async error handling | Uncaught promise rejections, missing error callbacks, swallowed errors in streams, missing .on('error') handlers |
| Stream handling | Backpressure issues, proper cleanup on error, no leaked file descriptors, correct use of transform/pipeline |
| Dependency pinning | Git-based deps (arsenal, vaultclient, bucketclient, werelogs, httpagent) must pin to a tag, not a branch |
| Logging | Proper use of werelogs ā no console.log in production code, log levels match severity |
| Async/await usage | Prefer async/await over raw promise chains (.then/.catch) and callbacks for new code; ensure await is not missing on async calls |
| Import placement | All require() statements must be at the top of the file, never inside functions, blocks, or describe scopes |
| Config & env vars | Backward compatibility of environment variables, sensible defaults, documented new variables |
| Production safety | Dry-run support preserved, resumption markers (KEY_MARKER, VERSION_ID_MARKER) handled correctly, batch limits respected |
| Security | No credentials or secrets in code, safe handling of user-supplied input, OWASP-relevant issues |
| Breaking changes | Changes to script CLI arguments, environment variable contracts, or client interfaces |
| Test coverage | New logic should have corresponding unit tests, mocks should be realistic |
For each specific issue, post a comment on the exact file and line:
gh api -X POST -H "Accept: application/vnd.github+json" "repos/<owner/repo>/pulls/<number>/comments" -f body="Your comment<br><br>ā Claude Code" -f path="path/to/file" -F line=<line_number> -f side="RIGHT" -f commit_id="<headRefOid>"
The command must stay on a single bash line. Never use newlines in bash commands ā use <br> for line breaks in comment bodies. Never put <br> inside code blocks or suggestion blocks ā use \n within $'...' quoting only for content inside fenced code blocks.
Each inline comment must:
```suggestion
corrected-line-here
```
Only suggest when you can show the exact replacement. For architectural or design issues, just describe the problem.
Example with a suggestion block:
gh api ... -f body=$'Missing the shared-guidelines update command.<br><br>```suggestion\n/plugin update shared-guidelines@scality-agent-hub\n/plugin update scality-skills@scality-agent-hub\n```<br><br>ā Claude Code' ...
$'...' as \' (e.g., don\'t)ā Claude CodeUse the line number from the new version of the file (the line number you'd see after the PR is merged), which corresponds to the line parameter in the GitHub API.
gh pr comment <number> --repo <owner/repo> --body "LGTM<br><br>Review by Claude Code"
The command must stay on a single bash line. Never use newlines in bash commands ā use <br> for line breaks in comment bodies. Never put <br> inside code blocks or suggestion blocks.
Do not describe or summarize the PR. For each issue, state the problem on one line, then list one or more suggestions below it:
- <issue>
- <suggestion>
- <suggestion>
If no issues: just say "LGTM". End with: Review by Claude Code
Do NOT post anything to GitHub. Instead, output the review directly as text.
For each issue found, output:
**<file_path>:<line_number>** ā <what's wrong and how to fix it>
When the fix is a concrete line change, include a fenced code block showing the suggested replacement.
At the end, output a summary section listing all issues. If no issues: just say "LGTM".
End with: Review by Claude Code