CtrlK
BlogDocsLog inGet started
Tessl Logo

api-and-interface-design

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

60

Quality

71%

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-and-interface-design/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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 dense, well-structured, and highly actionable design guide whose code examples and checklists are its strengths. Its weaknesses are efficiency — it re-teaches known concepts like HTTP status codes and TypeScript patterns — and a monolithic structure that inlines deep reference material (especially idempotency) instead of splitting it into bundle files, including one dangling cross-reference.

Suggestions

Trim known-concept restatement: drop the Hyrum's Law quote/paraphrase and the HTTP status-code mapping comments, keeping only the project-specific conventions they justify — that would tighten conciseness from 3 toward 4-5.

Split deep implementation detail into reference files (e.g. references/idempotency.md and references/rest-patterns.md), leaving SKILL.md as a lean overview with clearly signaled one-level-deep links.

Fix or remove the dangling "See `deprecation-and-migration`" reference at line 30 — no such file exists in the bundle, so it currently misleads navigation.

DimensionReasoningScore

Conciseness

The body restates concepts Claude already knows — the Hyrum's Law quote plus its plain-language paraphrase, the HTTP status-code mapping ("400 → Client sent invalid data"), REST resource-naming basics, and standard TypeScript patterns (discriminated unions, branded types). These are more than minor over-explanations, matching 'mostly efficient but includes some unnecessary explanation', though nothing is padded enough to drop to 2.

3 / 5

Actionability

Concrete TypeScript interfaces, a complete Express validation handler, the TOCTOU-vs-unique-constraint idempotency code, decision tables, and a verification checklist give mostly executable guidance. Minor gaps — `function getTask(id: TaskId): Promise<Task> { ... }` and undefined helpers like `isUniqueViolation` and `replayOrReject` — keep it short of copy-paste-ready.

4 / 5

Workflow Clarity

"After designing an API:" followed by a 12-item checklist provides explicit validation checkpoints, and the Red Flags section gives review criteria. There is no stepwise procedure or error-recovery loop, but for a design-guidance skill the organizational sequence plus checklist matches 'clear sequence with most checkpoints present'.

4 / 5

Progressive Disclosure

This is a ~360-line monolithic SKILL.md with no bundle files; the deep idempotency implementation section and the REST/TypeScript pattern catalogs clearly belong in separate reference files. The reference at line 30 ("See `deprecation-and-migration`") is dangling — no such file exists in the bundle. Good section headers keep it above the 'minimal structure' anchor.

3 / 5

Total

14

/

20

Passed

Description

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

A strong description with an explicit, multi-scenario "Use when" clause and clear domain focus. The main gap is specificity — it says the skill 'guides design' without listing concrete actions or outcomes, and "any public interface" slightly widens the trigger surface.

DimensionReasoningScore

Specificity

"Guides stable API and interface design" names the domain clearly but relies on one generic action verb rather than enumerating concrete capabilities; the design activities appear only in the when-clauses. It sits at the 'names domain and 1-2 concrete actions' anchor, below 4 which requires several specific listed actions.

3 / 5

Completeness

Both parts are explicit: "Guides stable API and interface design" states what it does, and two "Use when..." clauses give concrete trigger scenarios (endpoints, type contracts, frontend/backend boundaries). The when is explicit and specific, matching the top anchor rather than 4's 'could be more explicit'.

5 / 5

Trigger Term Quality

Natural terms users would say are well covered — "APIs", "REST or GraphQL endpoints", "module boundaries", "type contracts", "frontend and backend". A few common variants (e.g. OpenAPI, schema design, API versioning) are missing, keeping it below comprehensive coverage at 5.

4 / 5

Distinctiveness Conflict Risk

The API/interface-design niche is mostly distinct with clear triggers, but "or any public interface" is broad and could overlap with closely related skills (component props design, database schema design). Minor overlap risk matches 4 rather than 5's minimal-conflict profile.

4 / 5

Total

16

/

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
addyosmani/agent-skills
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.