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 and stand the test of time.

34

Quality

18%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/antigravity-api-design-principles/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Discovery

22%

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

This description reads more like a marketing tagline or course title than a functional skill description. It lacks concrete actions, explicit trigger conditions, and uses aspirational fluff ('delight developers', 'stand the test of time') instead of specifying what the skill actually does. The mention of REST and GraphQL provides some keyword value but is insufficient to make this a useful skill selector.

Suggestions

Replace aspirational language with concrete actions, e.g., 'Designs REST endpoints, defines GraphQL schemas, structures request/response payloads, applies versioning strategies, and generates OpenAPI/Swagger specifications.'

Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks about API design, REST endpoints, GraphQL schemas, HTTP methods, API versioning, or OpenAPI specs.'

Remove marketing fluff like 'delight developers' and 'stand the test of time' — these add no selection value and reduce clarity.

DimensionReasoningScore

Specificity

The description uses vague, aspirational language like 'intuitive, scalable, and maintainable' and 'delight developers' without listing any concrete actions. There are no specific capabilities such as 'design endpoints', 'define schemas', 'generate OpenAPI specs', etc.

1 / 3

Completeness

The description vaguely addresses 'what' (API design principles) but provides no 'when' clause or explicit trigger guidance. There is no 'Use when...' or equivalent, which per the rubric should cap completeness at 2, and the 'what' itself is too vague to merit even a 2.

1 / 3

Trigger Term Quality

It includes some relevant keywords like 'REST', 'GraphQL', and 'API design' that users might naturally say. However, it misses common variations like 'endpoints', 'routes', 'schema', 'OpenAPI', 'swagger', 'HTTP methods', or 'API documentation'.

2 / 3

Distinctiveness Conflict Risk

Mentioning both REST and GraphQL provides some specificity, but the broad framing around 'API design principles' could overlap with skills related to backend development, web services, or general software architecture.

2 / 3

Total

6

/

12

Passed

Implementation

14%

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 placeholder that defers all actionable content to a referenced file (`resources/implementation-playbook.md`) that does not exist in the bundle. The body itself provides only vague, abstract guidance with no concrete examples, patterns, code, or specific API design rules. It fails to deliver value as a standalone skill document.

Suggestions

Add concrete, actionable API design patterns directly in the SKILL.md — e.g., specific REST resource naming conventions, HTTP method usage, status code mappings, GraphQL schema design examples with actual code/schema snippets.

Include at least one worked example showing input (API requirements) and output (resulting API design specification) so Claude knows exactly what to produce.

Either provide the referenced `resources/implementation-playbook.md` bundle file or inline the essential content from it into the skill body.

Replace the four abstract instruction steps with a concrete workflow that includes validation checkpoints — e.g., 'Draft OpenAPI spec → validate with linter → review naming consistency → finalize versioning strategy.'

DimensionReasoningScore

Conciseness

The 'Use this skill when' and 'Do not use this skill when' sections are somewhat verbose and explain things Claude can infer. The Limitations section is boilerplate. However, the core instructions are brief.

2 / 3

Actionability

The instructions are extremely vague and abstract — 'Define consumers, use cases, and constraints' and 'Choose API style and model resources or types' provide no concrete guidance, no code examples, no specific patterns, no schemas, and no executable steps. Everything actionable is deferred to a referenced file that doesn't exist in the bundle.

1 / 3

Workflow Clarity

The four numbered steps are high-level abstractions without any specifics, validation checkpoints, or feedback loops. There is no concrete sequence a practitioner could follow — it reads more like a table of contents than a workflow.

1 / 3

Progressive Disclosure

The skill references `resources/implementation-playbook.md` for all substantive content, but no bundle files are provided, meaning the reference leads nowhere. The SKILL.md itself contains almost no useful content, making it an empty shell pointing to a nonexistent resource.

1 / 3

Total

5

/

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
boisenoise/skills-collections
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.