The body is lean: the Overview crisply enumerates the five failure modes, steps are terse, and it avoids explaining concepts Claude already knows (no primer on what an index or a database is), with every section earning its place.

Provides fully executable vendor-specific EXPLAIN commands, copy-paste CREATE INDEX examples (single, composite, partial, functional, covering), and a complete worked output-format template — concrete and copy-paste ready rather than pseudocode.

A clear four-step sequence (get EXPLAIN ANALYZE → identify dominant cost → match to fix → emit candidate) with an explicit validation checkpoint in the output format that re-runs EXPLAIN ANALYZE and confirms the new plan meets budget.

The body is an overview that points to one real, one-level-deep reference file (references/plan-signatures.md, verified to exist), signaled inline at each relevant step for cost signatures, diagnosis-to-fix, index choice, and anti-patterns.

Lists multiple concrete actions — 'identifies the dominant cost (sequential scan, nested loop, sort spill, missing index, type-cast preventing index use)', 'proposes the specific index or query rewrite', and 'emits the candidate CREATE INDEX statement' — matching the anchor for listing multiple specific concrete actions.

Clearly answers both what (reads plan output, identifies cost, proposes index/rewrite, emits CREATE INDEX) and when, with an explicit 'Use when load testing or production telemetry shows the database as the bottleneck' trigger clause.

Covers natural practitioner terms users would actually say — 'EXPLAIN / EXPLAIN ANALYZE', 'PostgreSQL, MySQL, or SQLite', 'load testing', 'production telemetry', 'database as the bottleneck' — providing good coverage of natural triggers rather than only jargon.

Occupies a clear niche (query-plan analysis across three named databases) with distinct triggers tied to DB-bound latency and an explicit non-applicability carve-out, making it unlikely to trigger for the wrong skill.