CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

api-documenter

Master API documentation with OpenAPI 3.1, AI-powered tools, and modern developer experience practices. Create interactive docs, generate SDKs, and build comprehensive developer portals. Use for API documentation or developer portal creation.

Quality

63%

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-documenter/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is a persona-style capability catalog: well-organized and clearly sectioned, but almost entirely descriptive padding that assumes no competence of Claude and offers no executable guidance. Weakest on conciseness and actionability; workflow and structure are present but shallow.

Suggestions

Replace the ~100-line Capabilities, Behavioral Traits, and Knowledge Base catalogs with task-specific guidance, keeping only what Claude would not already know (e.g., project-specific conventions, tool choices, naming standards).

Add executable artifacts: an OpenAPI 3.1 skeleton snippet, concrete validation commands (e.g., `spectral lint api.yaml` or a Redocly CLI check), and example SDK-generation commands so the Instructions steps can actually be followed.

Move detailed tool and capability catalogs (platform comparisons, auth documentation patterns, portal architecture details) into references/ files linked one level deep from SKILL.md.

DimensionReasoningScore

Conciseness

Roughly 100 lines of generic capability bullets ("AI-assisted content generation with tools like Mintlify and ReadMe AI", "Swagger UI and Redoc customization and optimization") plus "Behavioral Traits", "Knowledge Base", and "Purpose" sections pad the file without adding knowledge Claude does not already have. Not 1 because it never explains basic concepts; not 3 because the padding spans multiple full sections rather than occasional loose sentences.

2 / 5

Actionability

The only guidance is high-level hints like "Create or validate specifications with examples and auth flows" and "Build interactive docs and ensure accuracy with tests" — no code, commands, templates, or worked examples anywhere. This sits between the purely descriptive anchor 1 and anchor 2's high-level-hints-without-steps, landing at 2 because the Instructions and Response Approach sections do give vague directives.

2 / 5

Workflow Clarity

"Instructions" (4 steps) and "Response Approach" (8 numbered steps) present a coherent sequence from assessment to maintenance, but validation is only implicit ("Implement testing and validation for accuracy and reliability") with no checkpoints or error-recovery loops. Matches anchor 3: steps listed but validation gaps.

3 / 5

Progressive Disclosure

The body is well-sectioned with headers, but over 100 lines of capability catalogs that belong in separate reference files are inlined, and there are no references/ files at all. This matches anchor 3's inline-content-that-should-be-separate pattern; not 2 because the structure itself is clear and navigable.

3 / 5

Total

10

/

20

Passed

Description

75%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 solid description with concrete actions, natural trigger terms, and an explicit use-when clause, all in third-person imperative voice. Its main weakness is trigger coverage that is narrower than the skill's actual scope (spec authoring, SDK generation, migration guides).

DimensionReasoningScore

Specificity

"Create interactive docs, generate SDKs, and build comprehensive developer portals" lists several concrete actions, though the "Master API documentation... and modern developer experience practices" lead-in is vague and coverage has gaps (no testing, migration, or versioning actions). Not 5 because coverage is not comprehensive; not 3 because it goes well beyond 1-2 actions.

4 / 5

Completeness

Both parts are present: a clear what ("Create interactive docs, generate SDKs, and build comprehensive developer portals") and an explicit when ("Use for API documentation or developer portal creation"). Not 5 because the when-clause omits key triggers the body itself names, such as creating/updating OpenAPI/AsyncAPI specs and generating SDKs from specs.

4 / 5

Trigger Term Quality

Natural terms users would say are present ("API documentation", "developer portal", "SDKs", "OpenAPI 3.1"), but common variations like "API docs", "OpenAPI spec", "Swagger", or "reference documentation" are missing. Good coverage with a few natural terms missing matches the 4 anchor.

4 / 5

Distinctiveness Conflict Risk

The API documentation / developer portal niche is mostly distinct with clear triggers, with only minor overlap risk against general technical-writing or documentation skills. It does not reach 5 because "API documentation" is still a fairly broad phrase that could collide with generic docs-writing skills.

4 / 5

Total

16

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

rmyndharis/antigravity-skills

Path

skills/api-documenter/SKILL.md

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.