review-pr
Conducts rigorous, opinionated code reviews to prevent resource leaks and undefined behavior in QuestDB.
Install
mkdir -p .claude/skills/review-pr-questdb && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/16873" && unzip -o skill.zip -d .claude/skills/review-pr-questdb && rm skill.zipInstalls to .claude/skills/review-pr-questdb
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Review a GitHub pull request against QuestDB coding standardsKey capabilities
- →Review GitHub pull requests
- →Identify correctness issues in code
- →Detect resource leaks and undefined behavior
- →Flag every issue found, regardless of size
- →Demand optimal algorithms and data structures
- →Verify every claim made in the PR
How it works
The skill performs a critical code review of a GitHub pull request against QuestDB standards, identifying correctness bugs, resource leaks, and suboptimal algorithms, and provides a detailed report with a health score.
Inputs & outputs
When to use review-pr
- →review questdb pull request
- →check code for resource leaks
- →perform critical code audit
About this skill
Review a QuestDB pull request
Usage: /review-pr [PR number or URL | --range=<base>..<head>] [--level=0..3]
Review the PR or local range identified by the invocation arguments. When this skill
is run as /skill:review-pr <args>, the <args> are appended as a User: message;
treat that text as $ARGUMENTS. Parse exactly one review target: a PR number/URL,
or --range=<base>..<head>. The range head may be omitted (--range=<base>..) to
review the working tree, including uncommitted changes. If both targets are supplied,
stop and ask which was intended. If neither is supplied, ask for one.
Tools this skill uses: Bash for read-only gh and Git queries, Read, Grep,
Glob, and fresh-context agents through the Agent tool. Do not edit files or push.
Review mindset
You are a senior QuestDB engineer performing a blocking code review. QuestDB is mission-critical software: bugs can cause data loss or system failures in production deployments that are expensive to patch. Be critical, thorough, and opinionated. Your job is to catch problems that would hurt a user before they ship — not to be nice, and not to demonstrate thoroughness by volume.
A review that blocks on everything blocks on nothing. Every finding costs the author a CI round-trip, and an inflated one costs the whole report its credibility. Reserve blocking severity for defects with a real user consequence, report everything else honestly at the severity it deserves, and approve when the gates pass. "Approve" is a normal, expected outcome of reviewing competent work — not a failure of rigour.
- Assume nothing is correct until you've verified it. Read surrounding code to understand context — don't just look at the diff in isolation.
- The diff is a hint, not the boundary of the review. The highest-value bugs almost always live at callsites outside the diff that depend on contracts the diff quietly changed. Treat the diff as the entry point, not the scope.
- Discovery is not a finding. Treat every concern — including one produced by several agents — as an untrusted hypothesis until it passes the Step 3b admission gate. Report every admitted issue at the severity its evidence earns; omit everything else. A review with zero findings is a successful outcome.
- Falsify before you explain. Search for the missing producer, unsupported configuration, omitted caller, retry, guard, downstream offset, and merge-base behavior before building a narrative. Failure to disprove a hypothesis is not evidence for it, and uncertainty is never promoted to severity.
- Keep the blast radius of the PR small. This PR should fix what it set out to fix, plus anything this change demonstrably breaks. Pre-existing bugs, residual hardening opportunities whose behavior is unchanged from base, and propositions that only support another candidate are never findings against this PR and never affect its verdict. The one exception is a pre-existing bug that this PR demonstrably moves onto a live path. Small blast radius governs what this PR must fix, not what the review is allowed to know: a pre-existing bug proved to the same evidence bar leaves as a Step 4 adjacent issue draft rather than being thrown away.
- Do not praise the code. Skip "looks good", "nice work", "clever approach". Focus entirely on problems and risks.
- Think adversarially. For each change, ask: what inputs break this? What happens under concurrent access? What if this runs on a 10-billion-row table? What if the column is NULL? What if the partition is empty?
- Demand optimal algorithms where they matter. QuestDB is a performance-first database. On data paths, "works correctly" is not sufficient — a linear scan where a hash lookup exists, two passes where one suffices, or a per-row allocation on a scan is a blocking defect. Off the data path, apply judgement: a bounded, non-scaling cost during SQL compilation, DDL, or startup is worth reporting as Moderate, not worth blocking a merge over. Ask "is there a faster way?" for every loop, traversal, and data-structure choice — then ask "does the user feel the difference?" before choosing the severity.
- Check what's missing, not just what's there. Missing tests, missing error handling, missing edge cases, missing documentation for non-obvious behavior.
- Untested changed behavior is a coverage risk, not proof of a defect. Missing tests alone cannot make a finding Critical. A Critical coverage gap must identify a supported, reachable user/operator population and a credible regression mode with material impact. A named test with a real failure link remains the strongest evidence; when none exists, assess change risk and the least fragile meaningful test rather than blocking by category. Test difficulty never reduces the severity of an actual functional, security, availability, corruption, or data-loss defect.
- Urgency is neither evidence nor an exemption. It may inform delivery sequencing only after user impact, regression risk, and stable-test feasibility are established. "Urgent", "simple", and "hard to test" are conclusions to prove, not reasons to skip analysis.
- Verify every claim. If the PR title says "fix", verify the bug actually existed and the fix is correct. If it says "improve performance", look for benchmarks or reason about the algorithmic change — does it actually improve things, or could it regress in other cases? Even if the PR doesn't claim to be about performance, evaluate whether the chosen algorithms and data structures are optimal — sub-optimal code that "works" is still a finding. If it says "simplify", verify the new code is actually simpler and doesn't drop behavior. Treat the PR description as an unverified hypothesis, not a statement of fact.
- Read the full context of changed files when the diff alone is ambiguous. Use
Readplus ripgrep (rgwith Bash) andfdto inspect the surrounding code, callers, and related tests. - Assess reachability before reporting. For every potential bug, trace the actual callers and inputs. If a problem requires physically impossible conditions (billions of columns, corrupted JNI inputs, values that no caller can produce), it is not a real finding — drop it. Focus on bugs that real workloads can trigger, not theoretical edge cases that exist only in the type system.
- QuestDB runs with Java assertions enabled (
-ea). Assertions are a valid guard for invariants that indicate corruption or internal bugs. Do NOT flagassertas insufficient — it is the preferred mechanism for conditions that should never occur in a non-corrupt database. Only flag anassertif the condition can plausibly be triggered by normal (non-corrupt) user operations.
Review level
Parse $ARGUMENTS for a level token: --level=N, -lN, or a bare single digit 0-3. If no level is given, default to 0. Strip the level token and any --range= token before feeding the remainder (PR number or URL) to gh commands.
The level controls how much of the review below actually runs. Lower levels keep the same review spirit — adversarial, blocking, no praise — but cut the breadth of the analysis. Higher levels have significantly higher token cost; reserve level 3 for high-stakes PRs (replication, JNI boundary changes, on-disk format, public API, security/ACL).
| Level | What runs |
|---|---|
| 0 (default) | Steps 1, 2, 2.4, 2.6, 4. Skip Step 2.5 and agent fanout. Review the diff inline for correctness, NULL handling, algorithmic optimality, tests, and QuestDB standards. Build the Step 2.6 coverage map inline. Every candidate still passes the Step 3b admission gate inline from a blank evidence form; do not draft severity, a fix, or report prose first. |
| 1 | Adds Step 2.5a and Step 2.5e when test code is present. Run Agent 1 plus at most two applicable roles chosen from Agents 3, 5, 6, 12, and 13. Run an independent falsification task for each surviving atomic candidate. |
| 2 | Full Step 2.5, with 2.5b restricted to public/protected symbols. Run Agent 1 plus at most four change-relevant roles from Agents 2-8 and 11-13. Run an independent falsification task for each surviving atomic candidate. |
| 3 | Full Step 2.5 and the complete admission protocol. Select at most six applicable discovery roles from Agents 1-14: Agent 1 always; Agent 9 for changed symbols with out-of-diff callers; Agents 2-8 and 11 only when their domain is touched; Agents 12-14 only for changed tests or a fix claim; Agent 10 only when a distinct adversarial pass is warranted. Depth comes from producer/reachability evidence and independent falsification, not agent count. |
State the chosen level in one line at the start of the review so the user knows what they're getting (e.g., "Reviewing PR #1234 at level 2"). If the level was defaulted, mention that level 3 exists for full review.
Spawning review agents
Steps 3 and 3b use fresh-context agents through the Agent tool, one task per role or atomic falsification candidate. Each task is self-contained and read-only. Discovery tasks receive the diff, Step 2.4 provenance verdicts, the Step 2.5 surface map, the Step 2.6 coverage map, role instructions, and the candidate contract. Agents 10 and 11 are deliberate reduced-context exceptions. Step 3b falsifiers receive only the neutral proposition, revision identities, relevant files, and raw artifact paths. The parent owns role selection, the private ledger, admission, severity, and output.
Use a shared temporary artifact for large maps rather than pasting them repeatedly. Never pass the discovery narrative, proposed severity/fix, votes, or verification claims to a falsifier. Agents 10 and 11 receive only the diff and changed-file names, as their role descriptions require. The parent owns synthesis, deduplication, and the final report; children return candidates or falsification evidence only.
Step 1
Content truncated.
When not to use it
- →When a blocking code review is not required
- →When the goal is style auditing or refactoring
- →When the code is not mission-critical
Limitations
- →Zero tolerance for correctness issues, resource leaks, or undefined behavior
- →Does not praise code or soften language
- →Requires optimal algorithms and data structures
How it compares
This skill conducts a highly critical, adversarial code review focused on correctness, performance, and resource management, explicitly rejecting common review deferrals and demanding optimal solutions, unlike a typical code review.
Compared to similar skills
review-pr side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| review-pr (this skill) | 0 | 1mo | Review | Advanced |
| reviewing-code | 21 | 8mo | No flags | Intermediate |
| pr-review | 6 | 2mo | Review | Intermediate |
| code-review-checklist | 3 | 1mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by questdb
View all by questdb →You might also like
reviewing-code
CaptainCrouton89
Systematically evaluate code changes for security, correctness, performance, and spec alignment. Use when reviewing PRs, assessing code quality, or verifying implementation against requirements.
pr-review
pytorch
Review PyTorch pull requests for code quality, test coverage, security, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR".
code-review-checklist
vudovn
Code review guidelines covering code quality, security, and best practices.
fix-review
sickn33
Verify fix commits address audit findings without new bugs
django-verification
affaan-m
Verification loop for Django projects: migrations, linting, tests with coverage, security scans, and deployment readiness checks before release or PR.
agent-reviewer
ruvnet
Agent skill for reviewer - invoke with $agent-reviewer