CtrlK
BlogDocsLog inGet started
Tessl Logo

document

Technical documentation expert for creating clear, comprehensive documentation including API docs (OpenAPI), ADRs, system architecture docs, developer guides, and runbooks. Use when creating or improving technical documentation.

56

Quality

66%

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 ./plugins/dev-skills/skills/document/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%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 delivers genuinely useful, concrete templates and a clear per-flag execution flow, but it is padded with generic documentation principles Claude already knows and inlines large templates that would benefit from separation into reference files. Adding validation checkpoints and trimming the boilerplate would materially raise quality.

Suggestions

Cut the 'Documentation Principles' section and the generic 7-step process down to only the non-obvious guidance; remove writing fundamentals Claude already knows.

Add validation/review checkpoints to the task workflow (e.g. 'Verify code examples run', 'Check that all referenced links resolve').

Move the full OpenAPI and ADR templates into references/ files (e.g. references/openapi-template.yaml, references/adr-template.md) and link to them from SKILL.md to improve progressive disclosure.

DimensionReasoningScore

Conciseness

The useful templates (OpenAPI YAML, ADR markdown) are mostly efficient, but the 'Documentation Principles' section and the generic 7-step process ('Identify Audience', 'Choose Format', etc.) restate writing fundamentals Claude already knows and could be trimmed.

3 / 5

Actionability

Provides concrete, copy-paste-ready templates (full OpenAPI 3.0 spec, ADR markdown) and per-flag task steps, though the system-architecture/onboarding/runbook sections are bullet checklists rather than executable templates.

4 / 5

Workflow Clarity

A clear numbered sequence exists (the 7-step process and per-flag task sections), but there are no validation checkpoints or feedback loops (e.g. verify examples compile, check links resolve) even though review steps would fit naturally.

3 / 5

Progressive Disclosure

Sections are well-organized with headers, but at ~230 lines everything is inlined into SKILL.md with no bundle files; the large OpenAPI and ADR templates are content that could plausibly live in separate reference files, and no references are signaled.

3 / 5

Total

13

/

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.

The description is third-person, has an explicit 'Use when' trigger, and lists concrete documentation deliverables, giving it a solid, balanced profile. Its main weakness is that the 'when' clause and action verbs are somewhat generic rather than crisply specific.

Suggestions

Tighten the 'when' clause with concrete trigger phrases, e.g. 'Use when the user asks to write API docs, an ADR, a runbook, or developer onboarding docs'.

Add a couple of natural synonyms ('Swagger', 'architecture decision record', '.yaml/.json spec') to broaden trigger coverage.

Lead with the concrete actions ('Generate OpenAPI specs, write ADRs, draft runbooks') before the abstract 'clear, comprehensive documentation' framing.

DimensionReasoningScore

Specificity

Enumerates several concrete deliverable types ('API docs (OpenAPI), ADRs, system architecture docs, developer guides, and runbooks') but the action verb ('creating') stays generic, leaving minor coverage gaps rather than fully comprehensive action detail.

4 / 5

Completeness

Clearly states the 'what' (the enumerated documentation types) and an explicit 'when' ('Use when creating or improving technical documentation'), but the 'when' clause is somewhat generic and could be more specific.

4 / 5

Trigger Term Quality

Includes natural terms users say ('API docs', 'OpenAPI', 'ADRs', 'runbooks', 'developer guides', 'technical documentation') with good coverage, though a few common synonyms/variations are absent.

4 / 5

Distinctiveness Conflict Risk

The specific enumerated types (ADRs, runbooks, OpenAPI) carve a clear niche, with only minor overlap risk against a general writing or code-review skill.

4 / 5

Total

16

/

20

Passed

Validation

87%

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

Validation14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

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

14

/

16

Passed

Repository
rikdc/ai-skills
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.