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.

44

Quality

44%

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 ./.agent/skills/api-design-principles/SKILL.md
SKILL.md
Quality
Evals
Security

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 is essentially a thin stub that defers all meaningful content to referenced files that aren't provided. The four instruction steps are too abstract to be actionable—they read like a table of contents rather than guidance. The skill lacks any concrete examples, code snippets, sample API designs, or validation steps that would make it useful on its own.

Suggestions

Add concrete, actionable examples for each instruction step—e.g., a sample REST resource naming convention, a sample error response schema, a sample versioning header, or a GraphQL type definition.

Include at least one complete worked example showing the progression from requirements to API design (e.g., designing a simple user management API endpoint with request/response examples).

Add validation checkpoints to the workflow—e.g., 'After step 2, verify resource naming follows conventions by checking against the naming checklist' or 'Review the error response format against the standard schema before proceeding.'

Trim the 'Use this skill when' / 'Do not use this skill when' sections to 2-3 items each, and use the saved space for substantive inline content rather than deferring everything to external files.

DimensionReasoningScore

Conciseness

The 'Use this skill when' and 'Do not use this skill when' sections are somewhat verbose and explain things Claude could infer. The core instructions (steps 1-4) are lean, but the surrounding context adds unnecessary padding. The description at the top repeats the frontmatter description.

2 / 3

Actionability

The four instruction steps are extremely vague and abstract ('Define consumers, use cases, and constraints', 'Choose API style and model resources or types'). There are no concrete examples, no code snippets, no specific commands, no sample API designs, and no executable guidance. All substantive content is deferred to a referenced file that isn't provided.

1 / 3

Workflow Clarity

The four steps are high-level and lack any validation checkpoints, feedback loops, or concrete sequencing. There's no guidance on what to check after each step, no examples of what good output looks like at each stage, and no error recovery. For a multi-step design process, this is insufficient.

1 / 3

Progressive Disclosure

The skill references `resources/implementation-playbook.md` and a sub-skill, which is a reasonable structure. However, no bundle files are provided, so we can't verify these references exist. The SKILL.md itself is almost entirely empty of substantive content, making it an over-delegating stub rather than a useful overview with well-signaled references.

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 and identifies the domain clearly. However, it leans on aspirational language ('delight developers') rather than listing concrete, specific capabilities, and the trigger terms could be broader to capture more natural user queries. The specificity of actions and distinctiveness could both be improved.

Suggestions

Replace the vague phrase 'build intuitive, scalable, and maintainable APIs that delight developers' with concrete actions like 'define resource naming, design pagination, structure error responses, plan versioning strategies'.

Expand trigger terms in the 'Use when' clause to include common variations like 'endpoints', 'OpenAPI', 'Swagger', 'API versioning', 'schema design', or 'API documentation'.

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 these are fairly high-level and don't list 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 for building intuitive, scalable, maintainable APIs) 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 relevant keywords like 'REST', 'GraphQL', 'API design', 'API specifications', and 'API design standards', but misses common user variations like 'endpoints', 'routes', 'OpenAPI', 'swagger', 'schema design', 'versioning', or 'API documentation'.

2 / 3

Distinctiveness Conflict Risk

The focus on REST and GraphQL API design is somewhat specific, but 'API design' could overlap with skills related to backend development, microservices architecture, or general software architecture. The description doesn't carve out a sufficiently narrow niche to avoid all conflicts.

2 / 3

Total

9

/

12

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

10

/

11

Passed

Repository
Dokhacgiakhoa/antigravity-ide
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.