docs-writer
tessl install github:google-gemini/gemini-cli --skill docs-writerUse this skill for writing, reviewing, and editing documentation (`/docs` directory or any .md file) for Gemini CLI.
Review Score
69%
Validation Score
12/16
Implementation Score
63%
Activation Score
67%
Generated
Validation
Total
12/16Score
Passed| Criteria | Score |
|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') |
metadata_version | 'metadata' field is not a dictionary |
license_field | 'license' field is missing |
body_examples | No examples detected (no code fences and no 'Example' wording) |
Implementation
Suggestions 3
Score
63%Overall Assessment
This skill provides a well-structured workflow for documentation tasks with clear sequencing and verification steps. However, it lacks concrete examples of actual documentation edits or commands, and some sections contain unnecessary elaboration. The distinction between writing and editing tasks is mentioned but not fully developed with actionable specifics.
Suggestions
- Add a concrete example showing a before/after documentation edit or a sample command documentation snippet
- Tighten Step 1 by removing redundant phrases like 'Fully understand' - Claude already knows to understand requests
- Restructure the writing vs editing guidance into parallel sections rather than nesting editing as a sub-step
| Dimension | Score | Reasoning |
|---|---|---|
Conciseness | 2/3 | The content is reasonably efficient but includes some unnecessary elaboration (e.g., 'Fully understand the user's documentation request' is somewhat redundant). Some sections could be tightened without losing clarity. |
Actionability | 2/3 | Provides structured guidance with specific tool mentions (replace, write_file) and file paths, but lacks concrete examples of actual documentation edits, command usage, or copy-paste ready snippets. |
Workflow Clarity | 3/3 | Clear 4-step workflow with logical sequencing from understanding to verification. Includes validation steps (review work, link verification) and explicit checkpoints before finalizing. |
Progressive Disclosure | 2/3 | References external files appropriately (CONTRIBUTING.md, style-guide.md) but the sub-step for editing is awkwardly nested within Step 3. Could better organize the writing vs editing paths. |
Activation
Suggestions 2
Score
67%Overall Assessment
This description adequately communicates the skill's purpose with clear 'what' and 'when' guidance, earning strong completeness marks. However, it lacks specificity in the types of documentation tasks it handles and could benefit from more natural trigger terms users might actually say. The scope of 'any .md file' creates potential overlap with other documentation or markdown skills.
Suggestions
- Add more specific documentation actions like 'create API references, update READMEs, write installation guides, format code examples'
- Include additional trigger terms users might naturally say: 'docs', 'markdown', 'README', 'help documentation', 'user guide'
| Dimension | Score | Reasoning |
|---|---|---|
Specificity | 2/3 | Names the domain (documentation, /docs directory, .md files) and some actions (writing, reviewing, editing), but doesn't elaborate on specific documentation tasks like creating API docs, updating READMEs, or formatting guidelines. |
Completeness | 3/3 | Clearly answers both what (writing, reviewing, editing documentation) and when (for /docs directory or any .md file for Gemini CLI) with explicit trigger guidance via 'Use this skill for...' structure. |
Trigger Term Quality | 2/3 | Includes relevant terms like 'documentation', '/docs', '.md file', and 'Gemini CLI', but misses common variations users might say like 'docs', 'markdown', 'README', 'help text', or 'user guide'. |
Distinctiveness Conflict Risk | 2/3 | The 'Gemini CLI' qualifier provides some distinctiveness, but 'any .md file' is broad and could overlap with general markdown editing skills or other documentation skills. |