Conciseness

The core material (Hyrum's Law implications, idempotency key handling, rationalizations table) is dense and high-value, but sections like 'REST API Patterns' (resource URLs, pagination shape, camelCase query params) and 'TypeScript Interface Patterns' (discriminated unions, branded types, input/output separation) restate concepts Claude already knows at length. This matches anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened') — the known-material sections pad the token budget without adding much.

Actionability

Guidance is largely concrete and executable: typed interface definitions, a status-code mapping, boundary validation code with Zod-safeParse, atomic idempotency-key claiming via unique constraint, a payload-hash guard, and a decision table for in-flight duplicates. It falls short of anchor 5 only in minor gaps — some snippets are illustrative fragments (e.g., `replayOrReject(key)` and `hash(req.body)` are referenced but never defined), fitting anchor 4 ('mostly executable guidance... with minor gaps').

Workflow Clarity

The design process is well sequenced: numbered core principles (contract first → error semantics → boundary validation → additive evolution → naming → idempotency), followed by a 'Verification' section with a 12-item checklist that functions as explicit validation checkpoints, plus 'Red Flags' for error recognition. Anchor 5 would require feedback loops for error recovery during execution; the checklist verifies a design but offers no 'if this fails, do X' loop, so anchor 4 is the best fit.

Progressive Disclosure

The file is well-sectioned and easy to navigate internally, but it is a ~365-line monolith with no bundle files at all, and substantial deep-dive content (the full idempotency implementation guide, the TypeScript patterns section) is inlined where anchor 5 expects it split into clearly signaled one-level-deep references. It also contains a dangling reference — 'See `deprecation-and-migration`' points to no file in this bundle — matching anchor 3 ('some structure but could be better organized... content that should be separate is inline') rather than anchor 2, since section organization within the file is good.

Specificity

The description names the domain ('API and interface design') with one action ('Guides stable API and interface design') but never lists concrete capabilities like 'define contracts', 'design error semantics', or 'apply naming conventions'. This matches anchor 3 ('names domain and 1-2 concrete actions, but not comprehensive') and falls short of anchor 4, which expects several specific actions listed.

Completeness

Both 'what' ('Guides stable API and interface design') and 'when' (two explicit 'Use when...' clauses with concrete triggers) are present, and the 'when' is highly explicit. The 'what' is thinner than anchor 5 expects — a single generic verb ('Guides') rather than enumerating capabilities — so it sits between anchors 4 and 5, closer to 4.

Trigger Term Quality

Natural trigger terms are well covered: 'designing APIs', 'module boundaries', 'public interface', 'REST or GraphQL endpoints', 'type contracts', 'boundaries between frontend and backend'. Good coverage but a few natural variations users might say are missing (e.g., 'endpoints', 'SDK design', 'schema design'), fitting anchor 4 rather than the comprehensive synonym coverage of anchor 5.

Distinctiveness Conflict Risk

The API/interface design niche is clear with specific triggers (REST/GraphQL endpoints, module boundaries, type contracts) that are unlikely to fire for unrelated skills. However, the broad catch-all 'or any public interface' creates minor overlap risk with closely related skills (component props, database schema design), matching anchor 4 rather than the minimal conflict of anchor 5.