api-design-principles

Master REST and GraphQL API design principles to build intuitive, scalable, and maintainable APIs that delight developers. Use when designing new APIs, reviewing API specifications, or establishing API design standards.

1.03x

Quality

44%

Does it follow best practices?

Impact

91%

1.03x

Average score across 3 eval scenarios

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./data/02-architect-apidesign/SKILL.md

Quality

Content

22%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill reads like a textbook chapter on API design rather than a focused, actionable skill for Claude. It is excessively verbose, explaining fundamental concepts Claude already knows (HTTP methods, REST principles, what GraphQL is), while lacking a clear workflow for actually designing an API. The code examples are illustrative but not fully executable, and the referenced bundle files don't exist.

Suggestions

Cut the content by 60-70%: remove explanations of basic REST/GraphQL concepts, HTTP method semantics, and generic best practices that Claude already knows. Focus only on project-specific conventions and non-obvious patterns.

Add a clear step-by-step workflow for API design (e.g., 1. Gather requirements → 2. Define resources → 3. Design schema → 4. Validate against checklist → 5. Generate OpenAPI spec) with explicit validation checkpoints.

Make code examples fully executable or remove helper function dependencies — currently functions like build_query(), fetch_users(), count_users() are undefined, making examples non-runnable.

Either create the referenced bundle files (rest-best-practices.md, graphql-schema-design.md, etc.) or remove the references. Move the detailed patterns into those files and keep SKILL.md as a concise overview.

Dimension	Reasoning	Score
Conciseness	Extremely verbose at ~400+ lines. Explains basic concepts Claude already knows well (REST methods, what resources are, HTTP status codes, what GraphQL is). The 'When to Use This Skill' section lists 7 obvious use cases. Best practices and common pitfalls sections are generic knowledge that adds no novel value. Much of this is textbook content.	1 / 3
Actionability	Code examples are relatively concrete and use real frameworks (FastAPI, Ariadne), but many rely on undefined helper functions (build_query, fetch_users, count_users, etc.) making them not truly executable. The skill describes patterns rather than giving step-by-step instructions for a specific task. It reads more like a reference guide than actionable instructions.	2 / 3
Workflow Clarity	There is no clear workflow or sequenced process for designing an API. The content presents patterns and best practices but never guides through a design process with validation checkpoints. The 'Interactive Design Process' section mentions clarifying requirements and feedback loops but provides no concrete steps or validation criteria.	1 / 3
Progressive Disclosure	References to external files (references/, assets/, scripts/) are listed in the Resources section, but none of these bundle files actually exist. The main content is a monolithic wall of patterns and examples that could benefit from being split into separate files. The references section is well-structured but points to non-existent files.	2 / 3
	Total	6 / 12 Passed

Description

67%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has a solid structure with an explicit 'Use when...' clause that covers key scenarios, which is its main strength. However, it relies on aspirational buzzwords ('intuitive, scalable, maintainable, delight developers') instead of listing concrete capabilities, and it misses many natural trigger terms users would use when seeking API design help. The specificity of actions could be significantly improved.

Suggestions

Replace vague aspirational language ('intuitive, scalable, maintainable APIs that delight developers') with concrete actions like 'define resource naming, design pagination, structure error responses, plan versioning strategies, write OpenAPI/GraphQL schemas'.

Add more natural trigger terms users would say, such as 'endpoints', 'OpenAPI', 'Swagger', 'API versioning', 'schema design', 'request/response format', '.yaml spec'.

Sharpen distinctiveness by clarifying this is specifically about API design patterns and conventions rather than implementation, to avoid overlap with general backend development skills.

Dimension	Reasoning	Score
Specificity	Names the domain (REST and GraphQL API design) and mentions some actions ('designing new APIs, reviewing API specifications, establishing API design standards'), but the core description uses vague aspirational language ('intuitive, scalable, and maintainable APIs that delight developers') rather than listing concrete specific actions like 'define resource naming conventions, design pagination schemes, structure error responses'.	2 / 3
Completeness	Clearly answers both 'what' (REST and GraphQL API design principles) and 'when' with an explicit 'Use when...' clause covering three trigger scenarios: designing new APIs, reviewing API specifications, or establishing API design standards.	3 / 3
Trigger Term Quality	Includes some relevant keywords like 'REST', 'GraphQL', 'API design', 'API specifications', and 'API design standards', but misses common natural variations users might say such as 'endpoints', 'routes', 'OpenAPI', 'Swagger', 'schema design', 'API versioning', 'request/response format', or 'API documentation'.	2 / 3
Distinctiveness Conflict Risk	The focus on REST and GraphQL API design is somewhat specific, but 'designing new APIs' and 'reviewing API specifications' could overlap with general coding skills, backend development skills, or architecture skills. The phrase 'delight developers' is fluffy and doesn't help distinguish it.	2 / 3
	Total	9 / 12 Passed

Validation

90%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 10 / 11 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (534 lines); consider splitting into references/ and linking	Warning

	Total	10 / 11 Passed

Repository: majiayu000/claude-skill-registry-data
Commit: 267bf8e

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.