Write, structure, and maintain all forms of technical documentation — READMEs, API docs, runbooks, architecture decision records (ADRs), changelogs, onboarding guides, and user manuals.
SkillScore73Maintained
Automatic
◆Doc Ops pack
Last verified 8/4/2026
What it changes
Passed 16 of 22 test cases with the skill, and 11 of 22 without it.
Without skill50%
With skill73%
Checks it passed that the model alone missed
Uses sentence case formatting across all Markdown section headings
Begins the document body with a blockquote single-sentence overview
Documents expected terminal output following command execution steps
and 6 more in the full report
6 fixed10 passed either way5 still failing1 broke
Pass-rate lift
+23 pp
Tokens
+118%
Agent turns
0%
Response time
-13%
Model gemini-3.6-flashMeasured 8/4/2026v116 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
Edit this documentation sentence for our SDK documentation: 'When configuring the client connection pool, you must ensure that you set the maximum connection timeout value to lower than thirty seconds because otherwise the load balancer might drop idle TCP sockets while your application is waiting for responses.'
What was checked, without and with the skill
Checked
Without skill
With skill
Splits the text into concise sentences containing twenty-five words or fewer
Missed
Passed
Replaces passive or speculative phrasing with direct present tense statements
Passed
Passed
case-15 · gemini-3.6-flash · 8/4/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md319 linessingle file
Technical Writing
Approach every documentation task as a senior engineer who has joined a new team and could not figure out how to run the project from the existing docs. Write the documentation that would have saved you three hours on your first day.
Documentation is not a formality. It is the interface between your system and the humans who must use, operate, and extend it. Bad documentation costs real time — onboarding time, debugging time, support time. Good documentation compounds: every hour spent writing saves ten hours across the team.
Technical Writing Principles
Write for the reader, not the writer. You know how the system works. Your reader does not. Write for their starting point, not yours.
One document, one job. A document that tries to be a tutorial, a reference, and a how-to guide at the same time fails at all three. Follow the Diataxis framework: every document is exactly one of — Tutorial, How-To, Reference, or Explanation.
Accurate beats elegant. A beautifully written document that describes how the system used to work is worse than an ugly document that is correct. Accuracy first, prose second.
Show, don't just tell. Code examples, command outputs, screenshots, and diagrams are worth more than prose descriptions of the same thing.
Docs that are hard to find are docs that do not exist. Structure matters. A runbook buried five folders deep will not be found at 3am during an incident.
Update docs in the same PR as the code. A doc updated a week after the code change is a doc that was wrong for a week. Stale documentation erodes trust faster than no documentation.
The Diataxis Framework
Every piece of documentation you write falls into exactly one of these four types. Determine the type before writing.
Type
Question it answers
Audience mindset
Example
Tutorial
How do I learn this?
I am new and want to succeed at something
"Build your first API in 10 minutes"
How-To
How do I do X?
I know what I want; guide me
"How to deploy to production"
Reference
What is X?
I need to look up a specific detail
API endpoint reference, CLI flag reference
Explanation
Why does X work this way?
I want to understand the design
"Why we chose event-sourcing"
Never mix types in one document. A tutorial that stops to explain architecture theory loses the learner. A reference that tries to be a tutorial confuses the expert looking up a flag.
README Standard
The README is the front door of your project. It must be scannable in 30 seconds and answer: what is this, why would I care, and how do I get started.