Conciseness

The body is almost entirely lean rule bullets with no padding, but two things could be trimmed: the status-code line restates HTTP knowledge Claude already has ('200 success; 201 created… 404 not found'), and the trailing 'Canonical response anchors' section is a single-item fragment ('- DELETE') that adds noise. Not 5: these minor instances of over-explanation/filler keep it off the 'every token earns its place' anchor; not 3: the body is far tighter than 'mostly efficient with some unnecessary explanation'.

Actionability

Guidance is fully concrete and directly applicable: exact sub-resource pattern ('POST /orders/:id/cancel'), exact headers ('Location', 'Retry-After', 'Deprecation: true + Sunset: <date>'), exact defaults ('Default limit: 20, max 100'), an inline pagination envelope, and copy-paste-ready examples in references/REFERENCE.md. These cover the common cases an instruction-only skill needs.

Workflow Clarity

This is a single-purpose conventions skill with no multi-step or destructive workflow, so the simple-skill exception applies: applying the rules is unambiguous, and the sections progress logically (verbs → status codes → URLs → versioning → pagination → OpenAPI → security). No validation checkpoints are needed since no fragile operation sequence exists.

Progressive Disclosure

The body is a concise overview of rules, and bulk examples (URL table, error body, pagination envelope, deprecation headers) are appropriately split into a single well-signaled reference, [URL Examples, Status Codes & Pagination Envelope](references/REFERENCE.md), which exists in the bundle and is exactly one level deep. Not 4: navigation is clean with no organization gaps of consequence.

Specificity

The description enumerates multiple concrete areas ('HTTP semantics, status codes, versioning, pagination, and OpenAPI standards') and concrete actions ('designing endpoints, choosing HTTP methods, implementing pagination, or writing OpenAPI specs'), giving comprehensive coverage of the REST design domain. Not 4: coverage spans essentially the whole domain rather than having minor gaps.

Completeness

It explicitly answers both what ('Apply REST API conventions — HTTP semantics, status codes, versioning, pagination, and OpenAPI standards for any framework') and when ('Use when designing endpoints, choosing HTTP methods, implementing pagination, or writing OpenAPI specs') with concrete trigger phrases, matching the top anchor exactly.

Trigger Term Quality

Natural phrases users would say are present ('designing endpoints', 'choosing HTTP methods', 'implementing pagination', 'writing OpenAPI specs'), but common variations like 'RESTful', 'swagger', or 'API documentation' are absent. Not 3: keyword coverage is broad and idiomatic, not partial; not 5: a few natural synonyms are missing.

Distinctiveness Conflict Risk

It occupies a clear niche (framework-agnostic REST API design conventions) with distinct triggers (endpoints, HTTP methods, pagination, OpenAPI specs), so wrong-skill triggering is unlikely. Not 4: the overlap with framework-specific routing skills is minimal given the explicit design-convention framing.