CtrlK
BlogDocsLog inGet started
Tessl Logo

api-documenter

Master API documentation with OpenAPI 3.1.

28

Quality

21%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.agent/skills/api-documenter/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

20%

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

This skill reads more like a high-level blog post or checklist about API documentation best practices than an actionable skill for Claude. It is heavy on generic advice that Claude already knows and light on concrete, executable guidance—no OpenAPI spec examples, no schema templates, no actual documentation generation commands beyond a single validator script. The content would need a fundamental rewrite to be useful as a skill.

Suggestions

Replace generic advice bullets with concrete, executable examples: include a minimal OpenAPI 3.1 spec snippet, a complete openapi-generator-cli command with flags, and a sample Prism mock server invocation.

Remove the role-playing preamble and motivational language ('delight for developers', 'Senior Technical Writer') to save tokens and focus on actionable content.

Add validation feedback loops to the Execution Protocol: specify what to do when validation fails, include expected output examples, and add a verification step after doc generation.

Either provide bundle files (templates, scripts, reference docs) and reference them clearly, or inline the essential content—currently the skill references 'standard templates' and a validator script that don't exist in the bundle.

DimensionReasoningScore

Conciseness

The content is padded with role-playing preamble ('You are a Senior Technical Writer and API Architect'), motivational fluff ('a delight for developers'), and explains concepts Claude already knows (what tags are, what OAuth2 is, what a changelog is). Most bullet points are generic advice rather than actionable instructions.

1 / 3

Actionability

Almost entirely vague, high-level advice ('Write how-to guides', 'Maintain a clear log', 'Create a welcoming entry point'). The only concrete command is the validator script, but there's no executable OpenAPI spec example, no schema snippet, no template content. The guidance describes rather than instructs.

1 / 3

Workflow Clarity

The Execution Protocol section provides a numbered sequence (validate → generate → review → publish), and step 1 includes a concrete validation command. However, steps 2-4 are vague ('Use standard templates', 'Audit the documentation'), there are no feedback loops or error recovery steps, and no validation checkpoints after generation.

2 / 3

Progressive Disclosure

The content uses an internal menu with anchor links and organized sections, which provides some structure. However, there are no references to external files for detailed content (no bundle files exist), and sections 1-4 contain shallow bullet points that are neither concise overviews nor detailed references—they occupy an unhelpful middle ground.

2 / 3

Total

6

/

12

Passed

Description

22%

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 far too terse and vague to be effective. It fails to specify what concrete actions the skill performs, provides no 'Use when...' guidance, and uses the imperative 'Master' which is neither informative nor in proper third-person descriptive voice. The only redeeming quality is the mention of 'OpenAPI 3.1' which provides some domain specificity.

Suggestions

Replace the vague 'Master API documentation' with specific actions like 'Generates, validates, and documents REST API specifications using OpenAPI 3.1 format, including endpoint definitions, request/response schemas, and authentication configuration'.

Add an explicit 'Use when...' clause with trigger terms such as 'Use when the user asks about OpenAPI specs, Swagger files, API documentation, REST endpoints, .yaml/.json API definitions, or schema validation'.

Include common synonym trigger terms like 'swagger', 'REST API', 'API spec', 'endpoints', 'schema' to improve matching against natural user queries.

DimensionReasoningScore

Specificity

The description uses vague language ('Master API documentation') without listing any concrete actions like 'generate endpoints', 'validate schemas', or 'create request examples'. It names a domain (OpenAPI 3.1) but describes no specific capabilities.

1 / 3

Completeness

The 'what' is extremely vague ('Master API documentation' says almost nothing about what the skill actually does), and there is no 'when' clause or explicit trigger guidance whatsoever.

1 / 3

Trigger Term Quality

It includes 'API documentation' and 'OpenAPI 3.1' which are relevant keywords a user might mention, but misses common variations like 'swagger', 'REST API', 'API spec', 'endpoints', '.yaml', '.json', or 'schema'.

2 / 3

Distinctiveness Conflict Risk

'OpenAPI 3.1' provides some specificity that distinguishes it from generic documentation skills, but 'API documentation' is broad enough to overlap with other API-related or documentation skills.

2 / 3

Total

6

/

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

frontmatter_unknown_keys

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

Warning

Total

10

/

11

Passed

Repository
Dokhacgiakhoa/antigravity-ide
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.