QuestDB is an open-source database for storing, ingesting, and querying time-series data such as market events. It is used for low-latency workloads that need live calculations and long-term historical queries through SQL. The catalogue skills support working with QuestDB.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/questdb/questdb/review-prnpx skills add questdb/questdb --skill review-prgit clone --depth 1 https://github.com/questdb/questdbWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/questdb/questdb/review-pr)<a href="https://agentmods.dev/skills/questdb/questdb/review-pr"><img src="https://agentmods.dev/badge/skills/questdb/questdb/review-pr.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00018 | $0.22743 |
| Opus 5 | $0.00009 | $0.11371 |
| Sonnet 5 | $0.00004 | $0.04549 |
| Haiku 4.5 | $0.00002 | $0.02274 |
Grade A, and why
review-pr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 901 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 901 lines · 18 tokens per session scan A 632b16b0c67b
review-pr is a skill published in the GitHub repository questdb/questdb (17,298 stars, last pushed today), licensed Apache-2.0. It adds 18 tokens to every session and 22,743 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
alert-rule-troubleshoot
This skill should be used when the user reports that an alert rule is "not firing", "no alert was sent", "the rule didn't trigger", "the rule isn't working", "it should have alerted but didn't", "why didn't I get an alert", "alert rule not firing", or wants to diagnose why a specific alert rule failed to produce an…
create-alert-rule
Create alert rules. Prefer reusing the validated rules in integrations (standard components like Linux/MySQL/Redis/Kafka/PostgreSQL/Elasticsearch all ship ready-made rule packs); import as many rules as the user needs—one rule, a batch, or a whole pack. Only hand-write a custom rule when integrations has nothing that…
generate-message-template
Generate or modify Nightingale (n9e) alert notification message templates. Use when the user asks to write a notification template, change the message format, add hostname/recovery value/severity, or create DingTalk/Feishu/Lark/email/SMS/voice templates.
ops-troubleshooting
This skill should be used when the user asks to "troubleshoot", "diagnose", "debug alert", "investigate incident", "locate a fault", "investigate an alert", "diagnose a problem", "fix an issue", "check alerts", "analyze alerts", "root cause analysis", "check metrics", "check logs", or discusses…
doc-qa
This skill should be used when the user asks "how-to" or factual questions about Nightingale (n9e) — UI/where-to-click, business groups/subscription rules/mute rules/edge mode, Token usage, notification pipeline, self-healing trigger conditions; OR about categraf input plugin field meanings, metric names, defaults…
notify-rule-copilot
One-stop assistant for creating, editing, copying, and troubleshooting Nightingale (n9e) notify rules (notifyrule). Use it when the user asks to "create a notify rule / add a notification policy / configure how alerts are delivered / edit and adjust a notify rule / tiered notification / route by business group or…