typescript-docs
Create comprehensive TypeScript documentation using JSDoc, TypeDoc, and multi-layered documentation patterns for different audiences. Includes API documentation, architectural decision records (ADRs), code examples, and framework-specific patterns for NestJS, Express, React, Angular, and Vue.
Install with Tessl CLI
npx tessl i github:giuseppe-trisciuoglio/developer-kit --skill typescript-docs69
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
67%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 excels at specificity and distinctiveness by naming concrete tools, deliverables, and supported frameworks. However, it lacks explicit trigger guidance ('Use when...') and relies on technical terminology that users may not naturally use when requesting documentation help. The description would benefit from adding natural language triggers and explicit usage conditions.
Suggestions
Add a 'Use when...' clause with trigger terms like 'document my TypeScript code', 'add JSDoc comments', 'generate API docs', or 'create README'
Include more natural language variations users might say: 'docs', 'document', 'comments', 'explain code', 'API reference'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Create comprehensive TypeScript documentation using JSDoc, TypeDoc, and multi-layered documentation patterns' plus specific deliverables like 'API documentation, architectural decision records (ADRs), code examples, and framework-specific patterns' with named frameworks. | 3 / 3 |
Completeness | Clearly answers 'what does this do' with specific capabilities and tools, but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied through the capability listing. | 2 / 3 |
Trigger Term Quality | Includes relevant technical terms (JSDoc, TypeDoc, ADRs, TypeScript, documentation) and framework names, but these are more technical jargon than natural user language. Missing common variations like 'docs', 'document my code', 'add comments', or 'README'. | 2 / 3 |
Distinctiveness Conflict Risk | Clear niche focused specifically on TypeScript documentation with distinct tools (JSDoc, TypeDoc) and specific frameworks listed. Unlikely to conflict with general coding skills or other documentation tools. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive TypeScript documentation skill with excellent actionability through complete, executable code examples for multiple frameworks. However, it suffers from being overly long without progressive disclosure to separate files, and includes some generic advice that doesn't add value for Claude. The workflow for documentation generation could benefit from more explicit validation checkpoints.
Suggestions
Split framework-specific documentation (NestJS, React, Angular, Express) into separate referenced files to reduce main skill length
Remove generic best practices and pitfalls sections - Claude already knows these principles
Add explicit validation steps to the documentation generation workflow (e.g., 'Verify TypeDoc output before committing')
Move the ADR template and sample to a separate ADRS.md file with a clear reference link
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some unnecessary verbosity, such as explaining what ADRs are and providing overly detailed examples. Some sections like 'Best Practices' and 'Common Pitfalls' list generic advice Claude already knows. | 2 / 3 |
Actionability | Provides fully executable code examples throughout - TypeDoc configuration, JSDoc patterns, GitHub Actions workflows, and framework-specific documentation patterns are all copy-paste ready with complete, runnable code. | 3 / 3 |
Workflow Clarity | The documentation pipeline section provides steps but lacks explicit validation checkpoints. The GitHub Actions workflow includes validation but the manual workflow doesn't emphasize verify-before-proceeding patterns for documentation generation. | 2 / 3 |
Progressive Disclosure | Content is organized into logical sections but everything is inline in one large file. Framework-specific patterns, ADR templates, and validation could be split into separate referenced files. No external file references are provided despite the content length. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
62%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (751 lines); consider splitting into references/ and linking | Warning |
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 16 Passed | |
- 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.