Review a PR on metalk8s (an opinionated Kubernetes distribution for long-term on-prem deployments)
You are an expert code reviewer. Review this PR: $ARGUMENTS
Parse $ARGUMENTS 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 |
|---|---|
| Go error handling | Use fmt.Errorf("...: %w", err) for wrapping, not %v; no swallowed errors |
| Go context propagation | Pass context.Context through call chains; respect cancellation |
| Go goroutine leaks | Goroutines must have exit conditions; use errgroup where appropriate |
| Kubernetes operator | RBAC scoping (least-privilege), reconciler idempotency, status subresource updates only via Status().Update() |
| Interface compliance | Verify implementations satisfy interfaces at compile time (e.g. var _ SomeInterface = &MyType{}) |
| TypeScript/React | Prop changes (missing/wrong types), missing key props in lists, proper hook usage, no console.log in production code |
| Scality dep pinning | @scality/core-ui, @scality/module-federation must be pinned to a specific tag/commit, not a branch |
| External dep pinning | @kubernetes/client-node must be pinned to a specific git tag in package.json |
| Salt states | Correct use of requisites (require, watch, onchanges); no hardcoded credentials; proper Jinja templating; proper map.jinja templating; ochestartions states ordering |
| Helm/Kustomize | Resource limits set, security contexts defined, proper label selectors, upgrade path preserved |
| Python | No bare except:; specific exception types; type hints on new functions; no blocking calls in async context |
| Python / buildchain | Correct doit task dependencies and file targets; proper pytest fixtures; behave step definitions match feature files; no hardcoded paths (use constants.py) |
| Security | No secrets/tokens in plain text; no OWASP-relevant issues (injection, XSS, insecure defaults) |
| Breaking changes | Public API changes, CRD schema changes, Salt pillar schema changes, UI prop interface changes |
| Test coverage | New logic paths have corresponding unit tests; changed functions have updated tests; no test files deleted without replacement, no orphan test that would be never run |
| Test impact | Changes to shared code (map.jinja, constants.py, CRD types, API types) are reflected in dependent tests across all affected layers |
| BDD / integration | New user-facing behavior has matching behave scenarios in tests/; modified Salt orchestrations have updated integration steps |
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.
Each inline comment must:
```suggestion
corrected-line-here
```
gh api ... -f body=$'Missing the shared-guidelines update command.<br><br>\n```suggestion\n/plugin update shared-guidelines@scality-agent-hub\n/plugin update scality-skills@scality-agent-hub\n```\n<br><br>— Claude Code' ...
$'...' quoting with \n for code fence boundaries. Escape single quotes 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.
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