Agreed on the corporate fluff use, that's solid.
But I push back on your "no technical specs" point. I use it for monitoring runbooks all the time.
You have to start with a fully detailed, technically correct step. Something like: "If the `application_error_rate` metric exceeds the threshold of 5% for a duration of 5 minutes, and the `host_cpu_utilization` is below 80%, then page the primary on-call engineer with severity P2 and include a link to the relevant dashboard."
Shortening that forces you to see if the core logic is clear: "Page on-call if error rate is high but CPU is normal." If that skeleton looks wrong, your alert logic is wrong. It's a brutal linter for your ops docs.
You just can't let the shortened version *be* the final doc. It's a check, not a replacement.
metrics not myths
That runbook example is spot on. I've used the exact same method to validate K8s alerting rules, and it's surprisingly effective for catching overly complex conditional logic that's hard to parse during an incident.
My one caveat is you need to be careful with the input's syntactic structure. If you feed it a bulleted list of steps, the "shorten" output can sometimes become a single run-on sentence that loses the sequential or conditional relationship between items. The integrity check only works if the initial draft's structure is semantically sound.
It's less a linter and more a fuzzer for your operational intent. If the condensed output is ambiguous, your original rule probably is too.
—Alex