review-pr

name	review-pr
description	Review a PR on file-reflector (a Go source-to-target filesystem sync agent)
argument-hint	<pr-number-or-url>
disable-model-invocation	true
allowed-tools	Read, 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 *)

Review GitHub PR

You are an expert code reviewer. Review this PR: $ARGUMENTS

Determine PR target

Parse $ARGUMENTS to extract the repo and PR number:

• If arguments contain REPO: and PR_NUMBER: (CI mode), use those values directly.
• If the argument is a GitHub URL (starts with https://github.com/), extract owner/repo and the PR number from it.
• If the argument is just a number, use the current repo from gh repo view --json nameWithOwner -q .nameWithOwner.

Output mode

• CI mode (arguments contain REPO: and PR_NUMBER:): post inline comments and summary to GitHub.
• Local mode (all other cases): output the review as text directly. Do NOT post anything to GitHub.

Steps

1. Fetch PR details:

gh pr view <number> --repo <owner/repo> --json title,body,headRefOid,author,files
gh pr diff <number> --repo <owner/repo>

2. Read changed files to understand the full context around each change (not just the diff hunks).

3. Analyze the changes against these criteria:

Area	What to check
Error handling	Failures wrap a package-level Err… sentinel via github.com/scality/go-errors — errors.Wrap(ErrX, errors.WithDetail(...), errors.WithProperty(...), errors.CausedBy(rawErr)) — not fmt.Errorf/%w; the sentinel is the category so errors.Is keeps matching through the chain. go-errors is imported unaliased as errors.
Clean-architecture layering	Dependency rule cmd → infrastructure → usecase → service → domain. domain imports nothing; usecase depends only on service ports; filesystem/OS code lives only in infrastructure adapters; a new capability the use cases consume is a small service port, not a concrete type.
Logging	log/slog only; use the *Context methods (InfoContext, ErrorContext, …) wherever a context.Context is in scope; structured key/value attrs, never fmt-style logging.
Context & goroutines	context.Context is threaded through call chains and cancellation is respected. The watcher's goroutines (event fan-in, retry scheduling) must have an exit condition tied to ctx or channel close — no leaks.
Sync invariants	Don't break the core guarantees: content is compared by full SHA-256 when sizes match (no size+mtime shortcut — it would defeat self-healing against tampering); writes are atomic (temp file → chmod/chown → rename); source symlinks are skipped; an ignored path is never created, modified, nor deleted; the single-writer-per-target assumption holds.
Filesystem safety & capabilities	Filesystem access stays scoped to the os.Root; no path traversal out of source/target. Changes to the capability set (CAP_DAC_OVERRIDE/CAP_FOWNER/CAP_CHOWN) or the rootless securityContext must be intentional. No credentials, tokens, or secrets in code, logs, or config.
Tests	Tests are Ginkgo + Gomega. Mocks for service ports are generated by mockery (go generate ./...) and committed — never hand-edited. New behaviour and error paths are covered.
Breaking changes	Flag changes to CLI flags, exit codes, log format, the image/capabilities, or any exported interface.
Docs	Behaviour/flag/output changes update README.md; architecture or design-decision changes update DESIGN.md; convention/workflow changes update CONTRIBUTING.md (per CONTRIBUTING's "keep the docs in sync" rule).

4. Deliver your review:

If CI mode: post to GitHub

Part A: Inline file comments

For each issue, post a comment on the exact file and line. Keep comments short (1-3 sentences), end with — Claude Code. Use line numbers from the new version of the file.

Without suggestion block — single-line command, <br> for line breaks:

gh api -X POST -H "Accept: application/vnd.github+json" "repos/<owner/repo>/pulls/<number>/comments" -f body="Issue description.<br><br>— Claude Code" -f path="file" -F line=42 -f side="RIGHT" -f commit_id="<headRefOid>"

With suggestion block — use a heredoc (-F body=@-) so code renders correctly:

gh api -X POST -H "Accept: application/vnd.github+json" "repos/<owner/repo>/pulls/<number>/comments" -F body=@- -f path="file" -F line=42 -f side="RIGHT" -f commit_id="<headRefOid>" <<'COMMENT_BODY'
Issue description.

```suggestion
first line of suggested code
second line of suggested code

— Claude Code COMMENT_BODY

Only suggest when you can show the exact replacement. For architectural or design issues, just describe the problem.

#### Part B: Summary comment

Single-line command, `<br>` for line breaks. No markdown headings — they render as giant bold text. Flat bullet list only:

```bash
gh pr comment <number> --repo <owner/repo> --body "- file:line — issue<br>- file:line — issue<br><br>Review by Claude Code"

If no issues: just say "LGTM". End with: Review by Claude Code

If local mode: output the review as text

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

What NOT to do

• Do not comment on markdown formatting preferences
• Do not suggest refactors unrelated to the PR's purpose
• Do not praise code — only flag problems or stay silent
• If no issues are found, post only a summary saying "LGTM"
• Do not flag style issues already covered by the project's linter (golangci-lint)