Skills / db-optimize-query
db-optimize-query
Speed up a slow SQL query by reading its execution plan, finding missing indexes and N+1 patterns, and proving the change with before and after timings. Use when the user reports a slow query, a slow page caused by the database, or asks to review query performance. Do not use for schema design or migrations.
- Author
- agentsaisle
- Latest
- v0.1.0
- Aisle
- database
- Works with
- Claude Code, Codex, Cursor
- Source
- HazemSalah29/agentsaisle
- Stars
- 2
Install
Install db-optimize-query
npx @agentsaisle/cli add db-optimize-queryInstalls into your project's skills folder. Add --global to install it for every project.
Runs scriptsThis skill includes scripts
Your agent may run these scripts on your machine. A maintainer has read every one in full, and the CLI lists the files when you install. You can read them on GitHub first.
Read the files on GitHubAudit
- Critical
- 0
- High
- 0
- Medium
- 1
- Low
- 0
4 files · audited 2026-10-29 · rules 1.0.0
MediumAA-P02Can write files and run interpreters without disable-model-invocation
SKILL.md:6
Read Write Edit Glob Grep Bash(node *) Bash(psql *)Why The agent may load this skill on its own and then write files and run code in one go.
Fix Set disable-model-invocation: true so the user starts it, or narrow the Bash patterns.
What this skill can use
Tools
- Read
- Write
- Edit
- Glob
- Grep
- Bash(node *)
- Bash(psql *)
Scripts
- scripts/explain-summary.mjs
Domains mentioned
None
Automated checks found the patterns listed here. An audit reduces risk; it is not a guarantee of safety. How audits work · Read the rules
Show this grade in a README
The badge updates when the registry is rebuilt. Paste this Markdown into the README:
[](https://agentsaisle-vercel.vercel.app/skills/db-optimize-query)SKILL.md
Rendered from commit 276ea59
Query optimization
Use when
- A query or page is slow and the cause is the database.
- The code loops and runs one query per item (N+1).
Don't use when
- The problem is schema shape (use
db-schema) or a risky table change (usedb-migrate). - The engine is not PostgreSQL and no plan output is available. Say so and reason from the query alone.
Steps
- Get the slow query and the real parameters. Ask for
EXPLAINaccess if you do not have it; never guess timings. - Capture the baseline:
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) <query>saved tobefore.json(psql:-At). Run it twice; use the second run. - Run
node <skill>/scripts/explain-summary.mjs before.json. Read the findings: sequential scans, wrong row estimates, many loops, disk sorts. - Change one thing: an index that matches the filter and sort order, a rewritten join, fetching in one query instead of many,
ANALYZEfor stale statistics. Never add an index you cannot justify from the plan. - Capture
after.jsonthe same way and runnode <skill>/scripts/explain-summary.mjs before.json after.json. - If the change is an index, hand it to
db-migraterules: create it concurrently.
Budget
- Search first (grep, glob, symbol search). Read line ranges, not whole files.
- Read at most 8 files per step. If you need more, write down what you learned and narrow the question.
- Do not re-read a file you just wrote or edited.
- Prefer the smallest command output that answers the question: head, tail, quiet flags, filtered lists.
- Never paste a full plan into the conversation; use the script's summary.
Output
- The change, the before and after timings from the script, and the remaining findings, if any.
Done when
- The after plan shows the improvement in the script's comparison.
- No new problems appear in the comparison.
- Results are reported as measured on this machine and data, not as a promise.
Version history
| Version | Commit | Install |
|---|---|---|
| 0.1.0latest | 276ea59 | add db-optimize-query |