Conciseness

The body is lean with zero padding: no explanation of what SQL, CTEs, or execution plans are — inline code comments carry the rationale instead ('filter early, before the join', 'no self-join required', 'always use ANALYZE to see actual row counts vs. estimates'). Every section (workflow, reference table, examples, constraints, output templates) earns its place.

Actionability

Four complete, executable SQL blocks (CTE with ROW_NUMBER, running-total/rank window functions, 'EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)', and a before/after correlated-subquery fix with a covering-index CREATE INDEX statement), plus concrete interpretation rules ('Seq Scan on large table → add or fix an index', 'high read count signals missing cache / index') and actionable MUST DO / MUST NOT DO and output-template lists.

Workflow Clarity

The five-step workflow (Schema Analysis → Design → Optimize → Verify → Document) has an explicit validation step with a feedback loop: 'Run EXPLAIN ANALYZE and confirm no sequential scans on large tables; if query does not meet sub-100ms target, iterate on index selection or query rewrite before proceeding' — exactly the verify→fix→retry loop the rubric demands for database operations, so no cap applies.

Progressive Disclosure

Reference Guide table maps Topic → Reference → 'Load When' with all five listed files (query-patterns.md, window-functions.md, optimization.md, database-design.md, dialect-differences.md) present in references/ and containing no further nested references (one level deep). Only brief quick-reference examples are inlined; the bulk of detail lives in the bundle.

Specificity

Multiple specific concrete actions with comprehensive coverage: 'Optimizes SQL queries, designs database schemas, and troubleshoots performance issues' plus 'covering index creation, recursive queries, EXPLAIN/ANALYZE interpretation, before/after query benchmarking, or migrating queries between database dialects'. No gaps across writing, optimizing, and schema design for the SQL domain, so it fits the top anchor rather than 'minor gaps in coverage'.

Completeness

Explicitly answers both questions: what — 'Optimizes SQL queries, designs database schemas, and troubleshoots performance issues'; when — 'Use when a user asks why their query is slow, needs help writing complex joins or aggregations, mentions database performance issues, or wants to design or migrate a schema.' This mirrors the rubric's anchor-5 example structure exactly, so not the 'when could be more explicit' anchor.

Trigger Term Quality

Natural user phrasing is present ('asks why their query is slow', 'needs help writing complex joins or aggregations', 'mentions database performance issues') alongside technical terms users actually say ('window functions', 'CTEs', 'indexing strategies', 'query plan analysis', 'EXPLAIN/ANALYZE') and product names ('PostgreSQL, MySQL, SQL Server, Oracle') — comprehensive coverage including synonyms ('query plan analysis' / 'EXPLAIN/ANALYZE interpretation'), so not the 'a few natural terms missing' anchor.

Distinctiveness Conflict Risk

Clear niche with distinct triggers: window functions, CTEs, covering indexes, EXPLAIN/ANALYZE interpretation, and named dialects (PostgreSQL, MySQL, SQL Server, Oracle) are unambiguously SQL-tuning territory with minimal conflict risk against adjacent data-analysis or general-programming skills.