Conciseness

The body is dense, checklist-driven, and assumes Convex competence — no space is spent explaining concepts Claude already knows. However, the destructive-apply and cleanup-removal confirmation gates are each stated two or three times (Safety Rules, Phase 5 step 4, Phase 6 step 1), and bounded-batch resumption appears in both Phase 5 and Phase 6; this deliberate but trimmable duplication keeps it at anchor 4 ('minor instances... that could be trimmed') rather than 5.

Actionability

Concrete executable commands are given for validation (`bunx convex codegen`, `bunx tsc --noEmit`, `bun run ci:static`, `bunx convex dev --once`, `convex run`) plus specific result fields (`isDone`, `dryRun`, resume cursors, confirmation token), matching 'mostly executable guidance with minor gaps'. Not a 5 because the actual dry-run/apply command shapes are delegated to `@convex-dev/migrations` and companion skills rather than shown, so nothing is copy-paste ready for the core production steps.

Workflow Clarity

Seven clearly sequenced phases with explicit validation checkpoints at every gate: local validation ladder before PR, deploy success before dry run, dry-run results presented before apply, explicit user confirmation before both apply and cleanup removal, verification proving zero remaining targets, and resume-until-isDone feedback loops with documented safety caps. This matches anchor 5 (explicit validation steps, error-recovery loops, checklists for a complex destructive process); the destructive-operation cap of 3 does not apply since validation is pervasive.

Progressive Disclosure

The body is well organized into scannable phase sections and appropriately delegates detail to companion skills (`convex-migration-helper`, `clawhub-convex`, `clawhub-production-release`) rather than inlining it. It stays at anchor 4 rather than 5 because at ~170 lines it is a single monolithic file with no one-level-deep bundled references (no references/ or scripts/ exist), and some per-phase detail checklists could be split out to shorten the always-loaded overview.

Specificity

The description enumerates multiple concrete job types ("end-to-end ClawHub Convex production migrations, backfills, destructive cleanups, and one-off maintenance functions") and the full action lifecycle ("created, validated, shipped, run, verified, then removed after completion"), giving comprehensive coverage of what the skill handles. Anchor 4 falls short because there are no real gaps in coverage; anchor 4's 'minor gaps' don't apply to this lifecycle-complete enumeration.

Completeness

'Use for end-to-end ClawHub Convex production migrations, backfills...' explicitly answers 'when' with concrete trigger phrases, while 'created, validated, shipped, run, verified, then removed after completion' explicitly answers 'what' the skill drives. This matches anchor 5's requirement for both a clear what and an explicit when with concrete triggers; anchor 4's weaker 'when could be more explicit' does not apply.

Trigger Term Quality

Natural domain terms a user would say — "production migrations", "backfills", "destructive cleanups", "one-off maintenance functions" — are present, matching 'good keyword coverage; a few natural terms missing'. It is not a 5 because synonyms that appear in the body (e.g., 'schema narrowing', 'table reshaping', 'data migration') are absent from the description itself.

Distinctiveness Conflict Risk

The description carves out a clear niche — the end-to-end create-through-cleanup lifecycle for ClawHub Convex production changes — with distinct trigger terms and minimal overlap risk. Anchor 4's 'minor overlap risk with closely related skills' is not met: even adjacent migration-helper or release skills are distinguishable from this lifecycle-with-removal framing.