CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

37

Quality

33%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./plugins/backend-development/skills/api-design-principles/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

0%

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 generic API design tutorial rather than an actionable skill for Claude. It is filled with concepts Claude already knows (HTTP methods, REST principles, GraphQL basics), lacks any concrete code examples or executable templates, and provides no workflow for actually designing an API. The single external reference points to a file that doesn't exist in the bundle.

Suggestions

Replace the explanatory content (HTTP methods, what REST/GraphQL are) with concrete, executable examples: e.g., a complete OpenAPI spec snippet for a well-designed endpoint, a GraphQL schema example with proper pagination and error handling.

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

Remove or create the referenced 'references/details.md' file, and ensure any cross-references point to actual bundle files with substantive content.

Cut at least 60% of the content that restates common knowledge (HTTP method semantics, 'use plural nouns', 'APIs without limits are vulnerable') and replace with project-specific patterns, decision frameworks, or copy-paste-ready templates.

DimensionReasoningScore

Conciseness

The content is verbose and explains many concepts Claude already knows well—HTTP method semantics, what REST resources are, what GraphQL queries/mutations/subscriptions do, basic best practices like 'use HTTP status codes correctly,' and common pitfalls that are general knowledge. The 'When to Use This Skill' section is also padded. Very little here adds novel, actionable knowledge.

1 / 3

Actionability

The skill provides abstract descriptions and general advice rather than concrete, executable guidance. There are no real code examples, no API design templates, no executable commands, and no specific patterns to follow. Statements like 'Use plural nouns for collections' and 'Always paginate large collections' are vague directions without showing how.

1 / 3

Workflow Clarity

There is no clear multi-step workflow for designing an API. The content is organized as a reference list of principles and best practices without any sequenced process, validation checkpoints, or decision points that would guide Claude through an actual API design task.

1 / 3

Progressive Disclosure

The skill references 'references/details.md' for detailed patterns, but no bundle files are provided, making this a dead reference. The main content is a monolithic wall of general knowledge with no meaningful structure separating overview from detail. The reference to a non-existent file is worse than having no reference at all.

1 / 3

Total

4

/

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 vague aspirational language ('intuitive, scalable, maintainable', 'delight developers') instead of listing concrete actions, and it misses many natural trigger terms users would employ when seeking API design help. The specificity of capabilities could be significantly improved.

Suggestions

Replace vague aspirational language ('intuitive, scalable, maintainable APIs that delight developers') with concrete actions like 'define resource naming conventions, design pagination and filtering, structure error responses, plan versioning strategies'.

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

DimensionReasoningScore

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', 'HTTP methods', or 'request/response format'.

2 / 3

Distinctiveness Conflict Risk

The focus on API design principles for REST and GraphQL provides some distinctiveness, but 'designing new APIs' and 'reviewing API specifications' could overlap with general coding skills, backend development skills, or documentation skills. The phrase 'delight developers' is fluffy and doesn't help differentiation.

2 / 3

Total

9

/

12

Passed

Validation

100%

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

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
wshobson/agents
Reviewed

Table of Contents

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.