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/antonrisch/db-skills/debug-slow-queriesnpx skills add antonrisch/db-skills --skill debug-slow-queriesgit clone --depth 1 https://github.com/antonrisch/db-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/antonrisch/db-skills/debug-slow-queries)<a href="https://agentmods.dev/skills/antonrisch/db-skills/debug-slow-queries"><img src="https://agentmods.dev/badge/skills/antonrisch/db-skills/debug-slow-queries.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.00046 | $0.01070 |
| Opus 5 | $0.00023 | $0.00535 |
| Sonnet 5 | $0.00009 | $0.00214 |
| Haiku 4.5 | $0.00005 | $0.00107 |
Grade A, and why
debug-slow-queries 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 — 192 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debug Slow Queries
Quick Start
Goal: go from "slow" to a verified fix with minimal risk.
When to use this skill
- p95 latency spikes, timeouts, or sudden cpu growth tied to database load
- a deploy introduces query regression
- tables grow and plans flip (index → seq scan, join strategy changes)
inputs to collect (before changing anything)
- database engine + version
- query text + typical parameters (not placeholders only)
- runtime evidence: p50/p95, rows returned, timeouts, error logs
- table sizes / row counts (approx)
- relevant indexes + constraints
- environment: prod vs staging, read replica vs primary
Workflow (default)
- reproduce or capture
- reproduce in staging with production-like data, or capture the exact query + params from logs
- baseline
- record current p50/p95 and the explain plan
- read the plan
- identify where time is spent (scan, join, sort, aggregate)
- pick the cheapest safe fix
- rewrite query → add/adjust index → update stats → change schema
- verify
- re-run explain, compare timing, validate correctness
- roll out safely
- ship behind a flag if needed, monitor, keep rollback path
Explain plan patterns (what to look for)
scans
- sequential scan on large table
- likely missing selective predicate index, or predicate is not sargable
- index scan returning many rows
- index exists but selectivity is poor; may need different leading columns or a partial index
joins
- nested loop with huge inner iterations
- inner side needs an index on join key, or join order needs improvement
- hash join spilling
- work_mem/memory pressure or too many rows; reduce join input with earlier filters
sorts / aggregates
- sort on large result
- add index to match order by, or paginate differently
- group by on many rows
- pre-filter, pre-aggregate, or add covering index for grouping columns
Engine-specific commands
PostgreSQL
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 · 192 lines · 46 tokens per session scan A 753ccc235744
debug-slow-queries is a skill published in the GitHub repository antonrisch/db-skills (9 stars, last pushed 7mo ago), licensed MIT. It adds 46 tokens to every session and 1,070 once invoked, about $0.0002 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
sql-optimizer
Analyzes SQL queries for missing indexes, N+1 patterns, suboptimal joins, and full table scans. Interprets EXPLAIN, detects anti-patterns, rewrites queries. Triggers on: "optimize this query", "slow query", "add indexes", "explain plan", "N+1 query", "why is this query slow".
doris-debug-deployment
Use for Doris FE/BE startup failures, port conflicts, prioritynetworks misrouting, metadir corruption, and ADD/DROP BACKEND issues.
doris-debug
Apache Doris production diagnostics router. Use when Apache Doris queries are slow, imports are failing or timing out, compaction is raising -235 errors, nodes are OOM or crashing, materialized views are not rewriting, or tablet/replica health is degraded. Routes to the appropriate doris-debug- skill. Covers…
creating-oracle-to-postgres-migration-bug-report
Creates structured bug reports for defects found during Oracle-to-PostgreSQL migration. Use when documenting behavioral differences between Oracle and PostgreSQL as actionable bug reports with severity, root cause, and remediation steps.
transactions-locks
Транзакции, блокировки и ответственное чтение 1С. Используй когда нужно написать или отревьюить транзакцию, поставить управляемые блокировки, решить надо ли блокировать чтение перед записью, разобрать ошибку «В этой транзакции уже происходили ошибки», ожидание блокировки, deadlock или избыточные блокировки.
query-optimize
Оптимизация запросов 1С и СКД. Используй когда нужно написать, проверить или ускорить запрос, СКД query, временные таблицы, виртуальные таблицы, отборы, соединения или проблемный SQL/DBMS trace.