CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

docs

Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Also use when tempted to write docs without naming the readers, without picking a tone, or without loading simple-english and i-have-adhd. Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.

Quality

87%

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

The canonical home for this skill is docs in TanStack/ai

SKILL.md
Quality
Evals
Security

Quality

Content

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

A highly actionable, clearly sequenced writing-process skill with explicit validation checkpoints and no padding from known-concept explanations. Its weaknesses are duplication (the red-flags table and two overlapping history-leak sections) and an all-in-one ~360-line file where some reference material could be split out.

Suggestions

Trim the red-flags table to entries not already stated verbatim in earlier sections, or merge it with the Forbidden section to remove the duplicate rules.

Merge "Write for the reader, not the history" and "Don't leak the build process" into one section, since both enforce the same no-history-leak principle with overlapping examples.

Move the package-manager tabs template and its framework package lines into a reference file (e.g. references/package-manager-tabs.md) and link to it from the body to slim the main file.

DimensionReasoningScore

Conciseness

The body is mostly dense, earned rules with no filler explanations of known concepts, but the ~25-row red-flags table restates rules verbatim from earlier sections (em dash, match-neighbors, history leak, install tabs), and "Write for the reader, not the history" and "Don't leak the build process" cover substantially overlapping ground. This matches "mostly efficient but could be tightened" better than the minor-trim anchor 4.

3 / 5

Actionability

Fully executable instruction-level guidance: exact docs-folder search paths, a copy-paste package-manager tabs template with real framework package lines, concrete bad/good rewrite pairs, an exact self-check (search added text for the forbidden glyphs), and hard failure handling (stop if simple-english or i-have-adhd is missing).

5 / 5

Workflow Clarity

The two-phase workflow is explicitly sequenced (flow diagram, three run moments, numbered find-docs and Phase 1 steps), gated before writing (readers, tone, prerequisite skills loaded), and closed with explicit validation loops: glyph search -> fix -> re-search, the simple-english self-check, and stop-and-report on missing files.

5 / 5

Progressive Disclosure

The single file is well-sectioned and easy to navigate, and references to the sibling skills are clearly signaled one level deep with exact paths. It falls short of anchor 5 because the ~30-line package-manager tabs data block is inlined reference material that could live in a separate file, and the skill carries everything in one ~360-line file with no bundle.

4 / 5

Total

17

/

20

Passed

Description

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

A strong description with explicit what/when structure, third-person phrasing, and a rich set of natural trigger phrases. Its main weakness is an intentionally broad trigger on any feature planning or implementation, which creates real overlap risk with general development skills.

Suggestions

Narrow the catch-all trigger "whenever planning or implementing a new feature or change in a repo" to contexts where docs are actually at stake (e.g. "when a plan or implementation changes user-facing behavior") to reduce conflict with general coding/planning skills.

Consider dropping "implement X" as a bare trigger term or tying it to doc impact, since it fires on ordinary code-implementation requests.

DimensionReasoningScore

Specificity

Names several concrete actions ("writing, editing, or organizing documentation", "planning what docs a feature needs") with only minor gaps at the activity level; it stops short of the anchor-5 comprehensive inventory of concrete capabilities.

4 / 5

Completeness

Explicitly answers both what ("writing, editing, or organizing documentation, when planning what docs a feature needs") and when (a "Use when..." clause plus concrete trigger phrases), matching the anchor-5 example structure.

5 / 5

Trigger Term Quality

Comprehensive natural-phrase coverage including synonyms and the slash-command form: "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.

5 / 5

Distinctiveness Conflict Risk

The docs niche and doc-specific triggers are distinct, but "whenever planning or implementing a new feature or change in a repo" and the trigger "implement X" overlap with general coding and planning skills, matching "somewhat specific but could still overlap with similar skills" rather than the minor-overlap anchor.

3 / 5

Total

17

/

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

TanStack/ai

Path

.grok/skills/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.