CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

documentation

To write, design, review, simplify, restructure, or standardize OSS project documentation

Quality

65%

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 ./.claude/skills/documentation/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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 well-sectioned, actionable editorial framework with a clear ordered thinking model and concrete placement rules, held back by cross-section redundancy of its own principles, the absence of a worked example, and a dangling reference to a non-existent plan/INDEX.md. It is a solid instruction-only skill that would score higher after a consolidation pass and one worked application.

Suggestions

Consolidate the overlapping principle statements across Goal, Core principle, Heuristics, and Hard constraints into one canonical section, honoring the skill's own "Minimize duplication aggressively" rule.

Resolve the plan/INDEX.md reference: either include the file in the bundle with a clearly signaled path, or remove/replace the instruction.

Add one compact worked example (e.g., a before/after CONTRIBUTING.md restructure or a sample recommended doc set) to anchor the placement model and output structure.

DimensionReasoningScore

Conciseness

The body is terse, bullet-driven, and never explains concepts Claude already knows, but the same principles are restated across sections: compactness appears in Goal ("ultra-compact"), Rule 5, Heuristics ("compact"), and Writing Constraints ("Write it, then cut it in half"); anti-duplication appears ~4 times (Goal, Rule 4, Heuristics, Hard constraints). Mostly efficient, but consolidating the overlapping Goal/Core principle/Heuristics/Hard constraints sections would tighten it substantially — matching anchor 3 rather than 4.

3 / 5

Actionability

Concrete, executable guidance throughout: "CONTRIBUTING.md should usually be workflow-only", an explicit placement mapping ("README for orientation, OVERVIEW for product/system mental model, QUICKSTART for immediate action..."), an ordered 1-6 output structure, banned-phrase lists, and three post-doc review tests. Minor gap: no worked before/after example or sample ToC showing the framework applied, which keeps it below anchor 5.

4 / 5

Workflow Clarity

The thinking model is explicitly ordered ("always reason in this order: A. Audience ... E. Maintenance cost") with a phased working approach ("self-discovery, then toc, then content") and validation-style review tests ("apply all three after every doc"). This matches anchor 4: clear sequence with most checkpoints present; minor gaps because the phasing note is a single vague sentence and the workflow pieces are scattered across sections.

4 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), yet the body references "plan/INDEX.md" ("only according to `plan/INDEX.md`"), which is neither present in the bundle nor clearly signaled — a dangling reference. The ~290-line single file is well sectioned and navigable, but content that could be split (Voice & Tone, Writing Constraints) is inlined. This matches anchor 3: some structure but could be better organized and a reference is not clearly signaled.

3 / 5

Total

14

/

20

Passed

Description

50%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 names a clear domain and enumerates actions, but all dimensions hover at the midpoint because it lacks a "Use when..." trigger clause, natural synonyms, and differentiated concrete capabilities. Adding explicit trigger conditions and concrete artifacts (README, CONTRIBUTING, docs structure) would raise every dimension.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to write, review, or restructure documentation for an open source project, or mentions README, CONTRIBUTING, or docs structure."

Include natural user phrases as trigger terms: "docs", "open source", "README", "CONTRIBUTING guide", "documentation audit".

Differentiate the capabilities with concrete objects rather than near-synonymous verbs, e.g. "review and restructure README, CONTRIBUTING, and developer docs; simplify and standardize doc structure".

DimensionReasoningScore

Specificity

The description names the domain ("OSS project documentation") and lists six actions ("write, design, review, simplify, restructure, or standardize"), but these are near-synonymous single-word editorial verbs on one object rather than distinct concrete capabilities like the anchor-4 example. It matches anchor 3: domain named with actions, but not comprehensive or differentiated.

3 / 5

Completeness

The "what" is reasonably clear (write/design/review/simplify/restructure/standardize OSS documentation), but there is no "Use when..." clause or any equivalent trigger guidance. Per the judging guideline, a missing "Use when" clause caps completeness at 3.

3 / 5

Trigger Term Quality

"documentation" is a natural keyword users would say, but common variations are missing: "docs", "README", "CONTRIBUTING", "open source" ("OSS" itself is jargon-leaning). This matches anchor 3: some relevant keywords but missing common variations or synonyms.

3 / 5

Distinctiveness Conflict Risk

"OSS project documentation" scopes the skill somewhat, but it could still overlap with general writing, tech-writing, and editing skills since no distinctive triggers (e.g., README, CONTRIBUTING, docs audit, doc restructuring) are named. This matches anchor 3: somewhat specific but with overlap risk.

3 / 5

Total

12

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

griddynamics/rosetta

Path

.claude/skills/documentation/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.