The body is terse and list-based rather than verbose, but it re-explains concepts Claude already knows (HTTP method semantics like 'GET: idempotent, safe', 'resources are nouns not verbs', and GraphQL query/mutation/subscription basics). Not a 3 because those well-known basics do not earn their tokens; not a 1 because the presentation is lean bullet form rather than padded prose.

It mixes concrete actionable guidance ('Use plural nouns for collections (`/users`, not `/user`)', 'Use cursor-based pagination (Relay spec)', 'Use @deprecated directive', versioning URL/header examples) with vague platitudes ('Protect your API with rate limits', 'Plan for breaking changes from day one', 'Documentation: Use OpenAPI/Swagger'). Not a 3 because much of it is descriptive rather than copy-paste-ready instruction; not a 1 because several items are specific and applicable.

The content is organized by topic (When to Use, Core Concepts, Versioning, Best Practices, Pitfalls) but there is no sequenced multi-step design workflow and no validation checkpoints or feedback loops. Not a 3 because there are no explicit validation/error-recovery steps; not a 1 because the structure is clear and organized rather than unclear or missing, and no destructive batch workflow requires a cap.

The body clearly signals one one-level-deep reference ('Detailed pattern documentation lives in references/details.md'), but it does not surface the other four bundle files (references/graphql-schema-design.md, references/rest-best-practices.md, assets/api-design-checklist.md, assets/rest-api-template.py). Not a 3 because navigation to most bundle materials is missing; not a 1 because the one signaled reference is well-structured and not deeply nested.

It names the domain ('REST and GraphQL API design') and three actions ('designing new APIs', 'reviewing API specifications', 'establishing API design standards'), but these are high-level categories rather than granular concrete actions, and 'intuitive, scalable, and maintainable APIs that delight developers' is buzzword padding. Not a 3 because the actions are abstract platitudes rather than specific concrete operations like the 'extract text, fill forms, merge documents' anchor; not a 1 because the domain and several actions are explicitly named.

It explicitly answers both what ('Master REST and GraphQL API design principles to build... APIs') and when via an explicit 'Use when designing new APIs, reviewing API specifications, or establishing API design standards' trigger clause. Not a 2 because the 'when' is explicit rather than missing or implied, matching the 'Use when... PDFs, forms, or document extraction' anchor.

It includes relevant natural terms ('REST', 'GraphQL', 'API design', 'API specifications', 'API design standards') that users would say, but coverage is limited to a few phrases and omits common variations such as 'endpoints', 'API schema', 'REST vs GraphQL', or 'API documentation'. Not a 3 because it does not give good coverage of natural term variations; not a 1 because the terms present are natural rather than jargon.

REST and GraphQL API design/review/standards is a clear, specific niche with distinct triggers unlikely to conflict with unrelated skills. Not a 2 because it is more specific than 'Works with document files'-style overlap; the scoped REST/GraphQL API-design framing keeps it distinct.