Conciseness

The body is dense with non-obvious, verified specifics, but the opening paragraph is rhetorical framing ("A green typecheck proves the code parses... the loop the whole field is missing") that re-motivates what the Rules already state, and Rules bullets 1–3 and 5–6 substantially restate Workflow steps 3–7 (seed both users' rows, drive multiple identities, never weaken an assertion, vitest config required). It could be tightened by roughly a third without losing any instruction.

Actionability

Mostly executable guidance with concrete inline snippets: `test.environment: "edge-runtime"` with `server.deps.inline: ["convex-test"]`, `t.withIdentity({ subject, tokenIdentifier, ... })`, `expect(...).rejects.toThrow(/forbidden|not authorized|403/)`, `t.run(async (ctx) => ctx.db.insert(...))`, and `npx vitest run`. Minor gaps: the vitest.config.ts is described in prose rather than shown as a complete file, and snippets use ellipses/placeholders rather than being copy-paste ready.

Workflow Clarity

The 7-step sequence (IDENTIFY → SET UP → SEED → DRIVE → ASSERT → RUN → handoff) is clearly ordered with an explicit validation step ("RUN the tests (`npx vitest run`) and report: what was proven... and — critically — any assertion that FAILED") and a genuine error-recovery feedback path (step 7: a failing negative test is a real defect — do not weaken the assertion, hand the fix to convex-authz, emit a bus finding). The `import.meta.glob is not a function` failure mode is pre-documented so setup errors are recoverable.

Progressive Disclosure

The body is well organized into Workflow and Rules sections and, at ~35 lines for a single-purpose skill, needs no external files — but it points to artifacts outside any bundle: "specs/finding.schema.json", the `test` and `convex-authz` capabilities, and a generated-from path in the HTML comment. None of these exist in the skill's directory, so the references cannot actually be navigated.

Specificity

It lists multiple concrete actions covering the capability's whole loop: "seed, drive as multiple mocked users via convex-test, assert behavior including the negative authz cases (wrong user refused, data-scope enforced)" — seeding, multi-identity driving, positive and negative assertion behavior are all named specifically. Not a 4: nothing significant in the capability's action set is left unspecified.

Completeness

The "what" is explicit and concrete ("seed, drive as multiple mocked users via convex-test, assert behavior including the negative authz cases"), and there is a "when" cue in "Prove a Convex feature works — ... the user just built" framing — but only via implication rather than an explicit clause. "when could be more explicit or specific" fits better than either the explicit-clause anchor (5) or the weakly-implied one (3).

Trigger Term Quality

Good domain keyword coverage — "Convex feature", "convex-test", "seed", "authz", "wrong user refused", "data-scope" — but it lacks the natural synonyms a user would most often say, such as "test", "verify", or "e2e", relying instead on the less colloquial "Prove... works". Not a 5: common phrasings of the request would not lexically match.

Distinctiveness Conflict Risk

The niche is clear (Convex, convex-test, negative authz cases) and would rarely collide with unrelated skills, but the generic head "Prove a feature works" overlaps a general test/verify skill for any non-Convex framework request — the body itself acknowledges this boundary with the `test` capability, yet the description does not. Mostly distinct with minor overlap risk against a closely related skill.