Conciseness

The body is dense tables and terse bullets with zero padding and no explanation of concepts Claude already knows — every line carries non-obvious, project-specific information ('Documents scanned | 32,000 — includes documents `.filter()` discards'; 'Components cannot access `ctx.auth` or `process.env`'). This matches anchor 5 ('lean and efficient; every token earns its place'); nothing rises to the 'minor instances of over-explanation' of anchor 4.

Actionability

Exact commands and API identifiers appear throughout ('ctx.scheduler.runAfter(0, internal.x.batch, { cursor: result.continueCursor })', 'npx convex env set', 'v.null(), never v.undefined()'), giving mostly executable guidance per anchor 4. It falls short of anchor 5's copy-paste-ready completeness: the deploy checkpoint table says 'checklist completed' for breaking changes but no checklist exists anywhere in the skill, and widen-migrate-narrow is compressed to one line ('widen, migrate, then narrow') without concrete steps.

Workflow Clarity

The Deploy Loop is a clear sequence ('npx convex dev' → verify → 'npx convex deploy') with an explicit error-recovery feedback loop (roll back via 'npx convex import' of the last good export, fix locally, re-deploy) and a five-row checkpoint table, satisfying anchor 4. It misses anchor 5 because the 'Breaking change | checklist completed' checkpoint references a checklist that is never shown, leaving a minor validation gap; the cap-at-3 rule for missing validation does not apply since verification steps are present.

Progressive Disclosure

A single well-sectioned file (Hard limits, Rules by function type, Deploy Loop) with clearly signaled one-level-deep references to the project config ('.opencastle/stack/database-config.md') and official docs, matching anchor 4's 'good structure; most content appropriately placed'. It is not anchor 5: the body exceeds the under-50-lines simple-skill bar, and the migration checklist referenced in the deploy table points to no defined location, a minor navigation gap.

Specificity

The 'when' clause lists several concrete actions ('designing a Convex schema, writing Convex functions, setting up Convex auth, or migrating Convex data') and the 'what' enumerates seven capability areas, matching anchor 4's 'several specific actions; minor gaps in coverage' — deployment, a substantial portion of the skill body, is omitted from both what and when. It falls short of anchor 5's 'comprehensive coverage' because of that gap.

Completeness

Both halves are explicit: the 'what' ('Convex schemas, queries, mutations, actions, auth, migrations and components') and the 'when' ('Use when designing a Convex schema, writing Convex functions, setting up Convex auth, or migrating Convex data') with concrete trigger phrases, matching anchor 5 exactly. It is not anchor 4 because the 'when' clause is already fully explicit and specific rather than merely serviceable.

Trigger Term Quality

Natural terms users would say are present and repeated ('Convex schema', 'Convex functions', 'Convex auth', 'migrating Convex data'), giving good keyword coverage per anchor 4. It misses anchor 5's comprehensive coverage: 'deploy' / 'npx convex' — phrases a user asking to deploy their Convex backend would actually say — trigger no match in the description.

Distinctiveness Conflict Risk

'Convex' anchors every capability and every trigger phrase, carving a clear niche (a specific backend platform) with distinct triggers and minimal conflict risk with generic database or ORM skills, matching anchor 5. There is no vagueness that would pull it toward anchors 3 or below.