// Review Vortex pull requests for correctness, Rust soundness, performance, API compatibility, and test coverage. Use when reviewing PRs, reviewing code changes, or when the user mentions "/pr-review".
| name | pr-review |
| description | Review Vortex pull requests for correctness, Rust soundness, performance, API compatibility, and test coverage. Use when reviewing PRs, reviewing code changes, or when the user mentions "/pr-review". |
Review Vortex changes for issues that CI may miss: semantic correctness, Rust soundness, zero-copy and alignment invariants, performance, API compatibility, and missing regression coverage.
When invoked by a PR automation, the prompt may already include PR metadata, issue body, comments, and changed files. In this mode, use git commands for the diff and history:
git diff origin/<base-branch>...HEAD
git diff --stat origin/<base-branch>...HEAD
git log origin/<base-branch>..HEAD --oneline
If the base ref is missing, fetch only that ref:
git fetch origin <base-branch> --depth=1
Do not refetch data already provided in the prompt. Use the supplied comments and metadata as review context.
When the user provides a PR number or URL, use gh to fetch the PR metadata, comments, and diff:
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits
gh pr view <PR_NUMBER> --json comments,reviews
gh pr diff <PR_NUMBER>
If gh cannot connect to api.github.com because of sandbox networking, rerun with escalated
network permissions.
AGENTS.md and any nested AGENTS.md for project conventions.ls, find, git status, or relevant config linters.| Area | Focus |
|---|---|
| Correctness | Length and dtype invariants, nullability, validity masks, offset math, canonicalization, boundary conditions, empty arrays, scalar vs array behavior |
| Rust soundness | unsafe blocks, aliasing, lifetimes, alignment, FFI boundaries, panic safety, ownership of buffers and arrays |
| Compression and IO | Encoding metadata, statistics, layout evolution, file compatibility, scan projection/filter behavior, async IO edge cases |
| Performance | Unnecessary copies, lost zero-copy behavior, avoidable allocations, poor cache locality, quadratic loops, excessive dynamic dispatch in hot paths |
| Error handling | Correct vortex_err! and vortex_bail! usage, useful messages, no accidental panics on user data |
| API compatibility | Public API docs, feature flags, crate boundaries, Python/Java binding impacts |
| Tests | Regression coverage, edge cases, parameterized cases with rstest, use of assert_arrays_eq!, docs doctests when docs change |
| Verification scope | Avoid requesting or running expensive workspace checks when the PR only changes docs, agent files, symlinks, or metadata |
Lead with findings, ordered by severity. For each finding include:
Use inline review comments when the environment supports them and a precise changed line is the best place for the feedback. Keep broad design feedback in the summary.
If no issues are found, say so explicitly and mention any residual risk or tests not run.
Iterate on Vortex vx-bench query performance with benchmark comparisons, engine-specific benchmark flags, RUST_LOG/tracing/metrics/explain output, and Samply profiles. Use when optimizing or investigating a vx-bench query, benchmark regression, engine/format comparison, or Vortex benchmark hotspot.
Analyze Samply Firefox-profiler output, record focused profiles, summarize hot threads/stacks, inspect symbolication, and compare profile evidence before and after a performance change.
Analyze Vortex GitHub Actions CI failures. Use when asked to investigate failed CI runs, failed jobs, or when the user mentions "/ci-failure-analysis".
Answer questions about the Vortex codebase or pull requests. Use when asked a question via "/query" or when the user wants to understand code, architecture, behavior, or implementation details.