CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

Quality

60%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

46%Weight 40%Scale 1-5

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

The body is well-structured and token-efficient with sensible use/don't-use scoping, but it provides no concrete design guidance and its progressive disclosure is broken: it points twice to a nonexistent playbook while leaving four relevant bundle files completely unreferenced. Claude loading this skill would hit a dead end on the only reference and never find the real detailed material.

Suggestions

Replace both broken `resources/implementation-playbook.md` references with pointers to the actual bundle files, e.g. 'REST patterns: see references/rest-best-practices.md; GraphQL schemas: see references/graphql-schema-design.md; pre-implementation review: use assets/api-design-checklist.md'.

Add concrete inline guidance instead of four abstract directives — e.g., plural-noun resource naming, a concrete error-response format, and a versioning/pagination pattern — so the skill is actionable even before opening references.

Turn step 4 into a real validation checkpoint, e.g. 'Run the checklist in assets/api-design-checklist.md against the spec and fix flagged gaps before finalizing'.

DimensionReasoningScore

Conciseness

The body is lean (~45 lines) with terse directives ('Define consumers, use cases, and constraints') and no explanations of concepts Claude already knows. Minor trimmable redundancy keeps it below a 5: the tagline 'delight developers and stand the test of time' repeats the frontmatter verbatim, and the same `resources/implementation-playbook.md` pointer appears twice (in Instructions and again in Resources).

4 / 5

Actionability

The instructions are high-level hints ('Choose API style and model resources or types', 'Specify errors, versioning, pagination, and auth strategy') with no concrete patterns, naming rules, or examples, and the promised 'detailed patterns, checklists, and templates' live in `resources/implementation-playbook.md`, which does not exist in the bundle. This matches anchor 2 ('high-level hints but missing the specific steps to execute') rather than 3, because nothing concrete is provided even at pseudocode level and the deferred detail is inaccessible.

2 / 5

Workflow Clarity

Four steps are listed in a clear sequence ('1. Define consumers... 4. Validate with examples and review for consistency'), so a sequence exists, but the validation step is a vague instruction with no checkpoint or feedback loop and no step carries executable specifics. This matches anchor 3 ('sequence present but checkpoints missing or implicit'), not 4, which requires concrete commands and mostly explicit checkpoints.

3 / 5

Progressive Disclosure

Scored against the actual bundle: the only referenced file, `resources/implementation-playbook.md`, does not exist (there is no resources/ directory), while all four real bundle files (references/rest-best-practices.md, references/graphql-schema-design.md, assets/api-design-checklist.md, assets/rest-api-template.py) are never mentioned in the body. This matches anchor 2 ('references are buried'/minimal effective cross-file structure) rather than 3, because the one reference present is broken and the actual detailed content is undiscoverable, not merely unclearly signaled; not 1 because the body itself is well-sectioned with one-level references and no nested chains.

2 / 5

Total

11

/

20

Passed

Description

56%Weight 40%Scale 1-5

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 names its domain and includes the core natural keywords (REST, GraphQL, API design), but it leans on aspirational marketing language and omits both concrete capabilities and any use-when trigger clause. It is serviceable but clearly below the good-example bar, which pairs concrete actions with explicit trigger phrases.

Suggestions

Add an explicit trigger clause, e.g. 'Use when designing or refactoring REST/GraphQL APIs, reviewing API specs, or setting team API design standards.'

Replace aspirational language with concrete capabilities, e.g. 'Design REST resources and GraphQL schemas; define error contracts, versioning, pagination, and auth strategies.'

Cut the marketing fluff ('delight developers and stand the test of time') — it adds tokens without trigger or informative value.

DimensionReasoningScore

Specificity

The phrase 'Master REST and GraphQL API design principles' names the domain, but the rest is goal language ('build intuitive, scalable, and maintainable APIs that delight developers') with no concrete action ever stated — no 'design endpoints', 'define error contracts', or 'version APIs'. This matches anchor 2 ('names the domain but actions are minimal or generic'), not 3, because no concrete verb+object capability is listed.

2 / 5

Completeness

The 'what' is stated ('Master REST and GraphQL API design principles to build... APIs') but the 'when' is entirely absent — there is no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. This matches anchor 3 ('clear what but when is missing'), not 4, because the when-clause is missing altogether rather than merely under-specified.

3 / 5

Trigger Term Quality

Natural trigger keywords are present: 'REST', 'GraphQL', 'API design', 'APIs' — terms users would genuinely say when needing this skill, comparable to anchor 4's 'PDF files, forms, document extraction'. Not 5 because common variations and synonyms are missing: 'endpoints', 'OpenAPI', 'API versioning', 'schema design', 'API documentation'.

4 / 5

Distinctiveness Conflict Risk

'REST and GraphQL API design' carves a mostly distinct niche, comparable to anchor 4's 'Works with PDF and Word document files', with only minor overlap risk against framework-implementation or API-documentation skills. Not 5 because without explicit trigger phrases it could still fire for adjacent API requests (e.g., debugging an existing endpoint or writing API docs).

4 / 5

Total

13

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

Total

15

/

16

Passed

Repository

sickn33/agentic-awesome-skills

Path

skills/api-design-principles/SKILL.md

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.