Conciseness

The bulk is high-value operational content (grep patterns, gating, verification steps) rather than explanation of known concepts, but there is noticeable trimmable material: the five Invocation Examples, the Related and Scope sections, and per-pattern repetition of gating rules. Pattern 11 also pins time-sensitive version numbers ("7.11.0 – 7.11.1 (latest)", "still unfixed in 7.11.1") inline rather than in an old-patterns/deprecated section, which the guidelines penalize. Mostly efficient but could be tightened — anchor 3, not the lean anchor 5 nor the padded anchor 2.

Actionability

Every detector gives an exact search regex (e.g. `INSERT\s+OR\s+REPLACE`, `static\s+let\s+databaseSelection`), a concrete Read-verification procedure, and a copy-paste-ready fix (`execute(sql: "WHERE id = ?", arguments: [id])`, `PRAGMA journal_mode = WAL`, `config.observesSuspensionNotifications = true`). Pattern 11 even includes a version-gated decision table with the exact GRDB versions and symptom string. Fully executable guidance covering the common cases — anchor 5.

Workflow Clarity

The five phases (Framework Detection → Pattern Detectors → Completeness Reasoning → Cross-Reference → Health Score) are clearly sequenced, with explicit validation checkpoints throughout: "use Read to verify the surrounding context before reporting — grep patterns have high recall but need contextual verification", "Require evidence from the Phase 1 map — don't speculate", gating to suppress false positives, and an error-recovery path ("report an unresolvable GRDB version as a LOW-confidence finding with the reason, not as a clean pass"). A defined output format with output limits completes the loop — anchor 5.

Progressive Disclosure

There is good internal section structure and the external `axiom-data (skills/grdb-performance.md)` references are clearly signaled with section numbers one level deep, but no bundle files exist and the 26KB body is monolithic — content that would serve better in separate reference files (Pattern 11's version table, Phase 3's twelve-row completeness table, the per-pattern detail) is inlined. Anchor 3: some structure, references present, but content that should be separate is inline.

Specificity

The description names the domain ("GRDB performance review", "app-group database setup audit") and embeds action nouns like "review", "audit", and "scan", but it never explicitly states what the skill does — the capability side is inferred entirely from trigger phrasing. It sits between anchor 2 (only 'when', no 'what') and anchor 4: more concrete than anchor 2's vague example, but without the several specific actions anchor 4 requires.

Completeness

The 'when' is explicit and rich ("Use when the user mentions…" with five concrete triggers), but the 'what' — that the skill detects performance and correctness anti-patterns and produces a health score — is only implied by nouns inside the trigger list, never stated. This sits between anchors 2 and 4: above anchor 2 (whose 'when'-only example is vague) but below anchor 4, which requires an explicit 'what' alongside the 'when'.

Trigger Term Quality

Phrases like "slow GRDB queries", "a ValueObservation that stopped updating", and "pre-release GRDB scan" are natural things a user would say, giving good coverage. A few natural variations are missing — "SQLite performance", "widget database sharing", "database locked" — and "app-group database setup audit" leans toward internal jargon, so it falls short of anchor 5's comprehensive synonym coverage.

Distinctiveness Conflict Risk

Triggers like "GRDB performance review" and "a ValueObservation that stopped updating" occupy a clear niche with distinct, technology-specific keywords; virtually no other skill would fire on them. Minimal conflict risk, matching anchor 5.