CtrlK
BlogDocsLog inGet started
Tessl Logo

tdg-personal/api-design

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

56

Quality

71%

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 API design reference with excellent actionability—concrete examples, good/bad comparisons, and executable code. However, it suffers from being too long and monolithic; it tries to be a complete API design handbook in a single file. The content would benefit significantly from splitting into focused sub-files and trimming redundant implementation examples and concepts Claude already knows.

Suggestions

Split implementation examples (TypeScript, Python, Go) into a separate IMPLEMENTATIONS.md file and keep only one brief example inline, or remove them entirely since Claude can generate framework-specific code from the patterns alone.

Remove the 'When to Activate' section and the HTTP methods semantics table—Claude already knows when to apply API design patterns and what HTTP methods mean.

Extract detailed sections (pagination deep-dive, filtering/sorting, rate limiting, versioning) into separate reference files and link to them from a concise overview in SKILL.md.

Add a brief workflow with validation steps for the API design process, e.g., 'Design → validate against checklist → review naming consistency → document in OpenAPI spec → verify error responses match format.'

DimensionReasoningScore

Conciseness

The skill is comprehensive but overly long (~350+ lines). Several sections explain things Claude already knows well (HTTP method semantics table, what status codes mean, basic auth patterns). The three full implementation examples in TypeScript, Python, and Go are redundant—one would suffice with a note to adapt. The 'When to Activate' section is unnecessary filler.

2 / 3

Actionability

The skill provides fully concrete, executable code examples across multiple languages, specific URL patterns with good/bad comparisons, exact status codes, complete JSON response schemas, and real query parameter syntax. Everything is copy-paste ready and specific.

3 / 3

Workflow Clarity

The checklist at the end provides a good sequence for API design review, but there are no explicit validation checkpoints or feedback loops. For a design patterns skill (not a destructive operation), this is less critical, but the versioning strategy section lists steps without clear validation gates. The skill reads more as a reference than a workflow.

2 / 3

Progressive Disclosure

This is a monolithic wall of text with no references to supporting files. The implementation examples in three languages, pagination deep-dives, auth patterns, and rate limiting details could all be split into separate reference files. Everything is inline in one massive document with no navigation structure beyond headers.

1 / 3

Total

8

/

12

Passed

Description

75%

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 listing specific, concrete capabilities with strong natural trigger terms that developers would use. Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude distinguish when to select this skill versus other potentially overlapping API or backend development skills.

Suggestions

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

Add boundary clarification to reduce overlap, e.g., 'Not for GraphQL APIs, WebSocket protocols, or API client/SDK implementation.'

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions/topics: resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting. These are clearly defined, actionable areas 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, which caps this dimension at 2 per the rubric.

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

While 'REST API design patterns' is a reasonably specific niche, it could overlap with general API development skills, backend development skills, or web framework skills. The lack of explicit trigger boundaries increases conflict risk.

2 / 3

Total

10

/

12

Passed

Validation

81%

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

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

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

Warning

frontmatter_unknown_keys

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

Warning

Total

9

/

11

Passed

Reviewed

Table of Contents