Individual skill
technical-writing
Write maintainable technical docs, RFCs, READMEs, PR descriptions, and commit messages. Use for durable engineering prose.
skills/technical-writing/SKILL.md
Source commit 79595c97d47b5400034fb985e67f1a00389a81af
What was checked
- Matches the observed repository HEAD
- Yes
- Scanner rules are current
- No
- Repository scan complete
- No
- Skill scan complete
- No
- Observed behavior
- Not checked yet
- Last checked
- Nov 6, 2026
These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.
Install this skill
Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.
An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.
Repository context
- Repository stars (not skill ratings)
- 21
- Repository last updated
- Nov 1, 2026
- License
- MIT
Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.
- agent-skills Repository topic
- ai-agents Repository topic
- claude-code Repository topic
- codex Repository topic
- coding-agents Repository topic
- cursor Repository topic
- pstack Repository topic
- cline Repository topic
- copilot Repository topic
- gemini Repository topic
- engineering Derived category
- writing Derived category
- docs Derived category
Files and excerpt
File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.
Browse files
SKILL.mdcore · 796 bytes
Read excerpt
# Technical Writing
1. Identify the reader and the action/decision the document should enable.
2. Put prerequisites and outcome before implementation history.
3. Use task-oriented sections for procedures, concept-oriented sections for mental models, and reference tables only for lookup material.
4. Keep terminology stable and sentences concrete. Define unavoidable jargon once.
5. Examples must be runnable or explicitly illustrative. Never fabricate commands, links, benchmarks, or compatibility claims.
6. For change documents, include impact, design/behavior, verification, migration/rollback if relevant, and open risks.