Three pages. Turning what's in your head into something the next person can follow.
Documentation is the task every SysAdmin means to get to and rarely does — not because it’s hard, but because writing clearly takes a different kind of effort than solving the problem did. You already know what you did. Turning that into a runbook someone else can follow at 3 AM, or a change log entry that still makes sense six months later, is a separate skill — and it’s one AI is genuinely good at, provided you stay in the loop.
This three-page series covers: drafting runbooks from a raw sequence of commands or a terminal history; turning incidents and change work into readable, honest change log entries; and — just as important — how to do both without publishing something wrong just because it reads well.
| You are… | You will get… |
|---|---|
| Sitting on a terminal history from an incident you never wrote up | A fast path from raw commands to a runbook someone else can actually follow |
| Expected to keep a change log but always behind on it | Prompt patterns that turn a rough timeline into a clean entry in minutes, not an hour |
| Skeptical of AI-written documentation | Page 3. It was written for you specifically. |
| Already using sgpt, aider, or fabric day to day | How those same tools apply to documentation work, not just code |
Read Page 3 at some point regardless of where you start. It isn't a disclaimer — it's the difference between documentation that helps and documentation that quietly makes things worse.