CtrlK
BlogDocsLog inGet started
Tessl Logo

jbvc/api-design

REST API design patterns including resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting for production APIs.

60

Quality

75%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

Quality

Content

57%

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

This is a thorough and highly actionable API design reference with excellent concrete examples across multiple languages and frameworks. Its main weaknesses are its monolithic structure (no progressive disclosure or supporting files) and verbosity—three full language implementations and some sections covering knowledge Claude already possesses inflate the token cost significantly. Adding validation checkpoints to the workflow (e.g., testing endpoints, validating OpenAPI specs) would also strengthen it.

Suggestions

Split implementation patterns (TypeScript, Python, Go) into a separate IMPLEMENTATIONS.md file and keep only one brief example inline, reducing the main file by ~40%.

Extract the detailed pagination, filtering, and rate limiting sections into a separate REFERENCE.md, leaving concise summaries with links in the main SKILL.md.

Add explicit validation steps to the checklist or workflow, such as 'Test endpoint with curl and verify response matches standard format' or 'Run OpenAPI spec validation before merging'.

Remove or condense sections that explain concepts Claude already knows well, such as the HTTP method semantics table and basic auth header format.

DimensionReasoningScore

Conciseness

The skill is comprehensive but overly long (~350+ lines). Some sections like the method semantics table and auth patterns explain things Claude already knows well. The three full implementation examples (TypeScript, Python, Go) are verbose when one would suffice with a note about language adaptation. However, most content is structured as reference tables and code blocks rather than prose, which helps.

2 / 3

Actionability

Highly actionable with concrete, executable code examples across multiple languages, specific URL patterns, exact status codes with usage context, complete JSON response schemas, and a ready-to-use checklist. The implementation patterns show real framework-specific code (Zod validation, DRF serializers, Go handlers) that is copy-paste ready.

3 / 3

Workflow Clarity

The checklist at the end provides a good sequence for endpoint design review, and the versioning strategy has a clear numbered process. However, there are no explicit validation checkpoints or feedback loops for the API design process itself—e.g., no step to validate OpenAPI spec, test with curl, or verify response format matches the standard before shipping.

2 / 3

Progressive Disclosure

This is a monolithic wall of content with no references to supporting files. The implementation patterns for three languages, detailed pagination strategies, auth patterns, and rate limiting tiers could all be split into separate reference files. Everything is inline in one large document with no navigation aids beyond section headers.

1 / 3

Total

8

/

12

Passed

Description

82%

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 excels at specificity and trigger term coverage, listing seven concrete REST API design topics that align well with natural developer language. Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know precisely when to select this skill over others. Adding trigger guidance would elevate this from a good to excellent description.

Suggestions

Add a 'Use when...' clause such as 'Use when the user asks about designing REST APIs, choosing HTTP status codes, implementing pagination, or structuring API error responses.'

Consider mentioning file types or output formats if applicable (e.g., OpenAPI specs, Swagger) to further distinguish from general backend development skills.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions/topics: resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting. These are all concrete, well-defined aspects of REST API design.

3 / 3

Completeness

Clearly answers 'what does this do' with the list of REST API design patterns, but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the topic listing.

2 / 3

Trigger Term Quality

Includes strong natural keywords users would say: 'REST API', 'resource naming', 'status codes', 'pagination', 'filtering', 'error responses', 'versioning', 'rate limiting'. These are terms developers naturally use when asking about API design.

3 / 3

Distinctiveness Conflict Risk

Clearly scoped to REST API design patterns specifically, with distinct triggers like 'resource naming', 'status codes', 'pagination', and 'rate limiting' that are unlikely to conflict with other skills. The 'production APIs' qualifier further narrows the niche.

3 / 3

Total

11

/

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

skill_md_line_count

SKILL.md is long (523 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Reviewed

Table of Contents