writing-runbooks

Writing runbooks REQUIRED BACKGROUND: the technical-writing skill (hard rules, truth rules, style). Overview A runbook is read by someone in a hurry, often mid-incident. Every rule here serves that reader: order, one action per step, copy-pasteable commands, and danger marked where the eye already is. Write from a real run: every step one actually taken, every failure named one that actually happened. A procedure imagined at the desk is a draft, not a runbook. Publish a partially exercised procedure with per-branch honesty: the runbook names the variant that has not run yet, marks that branch draft, and asks its first real runner to report back. A procedure with no real run behind any branch is a draft outright. When a value the commands need is genuinely unknown, the placeholder stays visibly bracketed rather than invented, and gets filled from a real run before publishing; truth outranks paste-readiness. When to invoke, and not Invoke for anything a person will execute: runbooks, setup and release procedures, troubleshooting entries, operational checklists, and the operator-facing strings inside a system. Do NOT invoke for design rationale ( writing-design-docs ) or for reference material nobody executes. If the procedure has not been run at least once, either run it first or label the document a draft; publishing an untested procedure as a runbook is the defect, not the labeling. Structure Show more Installs 1.0K Repository riekelt/technical-writer GitHub Stars 20 First Seen 7 days ago Security Audits Gen Agent Trust Hub Pass Socket Pass Snyk Pass