Dense and token-efficient throughout — e.g. '200 OK with {"error": "not found"} is a lie. 404 says not found.' — and it assumes Claude's knowledge (the status-code table never explains what HTTP is); every section earns its place.

Provides concrete, executable guidance: a method→status-code table, specific URL examples ('POST /users', not 'POST /createUser'), a copy-paste error-shape JSON, an idempotency-key pattern, and a ready-to-fill write-up template; absence of runnable program code is appropriate for an instruction/design skill.

A clearly sequenced 8-step process (gather contract → naming → methods/status → pagination → error shape → idempotency → versioning → review/write-up) with a one-round question gate in Step 1 and a success_criteria checklist serving as the final validation gate.

No bundle files exist and the body references only output artifacts (.gsd/DECISIONS.md) and sibling skills, not nested skill files; content is well-organized into clearly labeled semantic sections (<objective>, <context>, <core_principle>, <process>, <anti_patterns>, <success_criteria>) with no nested-reference problem.

Enumerates multiple concrete capability areas — 'versioning, pagination, error shapes, idempotency, auth, and evolvability' — matching the anchor for listing several specific actions; uses third-person voice ('Design or review').

Clearly answers both 'what' (design/review an HTTP/REST/GraphQL API for the listed concerns) and 'when' via an explicit 'Use when asked to...' clause with concrete triggers.

Quotes natural user phrases — 'design an API', 'shape the endpoints', 'design the schema', 'add a new endpoint', 'review this API' — plus 'building/modifying a public or internal HTTP surface', giving good coverage of terms users would actually say.

Explicitly carves a niche from the sibling skill — 'Complements `design-an-interface` (which is interface-agnostic) by covering HTTP-specific concerns like status codes, cache headers, and breaking-change management' — making overlap and misfires unlikely.