CtrlK
BlogDocsLog inGet started
Tessl Logo

api-design

Guides RESTful API endpoint design, resource naming, status code selection, pagination structure, versioning strategy, and error response schemas. Use when the user asks about designing APIs, defining HTTP endpoints, REST conventions, API versioning, request/response formats, URL structure, OpenAPI/Swagger specs, or reviewing an existing API contract for best practices.

75

Quality

94%

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

SKILL.md
Quality
Evals
Security

Quality

Content

85%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.

A concise, well-organized reference that is strong on naming conventions, status-code selection, and versioning, and it respects token budget admirably. Its weakness is actionability: the Pagination and Error responses sections state goals ('Return a structured response', 'Include enough info for the client to act on') without any concrete structure or example, leaving the reader to invent the schema.

Suggestions

Add a concrete pagination envelope to the Pagination section, e.g. `{ "data": [...], "next_cursor": "..." }` with a note on cursor vs. offset, so 'Return a structured response' becomes executable guidance.

Show an explicit error response schema in the Error responses section, e.g. `{ "error": { "code": "string", "message": "string", "field": "optional" } }`, so clients know exactly what shape to expect.

Illustrate the Versioning choice with one concrete example of each option (e.g. `GET /v1/users` vs `Accept: application/vnd.api+json;version=1`) to remove the remaining ambiguity about what each looks like.

DimensionReasoningScore

Conciseness

The body is lean and prescriptive throughout — e.g., "Pick the right code. Don't return 200 with an error body." and "Use kebab-case for multi-word path segments (`/access-tokens`, not `/access_tokens` or `/accessTokens`)" — with no padding and no explanation of concepts Claude already knows. Every token earns its place, matching the score-5 anchor.

5 / 5

Actionability

Resources/naming, status codes, kebab-case, and versioning give concrete, copy-ready guidance, but "For list endpoints, paginate. Return a structured response." and "Errors should be useful. Include enough info for the client to act on." are abstract with no fields, envelope shape, or example schema. Two of six sections lack the key details needed to execute, matching the score-3 anchor ('some concrete guidance but incomplete'); it is not 4 because these gaps are entire sections rather than minor ones.

3 / 5

Workflow Clarity

This is a single-purpose reference skill (under 50 lines, no multi-step process) whose sections follow a logical order (naming → status codes → pagination → versioning → errors), and it involves no destructive or batch operations that would require validation checkpoints. Per the rubric's simple-skill exception, the unambiguous single action warrants a 5.

5 / 5

Progressive Disclosure

The body is under 50 lines with well-organized section headers and no need for external references — no references/, scripts/, or assets/ bundle files exist and none are cited. Per the rubric guideline for short skills needing no external files, well-organized sections alone merit a 5.

5 / 5

Total

18

/

20

Passed

Description

100%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.

An exemplary skill description: it names concrete capabilities comprehensively, uses third-person voice, and pairs an explicit 'what' with an explicit 'Use when...' clause rich in natural trigger terms and synonyms. Conflict risk with unrelated skills is minimal.

DimensionReasoningScore

Specificity

"Guides RESTful API endpoint design, resource naming, status code selection, pagination structure, versioning strategy, and error response schemas" enumerates six concrete capability areas with comprehensive coverage of the API-design domain, in third-person voice. This matches the score-5 anchor (multiple specific concrete actions, comprehensive) rather than 4, which is reserved for lists with minor coverage gaps.

5 / 5

Completeness

The first sentence explicitly answers 'what' (six concrete capabilities) and "Use when the user asks about designing APIs, defining HTTP endpoints... or reviewing an existing API contract for best practices" explicitly answers 'when' with concrete trigger phrases. This matches the score-5 anchor exactly.

5 / 5

Trigger Term Quality

"designing APIs, defining HTTP endpoints, REST conventions, API versioning, request/response formats, URL structure, OpenAPI/Swagger specs" covers the natural phrases users would say, including synonyms (OpenAPI/Swagger). Coverage is comprehensive for this domain, fitting the score-5 anchor rather than 4 ('a few natural terms missing').

5 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche (REST API design) with distinct triggers such as "OpenAPI/Swagger specs", "status code selection", and "API contract", posing minimal conflict risk with other skills. The score-5 anchor (clear niche with distinct triggers) fits; nothing in the triggers is generic enough to pull it to 4.

5 / 5

Total

20

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
fernandezbaptiste/skill-review-sandbox
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.