Conciseness

The body is dense with novel information — no 'what is Postgres' filler, tables for CLI/REST, one-line error-to-fix mappings — but is ~350 lines with some fat that could be trimmed: the full REST API endpoint table is inlined, the CLI table duplicates references/cli-commands.md, and the appended house-rules section re-states rules the body already covers (e.g. the @beta pin, preview-PII warning, no drizzle-kit push). Not 5: every token does not quite earn its place given that duplication; not 3: there is no over-explanation of concepts Claude already knows.

Actionability

Fully executable throughout: copy-paste-ready TypeScript for the client, transactions, Drizzle config/schema/client, an HTTP function, a vitest harness, and a migration SQL file; exact install commands ('npm install @netlify/database drizzle-orm@beta'), exact env var names (NETLIFY_DB_URL), and exact CLI invocations with flags. Not 4: it goes beyond minor gaps by covering the common cases end-to-end, including the gotcha fixes ('pass connectionString explicitly').

Workflow Clarity

Multi-step flows are clear and validation is present where it matters: migration footguns enumerate the exact error ('migration "<name>" has been modified after being applied') with the corrective action, failed migrations block publish, 'netlify database status' verifies applied/pending, and destructive operations (branch delete, snapshot restore, reset) require explicit confirmation. Not 5: the core setup→migrate→deploy sequence is spread across sections rather than given as one explicitly ordered checklist, and local verification of preview-branch behavior is left to the reference files.

Progressive Disclosure

Good structure with clearly signaled one-level-deep references that all exist (references/migrations.md, local-dev.md, cli-commands.md, migration-from-extension.md, legacy-extension.md, operational-footguns.md), each placed after the section it extends. Not 5: the body is more than an overview — the REST API table and the CLI flag table are inlined in full rather than split into the existing reference bundle, which also creates duplication with references/cli-commands.md; not 3: references are well-signaled and content placement is otherwise appropriate.

Specificity

The description enumerates multiple specific concrete actions — 'querying data from Functions/Edge Functions, writing schema migrations, setting up Drizzle ORM, local dev with netlify dev, database branches for deploy previews, and migrating an existing Postgres project onto Netlify' — with comprehensive coverage of the skill's surface. Not 4: there are no meaningful coverage gaps; it names the package, the runtimes, the ORM, local dev, branching, and migration paths.

Completeness

It explicitly answers both parts: what ('Zero-config Postgres for Netlify apps via @netlify/database' plus the enumerated capabilities) and when ('Use when adding a database, building a contact form or CRUD API, ... or switching from Neon/Supabase/RDS to Netlify Database') with concrete trigger phrases. This mirrors the anchor-5 exemplar structure; the 'when' is explicit, multi-trigger, and specific.

Trigger Term Quality

The 'Use when' clause covers natural phrases users would actually say: 'adding a database', 'building a contact form or CRUD API', 'writing SQL migrations', 'wiring up Drizzle', 'running netlify database commands', 'testing with a local Postgres', and competitor synonyms 'switching from Neon/Supabase/RDS'. Not 4: even beyond common variations it includes the product-specific names (Neon/Supabase/RDS, Drizzle, netlify dev) a migrating user would name.

Distinctiveness Conflict Risk

It occupies a clear niche (Netlify's managed Postgres) with distinct triggers — @netlify/database, netlify database commands, netlify dev, deploy previews, Neon/Supabase/RDS switching — that no generic Postgres or Drizzle skill would claim. Not 4: overlap risk with a generic Drizzle/Postgres skill is minimal because every trigger is Netlify-scoped.