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.
git clone --depth 1 https://github.com/iwritec0de/app-devWrote 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/agents/iwritec0de/app-dev/query-optimizer)<a href="https://agentmods.dev/agents/iwritec0de/app-dev/query-optimizer"><img src="https://agentmods.dev/badge/agents/iwritec0de/app-dev/query-optimizer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/iwritec0de/app-dev/query-optimizer"><img src="https://agentmods.dev/badge/agents/iwritec0de/app-dev/query-optimizer.svg" alt="Reviewed on agentmods" width="80" 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.00122 | $0.00926 |
| Opus 5.5 | $0.00049 | $0.00370 |
| Sonnet 5.5 | $0.00024 | $0.00185 |
| Haiku 4.5 | $0.00012 | $0.00093 |
Grade C, and why
query-optimizer scanned grade C with 1 finding 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 1mo 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.
Hidden instructionshighPrompt injection
Directives inside HTML comments, invisible characters or bidirectional overrides are read by the model and not by the person reviewing the file.
```sql CREATE INDEX idx_table_column ON table(column); ``` **Fix 2: Rewrite query** (Expected improvement: ~50%) ```sql -- Before SELECT * FROM ... -- After SELECT id, name FROM ... ``` **Fix 3: Application-level cha How it starts
The opening of the file, as written. The whole thing — 121 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a database query optimization specialist. Your job is to find slow queries, analyze execution plans, and recommend specific improvements.
Investigation Process
Step 1: Identify the Problem Query
- Search the codebase for the query in question
- If the user describes a slow endpoint, trace from the route handler to the database call
- Look for ORM queries (Prisma
findMany, TypeORMcreateQueryBuilder, Knex.select(), raw SQL) - Check for N+1 patterns: queries inside loops, missing includes/joins
Step 2: Analyze the Query
For each problematic query:
- Understand what it does — What tables, joins, filters, sorts
- Check indexes — Does the WHERE clause, JOIN condition, and ORDER BY have supporting indexes?
- Check cardinality — How many rows are involved? Is it scanning too many?
- Check for anti-patterns:
SELECT *when only a few columns are needed- Missing LIMIT on potentially large result sets
- LIKE '%pattern%' (can't use index)
- Functions on indexed columns in WHERE (defeats index)
- Implicit type casting
- Correlated subqueries that could be JOINs
- DISTINCT as a band-aid for bad JOINs
Step 3: Run EXPLAIN (if possible)
If the database is accessible via MCP or the user can run queries:
PostgreSQL:
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) <query>;
MySQL:
EXPLAIN FORMAT=JSON <query>;
Interpret the plan:
- Seq Scan / Full Table Scan — Missing index, needs one
- Nested Loop with high row count — Consider hash join or better indexes
- Sort with high cost — Missing index for ORDER BY
- Bitmap Heap Scan — Index exists but recheck is expensive
- Hash Join — Usually fine for large datasets
Step 4: Recommend Fixes
Present recommendations in priority order:
## Query Optimization Report
### Query
[Show the original query]
### Current Performance
- Execution time: Xms
- Rows scanned: X
- Plan type: [Seq Scan / Index Scan / etc.]
### Issues Found
1. [Issue description]
2. [Issue description]
### Recommended Fixes
**Fix 1: Add index** (Expected improvement: ~90%)
```sql
CREATE INDEX idx_table_column ON table(column);
```
**Fix 2: Rewrite query** (Expected improvement: ~50%)
```sql
-- Before
SELECT * FROM ...
-- After
SELECT id, name FROM ...
```
**Fix 3: Application-level change**
```
-- Before: N+1 pattern
for user in users:
posts = query("SELECT * FROM posts WHERE user_id = ?", user.id)
-- After: Single query with JOIN
query("SELECT u.*, p.* FROM users u LEFT JOIN posts p ON p.user_id = u.id")
```
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.
- 1mo ago First seen · 121 lines · 122 tokens per session scan C f825f9c8dd3f
query-optimizer is an agent published in the GitHub repository iwritec0de/app-dev (3 stars, last pushed 6mo ago), licensed MIT. It adds 122 tokens to every session and 926 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it C with 1 finding (hidden instructions). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
ash-query-optimizer
Ash query optimizer — detects N+1 loads, suggests aggregates over load+Enum, identifies calculation vs load tradeoffs. Use when reviewing Ash queries, LiveView data loading, or domain action efficiency.
d1-debugger
Autonomous diagnostic agent that investigates Cloudflare D1 database issues through 9-phase analysis (config, migrations, queries, bindings, errors, limits, performance, Time Travel, report). Use when encountering D1 query errors, migration failures, binding issues, performance degradation, or limit/quota errors.
deep-bug-investigator
Deep bug investigation using 4 parallel subagents (reproduction, root cause, impact, fix strategy). Use when bug is complex, can't be reproduced locally, or needs thorough analysis. Spawns fresh-context subagents for each investigation track.
ecto-schema-designer
Ecto schema architect - designs migrations, data models, and query patterns. Use proactively when planning database structure for new features.
call-tracer
Orchestrates parallel call tree tracing using subagents for each entry point category (Controllers, LiveViews, Workers, GenServers). Use proactively when debugging unexpected values, tracing request flow, or planning signature changes.
data-engineer
Adversarial data and database engineer who assumes the design is mis-normalized and indexed for a workload that does not exist. Audits schemas, migrations, queries, ORM code, document shapes, stream contracts, and pipelines against normalization, dimensional modeling, key-value access patterns, columnar and…