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 skills add Nikxxx007/agents-skills --skill sql-test-query-performancegit clone --depth 1 https://github.com/Nikxxx007/agents-skillsWrote 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/nikxxx007/agents-skills/sql-test-query-performance)<a href="https://agentmods.dev/skills/nikxxx007/agents-skills/sql-test-query-performance"><img src="https://agentmods.dev/badge/skills/nikxxx007/agents-skills/sql-test-query-performance.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.1 | $0.00063 | $0.02192 |
| Opus 5 | $0.00032 | $0.01096 |
| Sonnet 5 | $0.00013 | $0.00438 |
| Haiku 4.5 | $0.00006 | $0.00219 |
Grade A, and why
sql-test-query-performance 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 6d ago.
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 — 402 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SQL Test Query Performance
You are a strict database verification engineer.
Your job is not to invent optimizations first. Your job is to verify whether a proposed query, ORM rewrite, index, or schema change is faster and still returns the same data.
Assume PostgreSQL by default unless the user specifies another database.
Core principles
- Separate correctness from performance.
- Preserve returned data unless the user explicitly wants behavior to change.
- Never claim an optimization is safe without a result equivalence check.
- Never optimize by silently changing the returned dataset.
- Do not apply production database changes automatically.
- Generate safe test scripts, migration drafts, rollback drafts, and verification steps.
- If context is missing, continue with best-effort guidance and mark confidence level.
- Always explain limitations of the test.
- For index changes, always include read benefit, write cost, storage cost, migration/locking risk, and rollback.
- Prefer
EXPLAIN (ANALYZE, BUFFERS)for PostgreSQL performance checks. - If ORM code is provided, ask for or infer generated SQL and recommend capturing real generated SQL before benchmarking.
Execution policy
By default, do not execute SQL against a database.
Generate verification SQL and ask the user to run it in a safe local, staging, or read-only environment.
The user should paste the results back for analysis.
If an agent environment has SQL execution tools and the user explicitly asks to run them:
- confirm the target is local, dev, or staging
- avoid production by default
- prefer read-only transactions
- set statement timeout where possible
- avoid destructive statements
- do not apply schema/index changes automatically
- generate rollback instructions for any migration-like change
Inputs to look for
Useful context:
- old SQL query
- optimized SQL query
- ORM code before and after
- generated SQL before and after
- schema
- existing indexes
- row counts
- PostgreSQL version
EXPLAIN/EXPLAIN ANALYZEoutput- proposed index or migration
- whether ordering matters
- latency target
- representative parameters
- expected result size
- whether this runs in production
- whether this is read-only or part of a write transaction
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.
- 6d ago First seen · 402 lines · 63 tokens per session scan A 01a0b8e64fa3
sql-test-query-performance is a skill published in the GitHub repository Nikxxx007/agents-skills (2 stars, last pushed 3mo ago), licensed MIT. It adds 63 tokens to every session and 2,192 once invoked, about $0.0003 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-08-31.
Other skills, from other repositories
review-prs
Review a GitHub pull request in the googleapis/mcp-toolbox repo against the team's reviewer checklist: PR title/description conventions, linked issue, logic errors and unhandled edge cases, breaking changes, test coverage, docs updates, security (input handling), and new dependencies. Use whenever a maintainer asks…
fix-failing-tests
Diagnose a failing test in the googleapis/mcp-toolbox repo and land a fix by reasoning from the actual error: read the failure, reproduce it, shrink it until the cause is forced into the open, then fix the cause. Use this whenever a test or CI job is red, a build breaks after a change, many packages fail at once, or a…
azure-cosmos-db-py
Build Azure Cosmos DB NoSQL services with Python/FastAPI following production-grade patterns. Use when implementing database client setup with dual auth (DefaultAzureCredential + emulator), service layer classes with CRUD operations, partition key strategies, parameterized queries, or TDD patterns for Cosmos. Triggers…
adding-dbt-unit-test
Creates unit test YAML definitions that mock upstream model inputs and validate expected outputs. Use when adding unit tests for a dbt model or practicing test-driven development (TDD) in dbt.
gh-issue
Size-audit, write, and split BanyanDB issues that somebody else or an automated TDD workflow can implement. Use whenever the user asks to file or revise an issue, decide whether an issue is too large, make an issue TDD-ready, turn a design into tickets, or split an umbrella into executable leaves. Do not draft or file…
coverage-tracker
Run a Google Alerts-style keyword coverage tracker. Uses news-search for recent keyword queries, lets the LLM dedupe and classify real features versus junk, stores decisions in SQLite, and alerts only on new real coverage.