Docs writing
A production-grade engineering toolkit for AI-assisted software development. Contains 168 specialized skill workflows (100 core + 68 GSD sub-skills), 142 expert agent personas, 24 design system specifications, 5 reference checklists, 84 slash commands, and 9 MCP server integrations.
npx -y skills add NafisRayan/100x-Agent-Toolkit --skill docs-writingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 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.
What its author says it does
Copied from the file, not written here
Writes and audits technical documentation using Diataxis, Stripe-style clarity, and the Eight Rules. 52 rules across 9 categories covering voice, structure, clarity, code examples, formatting, navigation, scanability, content hygiene, and review. Use when writing docs, creating READMEs, documenting APIs, writing tutorials, building a docs site, auditing documentation quality, or asking "review my docs", "improve this documentation", or "write docs for this".
SKILL.md
3.7 KB, as published. Nobody here has run it
Documentation Writing
52 rules across 9 categories for documentation quality. Focuses on concrete issues with concrete fixes.
Doc Writing/Audit Workflow
Copy and track this checklist during the audit:
Doc writing/audit progress:
- [ ] Step 1: Determine doc type (tutorial, how-to, reference, explanation) and audience
- [ ] Step 2: Run CRITICAL checks (voice and tone, structure and organization)
- [ ] Step 3: Run HIGH checks (clarity and language, code examples)
- [ ] Step 4: Run MEDIUM+ checks for remaining categories in scope
- [ ] Step 5: Report findings with file:line and concrete fixes
- Audit only changed files unless a full sweep is requested.
- Identify the doc type (tutorial, how-to, reference, explanation) and intended audience to select relevant categories.
- Load rule files progressively by category prefix — read only what applies.
- Prioritize CRITICAL and HIGH findings before medium-priority polish.
- After fixes, rerun the relevant rules before finalizing.
Rule Categories by Priority
| Priority | Category | Impact | Prefix | Rules |
|---|---|---|---|---|
| 1 | Voice & Tone | CRITICAL | voice- | 4 |
| 2 | Structure & Organization | CRITICAL | structure- | 10 |
| 3 | Clarity & Language | HIGH | clarity- | 6 |
| 4 | Code Examples | HIGH | code- | 7 |
| 5 | Formatting & Syntax | MEDIUM-HIGH | format- | 8 |
| 6 | Navigation & Linking | MEDIUM-HIGH | nav- | 6 |
| 7 | Scanability & Readability | MEDIUM | scan- | 2 |
| 8 | Content Hygiene | MEDIUM | hygiene- | 6 |
| 9 | Review & Testing | LOW-MEDIUM | review- | 3 |
Quick Reference
Read only what is needed for the current scope:
- Category map and impact rationale:
rules/_sections.md - Rule-level guidance and examples:
rules/<prefix>-*.md
Example rule files:
rules/voice-defaults.md
rules/structure-diataxis.md
rules/clarity-defaults.md
Each rule file contains:
- Why the rule matters
- Incorrect example
- Correct example
Review Output Contract
Report findings in this format:
## Documentation Audit Findings
### path/to/file.md
- [CRITICAL] `voice-defaults`: Passive voice obscures who performs the action.
- Fix: Rewrite "The configuration is loaded by the server" as "The server loads the configuration."
### path/to/clean-file.md
- ✓ pass
- Group findings by file.
- Use
file:linewhen line numbers are available. - State issue and propose a concrete fix.
- Include clean files as
✓ pass.
Gotchas
- Don't audit files that weren't changed unless a full sweep was explicitly requested — scope creep drowns the real findings.
- Don't skip doc-type identification. Tutorial rules applied to reference content (or vice versa) produces wrong-shaped feedback.
- Don't report MEDIUM/LOW polish before surfacing CRITICAL/HIGH findings — the reader fixes what they see first.
- Don't load every
rules/<prefix>-*.mdfile up front. Load progressively by category in scope. - Don't report findings without
file:lineand a concrete fix — the Review Output Contract requires both. - Don't rewrite content you were asked to review unless the user asked for edits — report issues, propose fixes, let the author apply them.