Openapi Spec Generator - Auto-activating skill for API Development. Triggers on: openapi spec generator, openapi spec generator Part of the API Development skill category.
36
3%
Does it follow best practices?
Impact
99%
1.04xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./planned-skills/generated/15-api-development/openapi-spec-generator/SKILL.mdQuality
Discovery
7%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is extremely weak—it is essentially a skill title and category label with duplicated trigger terms, providing no concrete actions, no use-case guidance, and no natural keyword coverage. It would be nearly indistinguishable from other API-related skills and gives Claude insufficient information to select it appropriately.
Suggestions
Add concrete actions describing what the skill does, e.g., 'Generates OpenAPI 3.x specification files (YAML/JSON) from API endpoint definitions, including paths, request/response schemas, and authentication details.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks to create or generate an OpenAPI spec, Swagger file, API schema, REST API documentation, or .yaml/.json API definition.'
Remove the duplicated trigger term and expand with common variations users would naturally say, such as 'swagger', 'API spec', 'API schema', 'OpenAPI YAML', 'API definition file'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description only names the skill ('Openapi Spec Generator') and its category ('API Development') but lists no concrete actions like 'generates OpenAPI/Swagger YAML/JSON specs from endpoint definitions' or similar. It is essentially a title repeated, not a capability description. | 1 / 3 |
Completeness | The description fails to answer 'what does this do' beyond the name and completely lacks a 'when should Claude use it' clause. There is no explicit trigger guidance or use-case description. | 1 / 3 |
Trigger Term Quality | The trigger terms listed are just the skill name repeated twice ('openapi spec generator, openapi spec generator'). It misses natural user phrases like 'swagger', 'API schema', 'REST API spec', 'OpenAPI YAML', '.yaml spec', 'API documentation', etc. | 1 / 3 |
Distinctiveness Conflict Risk | The term 'openapi spec generator' is somewhat specific to a niche (OpenAPI specification generation), which provides some distinctiveness. However, the broad 'API Development' category and lack of concrete scope could cause overlap with other API-related skills. | 2 / 3 |
Total | 5 / 12 Passed |
Implementation
0%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is an empty shell with no actual content. It consists entirely of auto-generated boilerplate that describes what the skill would do without providing any actionable information about generating OpenAPI specs. It fails on every dimension—there are no code examples, no spec templates, no workflows, and no references to supplementary materials.
Suggestions
Add a concrete, executable example showing a minimal OpenAPI 3.x spec (YAML or JSON) for a sample API endpoint, so Claude has a template to follow.
Define a clear workflow: e.g., 1) Gather endpoint info, 2) Generate spec skeleton, 3) Add schemas/components, 4) Validate with a tool like `swagger-cli validate spec.yaml`.
Include specific guidance on OpenAPI conventions, common patterns (pagination, error responses, auth schemes), and a validation step with a concrete command.
Remove all boilerplate sections ('When to Use', 'Example Triggers', 'Capabilities') that contain no actionable information and replace with actual spec-generation instructions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is entirely filler with no substantive information. It explains nothing Claude doesn't already know and repeats 'openapi spec generator' excessively without providing any actual guidance, code, or specifications. | 1 / 3 |
Actionability | There is zero concrete, executable guidance. No code examples, no OpenAPI spec templates, no commands, no schema snippets—just vague descriptions like 'provides step-by-step guidance' without actually providing any. | 1 / 3 |
Workflow Clarity | No workflow is defined at all. There are no steps, no sequence, no validation checkpoints. The skill claims to provide 'step-by-step guidance' but contains none. | 1 / 3 |
Progressive Disclosure | The content is a flat, uninformative page with no references to detailed materials, no links to examples or templates, and no meaningful structure beyond boilerplate headings. | 1 / 3 |
Total | 4 / 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.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
4dee593
Table of Contents
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.