Conciseness

The structural sections (workflow, constraints, reference table) are lean and list-based, but two sections are pure padding: the 'Role Definition' persona paragraph ('a senior database performance engineer with 10+ years of experience') and the 'Knowledge Reference' keyword dump ('pg_stat_statements, EXPLAIN ANALYZE, indexes, VACUUM, partitioning...') that tells Claude nothing it doesn't already know. This matches anchor 3 — mostly efficient with some unnecessary explanation that could be trimmed — rather than 2, since no concept is actually explained at length.

Actionability

The body contains no executable code, SQL, or commands anywhere — even the highest-value moments stay abstract ('Analyze EXPLAIN plans before optimizing', 'Measure performance before and after changes'). This matches anchor 2: minimal concrete guidance with high-level hints but missing the specific steps to execute. Not 3 because there isn't even partial concrete material like a sample pg_stat_statements query or an EXPLAIN ANALYZE invocation in the body; the concrete detail is entirely deferred to reference files.

Workflow Clarity

The 5-step Core Workflow (Analyze → Identify → Design → Implement → Validate) is a clear sequence, and validation checkpoints are explicitly present ('Measure performance before and after changes', step 5 'Validate Results - Measure improvements, ensure stability'), which satisfies the database-operations feedback-loop expectation and avoids the cap at 3. Not 5 because the steps lack executable commands or explicit error-recovery loops (the anchor-5 pattern of 'if X fails, fix and re-check'), leaving minor validation gaps.

Progressive Disclosure

The Reference Guide table gives a clear overview with well-signaled, one-level-deep references, each paired with a 'Load When' condition, and all five referenced files (query-optimization.md, index-strategies.md, postgresql-tuning.md, mysql-tuning.md, monitoring-analysis.md) exist with substantive content. This matches the anchor-5 example of a clear overview pointing to well-signaled separate files with no nesting.

Specificity

The description lists several specific actions — 'investigating slow queries, analyzing execution plans', 'index design, query rewrites, configuration tuning, partitioning strategies, lock contention resolution' — comparable to the anchor-4 example of several specific actions with minor gaps. Not 5 because coverage has gaps: schema design, monitoring, and engine-specific work (PostgreSQL/MySQL) named in the metadata are absent from the description itself; not 3 because far more than 1-2 concrete actions are named.

Completeness

Explicit trigger guidance is present ('Use when investigating slow queries...') so the completeness cap of 3 does not apply, and the 'what' is conveyed through the named capabilities ('index design, query rewrites, configuration tuning'), matching anchor 4: both what and when present, but the 'what' is phrased only via 'Invoke for...' rather than a declarative capability statement, so it could be more explicit — which keeps it below the anchor-5 example that cleanly separates both.

Trigger Term Quality

Good natural keyword coverage: 'slow queries', 'execution plans', 'database performance', 'index', 'query rewrites', 'lock contention' are phrases users would actually say. Not 5 because common synonyms and specifics are missing — engine names (Postgres/MySQL, which appear only in frontmatter metadata), 'database is slow', 'tune/tuning' as a user verb.

Distinctiveness Conflict Risk

Clear niche (database performance optimization) with distinct triggers — 'execution plans', 'partitioning strategies', 'lock contention resolution' would not plausibly route to a general coding or document skill, matching the anchor-5 'clear niche with distinct triggers; minimal conflict risk'.