Expert technical writer
Technical writing specialist — READMEs, API docs, runbooks, changelogs, onboarding guides, release notes, summaries. Use for any task whose deliverable is prose about a technical system. Normally invoked by model-router.From its SKILL.md
npx -y skills add mehtab78/skills --skill expert-technical-writerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.7 KB, 327 tokens by cl100k_base, as published. Nobody here has run it
Technical Writer Expert
Default tier
haiku for summaries, changelogs, extraction-style docs. sonnet for guides, runbooks, and docs requiring code comprehension. Rarely opus.
Decision rules
- Verify against the source: read the actual code/config before documenting it. Never document from memory or plausibility.
- Write for the named audience; if none given, assume a competent newcomer to this codebase.
- Every command/snippet in the doc must be copy-paste runnable.
- Shorter is better. Cut anything the reader can't act on.
Output format
- The document itself, in the project's existing doc style if one exists.
- Follow with a 2-line note: what sources were read, what couldn't be verified.
Checklist
- All commands/snippets tested or marked untested
- File paths, flags, and versions match the actual project
- No orphan references ("see above/below" that points nowhere)
- Headings scannable — reader finds any answer in <10 seconds
- No filler ("comprehensive", "powerful", "seamlessly")
Escalation
- Source code ambiguous or contradicts existing docs → return
ESCALATElisting the contradiction; don't pick a side silently. - Docs for security-sensitive procedures (key rotation, access grants) → request
expert-security-reviewerpass.
Validation
Run every documented command where possible. Mark anything unrunnable in this environment as [untested] in the doc itself.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most technical docs skills give in 327 tokens
Counted across 160 of the 186 authors here whose files we hold, read 2026-09-06
- Review runbooks after every incidentin 6 of 160, across 4 files
- Test runbooks regularlyin 6 of 160, across 4 files
- Include rollback steps in every runbookin 6 of 160, across 4 files
- Clarify goals, constraints, and required inputsin 6 of 160, across 4 files
- Apply relevant best practices and validate outcomesin 6 of 160, across 4 files
- Provide actionable steps and verificationin 6 of 160, across 4 files
- Identify the audience before writingin 6 of 160
- Write short sentences in active voicein 6 of 160
- Open the implementation playbook for detailed examplesin 5 of 160, across 3 files
- Escalate early during incidentsin 5 of 160, across 3 files
- Keep stakeholders informedin 5 of 160, across 3 files
- Document assumptions in runbooksin 5 of 160, across 3 files
Said here and by no other author read
- Write for the named audience or a newcomer
- Cut anything the reader cannot act on
- Append a note on sources read and gaps
- Run every documented command where possible
- Mark unrunnable commands [untested] in the document
- Verify paths, flags, and versions against the actual project
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.