Sdk Documentation Generator - Auto-activating skill for Technical Documentation. Triggers on: sdk documentation generator, sdk documentation generator Part of the Technical Documentation skill category.
33
0%
Does it follow best practices?
Impact
97%
0.98xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./planned-skills/generated/17-technical-docs/sdk-documentation-generator/SKILL.mdQuality
Discovery
0%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 essentially a placeholder that provides no meaningful information beyond the skill's name. It lacks concrete actions, natural trigger terms, explicit 'when to use' guidance, and any distinguishing details that would help Claude select it appropriately from a pool of skills.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Generates SDK reference documentation, creates API usage examples, documents method signatures and parameters, produces quickstart guides for libraries.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks to document an SDK, generate API references, create library documentation, or produce developer guides for code packages.'
Remove the duplicate trigger term and expand with natural variations users would say, such as 'SDK docs', 'API documentation', 'library reference', 'developer docs', 'code documentation'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description contains no concrete actions whatsoever. It only states it is an 'SDK Documentation Generator' and mentions 'Technical Documentation' but never describes what it actually does (e.g., generates API references, creates code examples, documents endpoints). | 1 / 3 |
Completeness | Neither the 'what' nor the 'when' is meaningfully answered. There is no explanation of what the skill does beyond its name, and no 'Use when...' clause or equivalent explicit trigger guidance. | 1 / 3 |
Trigger Term Quality | The trigger terms are just the skill name repeated twice ('sdk documentation generator, sdk documentation generator'). There are no natural user keywords like 'API docs', 'SDK reference', 'library documentation', 'code documentation', or file format mentions. | 1 / 3 |
Distinctiveness Conflict Risk | The description is so vague that it could overlap with any documentation-related skill. 'Technical Documentation' is a broad category, and without specific actions or file types, it would be difficult to distinguish from other documentation skills. | 1 / 3 |
Total | 4 / 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 actionable content whatsoever. It consists entirely of auto-generated boilerplate that repeats the skill name without providing any actual guidance, code, templates, or concrete instructions for SDK documentation generation. It fails on every dimension of the rubric.
Suggestions
Add concrete, executable examples such as a documentation template, a script for auto-generating SDK docs from code annotations, or a sample output showing expected documentation format.
Define a clear multi-step workflow for generating SDK documentation (e.g., 1. Parse source code, 2. Extract API signatures, 3. Generate markdown, 4. Validate links and formatting).
Remove all boilerplate sections ('When to Use', 'Example Triggers', 'Capabilities') that merely restate the skill name and replace them with actual technical content—code snippets, tool configurations, or documentation standards.
Include references to specific tools (e.g., TypeDoc, Sphinx, Doxygen) with concrete configuration examples and link to supplementary files for advanced topics.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is entirely filler and boilerplate. It repeats 'sdk documentation generator' numerous times without providing any actual information Claude doesn't already know. Every section restates the same vague concept with no substance. | 1 / 3 |
Actionability | There is zero concrete guidance—no code, no commands, no specific steps, no examples of input/output, no templates. Every bullet point is abstract and vague (e.g., '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 | There is no meaningful content to organize, no references to external files, and no layered structure. The sections are just repetitive restatements of the skill name with no navigable depth. | 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.