Conciseness

The body is dense with project-specific knowledge Claude cannot infer (core stores table, migration naming policy, db-exec vs db-patch decision matrix, identity-column registration), so nearly every section earns its tokens. It is not a 5 because a few passages over-explain — e.g., the multi-sentence 'Why: version numbers alone are not a safe identity' paragraph and the enumerated list of binary payload types that could be tightened — and not a 3 because padding is minor rather than a pattern.

Actionability

Guidance is fully executable throughout: copy-paste Drizzle schema code, `registerIdentityColumns` examples with realistic argument shapes, exact commands (`pnpm db:generate`, `pnpm db:migrate`, `pnpm action db-patch --table <t> ... --find "<old>" --replace "<new>"`), React Query hook snippets, and a scenario table covering the common db-exec/db-patch cases. It is not a 4 because even edge cases (batched statements, attachment refs, local file mode) carry concrete commands and typed error handling rather than hints.

Workflow Clarity

Sequences exist (managed-scaffold flow: define in drizzle/schema.ts → `pnpm db:generate` → `pnpm db:migrate`; deploy: set `DATABASE_URL` → keep Postgres-compatible), but validation/verification checkpoints are implicit or absent for database operations — there is no 'verify the row/schema after db-patch or db-migrate' step, only a passing mention of `guard:additive-migrations`. Per the rubric cap, missing feedback loops for database operations holds this at 3; it is not a 2 because sequences themselves are clearly defined and partially gated (fail-closed storage errors, typed attachment-ref errors).

Progressive Disclosure

The single-file body is well organized with clear sections, tables, and a Related Skills list, and most policy content (storage rules, store catalog, access guidance) is appropriately placed inline. It is not a 5 because deep-detail material — the identity-column policy section and the migration naming rationale — is inlined rather than split into one-level-deep reference files, and not a 3 because navigation is easy and nothing is buried or duplicated.

Specificity

The description names the domain ('How to store application data in agent-native apps. All data lives in SQL.') with one concrete action — storing data — but lists no other specific capabilities (no SQL, schema, migration, or query operations), matching the 'domain and 1-2 concrete actions, but not comprehensive' anchor. It is not a 4 because it does not list several specific actions, and not a 2 because the SQL-source-of-truth rule makes the action concrete rather than generic.

Completeness

It explicitly answers both questions: what it does ('How to store application data in agent-native apps. All data lives in SQL.') and when to use it with three concrete trigger phrases ('Use when adding data models, deciding where to store data, or reading/writing application data'). This mirrors the 5 anchor's what-plus-explicit-trigger structure, and is not a 4 because the 'when' clause is already explicit and specific rather than needing more detail.

Trigger Term Quality

'Use when adding data models, deciding where to store data, or reading/writing application data' supplies natural developer phrasings ('data models', 'store data', 'reading/writing application data') that a user would plausibly say. It falls short of 5 because common synonyms and technology terms are missing ('database', 'SQL' as a trigger word, 'schema', 'Postgres', 'migrations').

Distinctiveness Conflict Risk

The scope is narrowed to 'agent-native apps' with a distinctive SQL-source-of-truth position, giving it a clear niche with minimal conflict risk against adjacent skills like context-awareness or real-time-sync. It is not a 5 because phrases like 'reading/writing application data' are broad enough to overlap with generic database or API-skills in this ecosystem.