Skip to content
Kien

Turning ops runbooks into commands anyone can run

~70 engineering runbooks packaged as executable commands across 3 installable repos used by two teams — with mechanised guardrails on every operation that touches production.

Period
02/2026 – present
Role
Author and maintainer — solo
Team size
In daily use by two engineering teams

Stack

  • Claude Code skills & plugins
  • MCP (9 servers)
  • Bash
  • Python 3
  • Node.js
  • macOS launchd
  • GitLab CI
  • Markdown + YAML frontmatter

The problem

The same fiddly procedures were redone by hand every time: reconstruct a failed booking from four separate log sources, run SQL against a production database the standard mysql client cannot even connect to, hand-drive a manual CI pipeline to deploy, or provision a new supplier across two codebases and a database table.

All of it lived in one engineer's head. Ask him and you get an answer. Take him away and the work stops.

The approach

Each procedure became one file with a fixed shape: its arguments, an allowlist of exactly which tools it may touch, and a runbook body that includes the traps which previously cost hours.

The important part is that the guardrails are mechanised, not advisory:

  • A production DB write requires a blast-radius count, and a printed hostname and read-only check of the actual target before the human is asked to approve.
  • Consent expires within the turn — "they agreed last time" does not count.
  • A production deploy needs a typed confirmation, and may not be reported as done until the pipeline-wait command returns success.
  • Anything needing sudo is handed to the human to run.

The heaviest piece is a multi-agent pipeline that builds supplier API mapping documentation: the orchestrating session holds a hard read-whitelist and does no content work, six typed subagents with their own models and tools do all of it, a deterministic Python gate runs before any LLM reviewer (a script cannot argue with you), reviewers are blind and tasked with refuting, and the fixer is a separate agent holding only Edit.

The result

~70 distinct runbooks across 3 installable repos, wired by a symlink installer so git pull is the update. Six subagent roles, nine MCP servers scoped per tool, and five headless scheduled jobs that write worklogs and weekly reports — each validating its own output before touching a tracked file.

Cost is tracked in a file where every figure carries a measured or estimated label, a date and a source — including one optimisation recorded as a failure, with its payback maths written out.

There is no "saved X hours" number here, because none was measured.