CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

components-write-docs

Guidelines for creating or updating documentation for a CDS component on the docsite (apps/docs/). Use this skill after creating or making updates to a CDS React component to write high quality documentaiton in the CDS docsite.

Quality

74%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/components-write-docs/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%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.

This is a highly actionable, well-sequenced workflow skill: exact paths, complete templates, and a thorough final checklist leave little ambiguity about what to do. Its main costs are token efficiency and file organization — ~680 lines of monolithic content with substantial web/mobile template duplication that belongs in bundled reference files, plus validation steps that assert 'test it' without giving a command.

Suggestions

Move the full file templates (metadata JSON, props tables, styles, index.mdx variants, example skeletons) into references/ files (e.g., references/templates.md) and keep SKILL.md as an overview with one-line pointers.

Factor the web/mobile/cross-platform index.mdx templates into one base template plus a short diff of platform_switcher_options and import lines, eliminating the triple repetition.

Replace checklist assertions like 'Test all examples and props tables render correctly' with concrete validation commands (e.g., the docsite build/dev command) and a fix-and-retry loop for rendering errors.

DimensionReasoningScore

Conciseness

The body avoids explaining concepts Claude already knows — nearly every line is repo-specific convention, exact paths, or templates — but at ~680 lines it is noticeably over budget. The three index.mdx templates (web-only, mobile-only, cross-platform) and the paired _web/_mobile templates for props tables, styles, and examples repeat the same structure with small diffs, and filler lines like 'There is a chance that the component has already been imported' pad it further. This sits between 'noticeably verbose' (2) and 'efficient with minor trimming' (4): mostly earned tokens, but real duplication that could be factored into shared patterns or reference files.

3 / 5

Actionability

The guidance is copy-paste ready throughout: complete webMetadata.json schemas, fully executable props-table and StylesExplorer MDX blocks (including a working SelectExample with useState), exact file paths like 'packages/web/src/[source-category]/[ComponentName].tsx', and precise procedures for deriving dependencies from peerDependencies. Placeholders like [ComponentName] are intentional parameterization, not pseudocode, and the common cases (web-only, mobile-only, cross-platform, with/without styles API) are each covered with real code.

5 / 5

Workflow Clarity

Steps are clearly sequenced (check existing docs → research → verify availability → setup → create files → write content) with explicit branching for new docs vs updates, web vs mobile, and styles API presence, capped by a 19-item final checklist. It falls short of 5 because validation is checklist-only: 'Test all examples and props tables render correctly' gives no command (no build/dev-server invocation, no docgen check) and no error-recovery feedback loop, so checkpoints exist but are not executable.

4 / 5

Progressive Disclosure

With no references/, scripts/, or assets/ directories, everything lives in one monolithic SKILL.md — including large file-template blocks that would naturally sit in one-level-deep reference files. Internal structure is good (numbered steps, clear section headers, well-labeled templates), which keeps it above the 'minimal structure' anchor of 2, but the inline bulk (three near-identical index.mdx variants, full example skeletons) is exactly the 'content that should be separate is inline' pattern of the 3 anchor.

3 / 5

Total

15

/

20

Passed

Description

70%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 a solid, honest trigger: it states a precise niche, uses third person, and includes an explicit 'Use this skill after...' clause. Its weaknesses are modest coverage of what the documentation work entails, a trigger that misses the direct 'user asks for docs' path, and a typo ('documentaiton') in the closing sentence.

Suggestions

Expand the action list slightly (e.g., 'create metadata, props tables, live examples, and styles docs') so the 'what' is more comprehensive.

Broaden the trigger clause: 'Use after creating or updating a CDS React component, or when the user asks to write or update component documentation.'

Fix the typo 'documentaiton' and drop the redundant restatement of the goal in the second sentence.

DimensionReasoningScore

Specificity

The description names the domain precisely ('documentation for a CDS component on the docsite (apps/docs/)') and lists two actions ('creating or updating documentation'), but goes no deeper — it never hints at what the work actually involves (metadata files, props tables, examples, docgen config). This matches the anchor 'Names domain and 1-2 concrete actions, but not comprehensive'; a 4 would require several specific actions with only minor gaps.

3 / 5

Completeness

Both parts are present: the 'what' ('Guidelines for creating or updating documentation for a CDS component on the docsite') and an explicit 'when' ('Use this skill after creating or making updates to a CDS React component'). Not a 5 because the trigger clause covers only one path — creating/updating a component — and doesn't address the user directly asking for doc changes (e.g., 'or when the user asks to document a component'), and the clause partially repeats the 'what' instead of adding new trigger phrases.

4 / 5

Trigger Term Quality

It includes natural terms a user would plausibly say — 'documentation', 'CDS component', 'React component', 'docsite', 'creating', 'updates' — giving good keyword coverage. A 5 would require synonyms and variations users actually type (e.g., 'write docs', 'document the Button component', 'update the component page'), which are missing; it does not fall to 3 because the present keywords are relevant, not generic filler.

4 / 5

Distinctiveness Conflict Risk

The CDS docsite niche is clear and well-scoped by '(apps/docs/)' and 'CDS component', so generic skills would not trigger. Not a 5 because the body references a sibling 'components-best-practices' SKILL covering the same component ecosystem — a request like 'update the Button component docs to follow best practices' could plausibly trigger either, a minor overlap risk.

4 / 5

Total

15

/

20

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 — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (682 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 1 suspicious

Warning

Total

13

/

16

Passed

Repository

coinbase/cds

Path

.claude/skills/components-write-docs/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.