| name | review-pr |
| description | Review a pull request for conceptual fit, architecture impact, adversarial failure modes, security risk, docs impact, regression risk, test coverage, and merge readiness. Use when asked to review a PR, check whether a PR is safe to merge, decide if more tests are needed, perform adversarial or security review, or summarize PR risk. |
| disable-model-invocation | false |
| argument-hint | <PR number or URL> |
| allowed-tools | Bash |
Review PR
Review the PR from the user's point of view: make the decision easy, then provide detail only when it changes the decision.
Workflow
- Inspect PR metadata, files, diff, and checks.
- Read the touched code and nearby architecture boundaries.
- Identify whether the change is a behavior change, performance change, refactor, test-only change, docs-only change, or CI/infrastructure change.
- Run the required review passes:
- architecture fit: does the change match existing module boundaries and project patterns;
- adversarial review: what breaks under edge cases, bad inputs, scale, concurrency, cancellation, cache misses, offline mode, or hosted runner differences;
- security review: secrets, tokens, path traversal, unsafe downloads, sandbox escapes, user-controlled file paths, network exposure, dependency risk, and data leakage;
- docs review: local docs, public site docs, README translations, CLI help, model tables, benchmark pages, and migration notes when behavior is user-visible.
- Assess regression risk from the changed behavior and blast radius.
- Decide whether existing tests are enough. Include E2E coverage for runtime/model/user-facing behavior, or explicitly state why E2E is not applicable. Add or request tests only when they protect a real risk.
- Run the smallest meaningful validation:
- unit tests for logic and data structures;
- focused E2E for model/runtime behavior;
- CLI probe or benchmark only when the PR changes user-facing runtime behavior or performance.
- End with a short merge recommendation.
Output Shape
Start with this format unless the user asks for a detailed code review:
Status: ready / not ready / needs follow-up
What changed:
...
Architecture fit:
...
Adversarial/security/docs:
Adversarial: ...
Security: ...
Docs: ...
Regression risk:
Low / medium / high, with one-sentence reason.
Tests:
Unit: ...
E2E: ...
Needed: ...
Recommendation:
Merge / request changes / investigate first.
Review Rules
- Lead with blockers if any exist.
- Keep conceptual summary above command details.
- Do not paste logs unless asked.
- Be adversarial about failure modes, but do not invent blockers without evidence.
- Treat security and docs as explicit review passes, even when the conclusion is "no impact."
- Always report E2E tests run. If none were run, state the reason and whether that is acceptable.
- Do not add slow permanent E2E tests just to prove a local probe; add permanent tests when they guard realistic future regressions.
- Prefer same-input comparison against
main for performance or refactor PRs when output preservation matters.
- Treat model download, cache, and hosted runner failures as infrastructure unless code behavior caused them.
- For public API, CLI flags, model variants, or docs-visible behavior, call out required docs updates.
- For README changes, verify all translated README files are updated.
