Content
32%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a monolithic reference document: long, redundant with basics Claude already knows (HTTP semantics, status codes, REST/GraphQL fundamentals), dependent on undefined helper functions, and structured as reference material rather than an actionable design workflow. Its progressive disclosure is inverted — detail that belongs in the seven referenced bundle files is inlined, and none of those files actually exist.
Suggestions
Create the seven referenced bundle files (references/rest-best-practices.md, references/graphql-schema-design.md, references/api-versioning-strategies.md, assets/rest-api-template.py, assets/graphql-schema-template.graphql, assets/api-design-checklist.md, scripts/openapi-generator.py) and move the full pattern implementations and complete GraphQL schema into them, leaving a compact overview plus one-line pointers in SKILL.md.
Delete the sections explaining what Claude already knows — HTTP method semantics, the status-code table, 'resources are nouns not verbs' — and keep only project-specific conventions, decisions, and edge cases.
Add a sequenced design workflow with validation checkpoints (clarify requirements → draft resource/schema model → run the pre-implementation checklist → present design for review), and make the undefined helpers in code examples either concrete or explicitly marked as project hooks.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~530-line body extensively explains concepts Claude already knows: HTTP method semantics ('GET: Retrieve resources (idempotent, safe)'), 'Resources are nouns (users, orders, products), not verbs', a status-code dictionary (200/404/500), and 'Queries for reading data, Mutations for modifying data'. Content is also repeated across Core Concepts, Best Practices, and Common Pitfalls (pagination, versioning, and error handling each appear three times), matching the anchor 'Noticeably verbose; several unnecessary explanations or padded sections'. | 2 / 5 |
Actionability | The code is real Python/GraphQL rather than pseudocode (Pydantic pagination models, a FastAPI endpoint, DataLoader classes, a full GraphQL schema), but nearly every snippet depends on undefined helpers (fetch_users, count_users, build_query, encode_cursor/decode_cursor, hash_password, validate_user_input) and some snippets miss imports (Any, List) or an app definition. That matches 'Some concrete guidance but incomplete... missing key details' rather than the level-4 'minor gaps' anchor, since the gaps are pervasive rather than minor. | 3 / 5 |
Workflow Clarity | There is no sequenced design process: the 'Interactive Design Process' section is two unordered bullets, and the rest is reference-style material with no step sequence and no validation checkpoints. The referenced pre-implementation checklist (assets/api-design-checklist.md) does not exist, so no checkpoint exists anywhere. This fits the anchor 'Rough sequence present but many gaps; steps poorly defined; validation absent' and is below the level-3 anchor, which requires steps actually listed. | 2 / 5 |
Progressive Disclosure | The body inlines roughly 500 lines of full pattern implementations and a complete GraphQL schema — content the skill itself says belongs in references/assets — while all 7 files listed in the Resources section (references/rest-best-practices.md, assets/rest-api-template.py, scripts/openapi-generator.py, etc.) do not exist, making every reference broken. Section headers exist so it is not a structureless wall, but it squarely matches 'content that clearly belongs in separate files is inlined' with broken navigation on top. | 2 / 5 |
Total | 9 / 20 Passed |