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.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

12%

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

The body functions as a capability taxonomy and persona description rather than executable guidance: it is verbose, lacks concrete code or commands, and stores all detail inline in one file with no progressive disclosure. It needs concrete tool invocations, validation steps, and reference files to become actionable.

Suggestions

Replace the capability bullet lists with executable guidance, e.g. concrete commands like `redocly lint openapi.yaml`, `openapi-generator-cli generate -i openapi.yaml -g python`, or working curl/code samples users can run.

Add validation checkpoints and a feedback loop to the workflow (e.g. 'lint the spec -> fix errors -> re-lint -> only then publish'), since docs/spec generation benefits from validate-fix-retry cycles.

Move the long capability/knowledge-base sections into separate referenced files (e.g. CAPABILITIES.md, TOOLS.md) and keep SKILL.md as a lean overview with clearly signaled one-level-deep links.

Dimension	Reasoning	Score
Conciseness	The ~250-line body restates domain knowledge Claude already knows (e.g., 'OAuth 2.0 and OpenID Connect flow documentation,' 'JSON Schema validation,' 'CI/CD pipeline integration') and repeats the persona in the Purpose section, matching the verbose/padded anchor rather than the mostly-efficient anchor at 2.	1 / 3
Actionability	The content is almost entirely descriptive taxonomy ('AI-assisted content generation with tools like Mintlify and ReadMe AI,' 'Multi-language SDK generation from OpenAPI specifications') with no executable code, commands, or copy-paste examples, matching the 'describes rather than instructs' anchor.	1 / 3
Workflow Clarity	Instructions and Response Approach provide a numbered sequence, but steps are abstract with no validation checkpoints or feedback loops for spec generation/validation work, which per the rubric caps workflow clarity at 2; not 1 because a sequence is present.	2 / 3
Progressive Disclosure	The skill is a monolithic single-file wall of text with no bundle files (references/, scripts/, assets/ are absent) and no signaled references to external materials, matching the monolithic/one-level-deep anchor at 1 rather than the partially-structured anchor at 2.	1 / 3
	Total	5 / 12 Passed

Description

60%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description names a clear domain and several concrete capabilities with good specificity, but it omits any explicit 'Use when...' trigger guidance, which caps completeness and trigger-term quality. Adding a natural-language trigger clause would lift the weaker dimensions.

Suggestions

Append an explicit 'Use when...' clause with natural user phrasings, e.g. 'Use when creating or updating OpenAPI/AsyncAPI specs, building developer portals or SDK docs, or generating code examples from an API spec.'

Broaden trigger terms to common variations users actually say: 'API docs,' 'Swagger,' 'OpenAPI spec,' 'Redoc,' 'code samples from a spec,' 'API onboarding.'

Tighten the generic opener ('Master API documentation with... modern developer experience practices') to reduce buzzword overlap with general documentation skills.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions ("Create interactive docs, generate SDKs, and build comprehensive developer portals") plus named tools (OpenAPI 3.1, AI-powered tools), matching the multiple-specific-actions anchor rather than the partial domain-only anchor at 2.	3 / 3
Completeness	Clearly states what the skill does but provides no explicit 'when to use' trigger guidance, and per the rubric a missing 'Use when...' clause caps completeness at 2; not 1 because the 'what' is clearly stated.	2 / 3
Trigger Term Quality	Contains relevant keywords ("API documentation," "OpenAPI," "SDKs," "developer portals") but lacks a 'Use when...' clause and common natural variations a user would say, so it sits at 'some relevant keywords but missing common variations' rather than full coverage at 3.	2 / 3
Distinctiveness Conflict Risk	The domain (OpenAPI 3.1, SDK generation, developer portals) is fairly niche but the absence of explicit triggers and the generic opening ('Master API documentation') leave overlap risk with general docs/coding skills, matching 'somewhat specific but could still overlap' rather than the distinct-trigger anchor at 3.	2 / 3
	Total	9 / 12 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: sickn33/antigravity-awesome-skills
Commit: 9fc5f98

Reviewed: about 10 hours ago

Table of Contents

Discovery Implementation Validation

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.