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/cosmix/loom/loom-sql-optimizationnpx skills add cosmix/loom --skill loom-sql-optimizationgit clone --depth 1 https://github.com/cosmix/loomWrote 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/cosmix/loom/loom-sql-optimization)<a href="https://agentmods.dev/skills/cosmix/loom/loom-sql-optimization"><img src="https://agentmods.dev/badge/skills/cosmix/loom/loom-sql-optimization.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.00016 | $0.07008 |
| Opus 5 | $0.00008 | $0.03504 |
| Sonnet 5 | $0.00003 | $0.01402 |
| Haiku 4.5 | $0.00002 | $0.00701 |
Grade A, and why
loom-sql-optimization 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 — 545 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SQL Optimization
Overview
Analyzing and tuning SQL for performance: reading execution plans, index design, query rewriting, and PostgreSQL-specific behavior. Most notes assume PostgreSQL. The mechanism-level material — reading EXPLAIN, composite-index column order, partial-index limits, statistics, concurrency — is in Expert Practices below; this section is the workflow and the anti-pattern catalogue.
Workflow
- Find the slow query (logs,
pg_stat_statementsby total time, not just per-call). - Explain it:
EXPLAIN (ANALYZE, BUFFERS, SETTINGS). Read plans by estimated-vs-actual row divergence (bad stats → wrong join/scan choice), scan type, join algorithm, andRows Removed by Filter. See Expert Practices → Reading EXPLAIN. - Fix in priority order: refresh/extend statistics → add/reshape an index → rewrite the query → denormalize/derive → tune config. Change one thing at a time.
- Validate: re-EXPLAIN on production-like data, confirm the target node changed (Sort gone / Index Scan chosen / Heap Fetches low), verify correctness, monitor post-deploy.
Best Practices
EXPLAIN (ANALYZE, BUFFERS)is the source of truth — never optimize by guessing; actual rows and buffers reveal the real cost.- Select only needed columns (enables index-only scans; avoids TOAST/wide-row I/O).
- Index for WHERE/JOIN/ORDER BY, but mind column order and the write tax (Expert Practices → Index Design).
- Avoid N+1: one JOIN or a batched
WHERE id = ANY($1), not a query per row. NOT EXISTS, neverNOT IN (nullable subquery)— one NULL silently returns zero rows;NOT EXISTSis NULL-safe and hash-anti-join-able. (InclusionIN/ANY/EXISTSplan identically in modern PG — pick readability.)- No functions/implicit casts on indexed columns (
WHERE lower(x)=needs an expression index;WHERE int_col = '1'may cast and skip the index). - Keyset pagination, not deep
OFFSET(Expert Practices). - CTEs are not fences (PG12+): a non-recursive, side-effect-free CTE used once is inlined; used >1× it materializes. Force with
AS MATERIALIZED/AS NOT MATERIALIZED; theOFFSET 0trick is obsolete. ANALYZEafter bulk loads; monitor query performance over time.
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 · 545 lines · 16 tokens per session scan A 83142f745312
loom-sql-optimization is a skill published in the GitHub repository cosmix/loom (54 stars, last pushed yesterday), licensed MIT. It adds 16 tokens to every session and 7,008 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
postgresql-review
PostgreSQL query review, optimalisering og beste praksis for Nav-applikasjoner.
database-architecture
MANDATORY when designing schemas, writing migrations, creating indexes, or making architectural database decisions - enforces PostgreSQL 18 best practices including AIO, UUIDv7, temporal constraints, and modern indexing strategies.
timescaledb
MANDATORY when working with time-series data, hypertables, continuous aggregates, or compression - enforces TimescaleDB 2.24.0 best practices including lightning-fast recompression, UUIDv7 continuous aggregates, and Direct Compress.
postgis
MANDATORY when working with geographic data, spatial queries, geometry operations, or location-based features - enforces PostGIS 3.6.1 best practices including STCoverageClean, SFCGAL 3D functions, and bigint topology.
postgres-rls
MANDATORY when touching auth tables, tenant isolation, RLS policies, or multi-tenant database code - enforces Row Level Security best practices and catches common bypass vulnerabilities.
alloydb-basics
Manages clusters, instances, and backups for AlloyDB for PostgreSQL, and integrates with AlloyDB Model Context Protocol (MCP) tools for automated database operations. Use when creating, configuring, or administering AlloyDB databases. Do NOT use for general PostgreSQL instances (e.g. Cloud SQL) or other GCP databases.