CtrlK
BlogDocsLog inGet started
Tessl Logo

openapi-spec-generation

Generate and maintain OpenAPI 3.1 specifications from code, design-first specs, and validation patterns. Use when creating API documentation, generating SDKs, or ensuring API contract compliance.

70

Quality

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

SKILL.md
Quality
Evals
Security

Quality

Content

72%

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

A well-organized, token-efficient overview that practices good progressive disclosure by offloading full templates to referenced bundle files. Its main gaps are the absence of an inline validation-gated workflow and incomplete (skeleton-only) executable code in the body itself.

Suggestions

Add a short numbered workflow in the body (e.g., 1. draft spec → 2. validate with Spectral/Redocly → 3. generate SDK) with an explicit validation checkpoint, rather than relying on the bundle for the validation sequence.

Replace the `...` placeholders in the inline YAML skeleton with one complete, copy-paste-ready path example so the body itself is executable, keeping full templates in references.

Surface the bundle's validation/linting tools (Spectral, Redocly) as a brief inline checklist so contract-validation guidance is visible without opening references.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — no preamble explaining what OpenAPI is, just a structural skeleton, a compact approaches table, and terse Do/Don't directives where every token earns its place.

3 / 3

Actionability

The body offers a concrete YAML skeleton and specific directives ('Use $ref', 'Add examples', 'Document errors'), but the skeleton uses `...` placeholders and the fully executable, copy-paste templates are deferred to references/details.md rather than present inline.

2 / 3

Workflow Clarity

Decision guidance exists via the 'When to Use' list and design-approaches table, but the body lacks an explicit multi-step sequence (draft → validate → generate) with validation checkpoints; the validation/linting workflow lives only in the bundle, and missing inline validation caps this at 2.

2 / 3

Progressive Disclosure

SKILL.md is a lean overview that clearly signals one-level-deep references ('Full template library and detailed worked examples live in references/details.md. Read that file when you need the concrete templates.'), with content appropriately split across details.md and code-first-and-tooling.md, each holding real content rather than pointer-only nesting.

3 / 3

Total

10

/

12

Passed

Description

100%

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, third-person description that clearly states capabilities and provides an explicit 'Use when' trigger clause with natural keywords. It is concise without over-claiming and occupies a distinct niche.

DimensionReasoningScore

Specificity

Names multiple concrete actions — 'Generate and maintain OpenAPI 3.1 specifications from code, design-first specs, and validation patterns' — covering several distinct capabilities rather than vague abstractions.

3 / 3

Completeness

Explicitly answers both what ('Generate and maintain OpenAPI 3.1 specifications...') and when via an explicit 'Use when creating API documentation, generating SDKs, or ensuring API contract compliance' clause.

3 / 3

Trigger Term Quality

Includes natural user-facing terms such as 'API documentation', 'generating SDKs', and 'API contract compliance' alongside the technical 'OpenAPI 3.1', giving good coverage of phrases a user would actually say.

3 / 3

Distinctiveness Conflict Risk

The OpenAPI 3.1 / API-contract niche with triggers like SDK generation and contract compliance is distinct and unlikely to fire for unrelated skills.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
wshobson/agents
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.