---
name: engineering-playbook-builder
description: Use this skill when a technology leader wants to build a real, living engineering playbook — starting with version control, code review, and CI/CD — instead of a rulebook nobody reads, or wants to audit an existing set of engineering processes and set up the mechanism that keeps the playbook current instead of ossifying into a forty-one-page process manual. States a candidate play choice and core/situational classification with reasoning; the actual rules still get co-authored with a real engineer who'll work under them. Triggers on requests like "help me write our engineering playbook," "build our first three plays," "our SDLC doc nobody reads," "run the lineage audit before we write our playbook," or "how do we decide when to change our playbook."
---

# Build (and Keep Alive) Your Engineering Playbook
This skill is Labor as Code™ for three consecutive chapters of *The
Code Takes Care of Itself* — "Short Written Playbooks Make Small Teams Fast," "Write a Short Playbook That Explains Why,"
and "A Playbook Has to Change When the Business Does." Read all three for the full
argument this generalizes: a playbook is a compressed model of *why*,
not a lookup table of *how*, and that difference is the entire reason
it stays short and useful while a process manual only ever grows. The
book's own worked examples (a forty-one-page fintech "Software
Development Lifecycle" nobody had opened in eleven months; Kelly
Johnson's fourteen rules; Musk's five-step Algorithm) are illustrations
to read, not templates to copy verbatim. This skill executes the
method — the diagnostic audit, the drafting discipline, and the
governance loop. Given real deviation examples, it applies the book's
own core-versus-situational test (Part C, Step 1) and states a
candidate classification with reasoning for the user and the engineer
to confirm or overturn. What it does not do is write a play's actual
guidance unilaterally - the book is explicit that a play "handed down
unilaterally gets followed... reluctantly," so the specific rules in
each play have to come from the user and the real engineer who will
work under it, not from this skill drafting alone.

## Before running

1. **This is three linked steps, not one form.** Part A is a one-hour
   diagnostic to run *before* writing anything. Part B builds one
   play at a time — the book is explicit that the second play doesn't
   get written until the first has run for a full quarter under real
   load. Part C is an ongoing governance habit, not a one-time
   deliverable. Confirm with the user which part they're actually
   here for before starting; don't run all three in one sitting for a
   team that just wants to fix its stalled code-review process.
2. **Part B needs a real co-author.** The book insists a play "handed
   down unilaterally gets followed the way any unilateral mandate gets
   followed: reluctantly." This skill can draft structure, but the
   actual guidance in each play has to come from a real engineer who
   will work under it — ask who that person is before drafting Step
   B4, and treat their input as required, not optional polish.
3. **This skill writes in standard Markdown**, even when the team's
   actual playbook will live in whatever format their wiki or repo
   uses. Convert format at the end; don't let format choice block the
   content work.

## Part A: The Lineage Audit (run this first, once)

A one-hour diagnostic, not a scorecard. It shows where to aim Part B,
drawing on both Kelly Johnson's fourteen rules for the Lockheed Skunk
Works and the five-step "Algorithm" Elon Musk's engineers describe —
two shops with no shared ancestry that converged on the same five
disciplines, which the book treats as evidence the disciplines are
real rather than house style.

1. **List the three most important standing requirements** — the
   release process, the review gate, the compliance control everyone
   complains about. Next to each, write the *name of the person* who
   owns it. A person's name, not a team name. If the owner is a
   department, an employee who's left, or nobody, that requirement
   goes on a "question first" list.
2. **Run one deletion pass.** List every recurring meeting, report,
   approval, and pipeline gate the organization runs, and ask one
   question of each: would we create this today if it didn't already
   exist? Delete everything that gets a no. Record the deletions
   somewhere visible, and give each one a stated restoration path — a
   restoration later counts as the system working correctly, not as
   anyone's failure.
3. **Find anything being automated that hasn't cleared steps 1–2
   yet.** AI tooling has made this the most common failure the book
   documents: automating a process before questioning or deleting it.
   Stop that automation. Give the requirement an owner, then run it
   through the deletion question.
4. **Check against Rule One (authority matched to accountability).**
   Write down the three most consequential decisions the organization
   made last quarter, and who actually made each one. If the
   responsibility was the user's but a committee made the call,
   that's the gap between accountability and authority — name it and
   take it to whoever the user reports to.
5. **Score cost honesty.** When did whoever funds this work last get
   an accurate account of where the time and money went, before they
   asked for it? If the honest answer is "only when asked," that's the
   single highest-leverage fix on this list — adopt a monthly,
   no-surprises accounting before writing a single play.

## Part B: Build your first play (repeat once per quarter, one play at a time)

1. **Choose the play**: version control, code review, or CI/CD (or,
   per the book's own extension, incident response as a fourth
   candidate). Look at the most repeated arguments, the most recent
   incident, and the complaint that keeps surfacing in one-on-ones.
   State which play the evidence points to and why, then choose the
   play whose *absence* costs the most today, not the one that's
   easiest to write. Where two candidates are close, name both and the
   specific incident or complaint that would break the tie.
2. **Write the purpose in one sentence before writing a single rule.**
   Ask what the play protects. Not "we need code review because good
   teams do code review" — that's a borrowed justification. This
   kind of sentence: "Code review exists so that no single engineer's
   blind spot becomes a production incident, and so our quality
   standard transmits to newer engineers without a formal training
   program." If the purpose can't be stated in one sentence, don't
   write the rules yet — the play's job isn't defined.
3. **Write the specific guidance, and trace every rule back to the
   purpose sentence.** For each instruction, ask: does this rule
   protect coordination between people, or does it replace a judgment
   call that actually belongs to the engineer? Keep the first kind.
   Delete the second, or rewrite it as guidance instead of a mandate.
4. **State the fourth assumption explicitly: who, or what, wrote the
   code.** All three plays historically assumed a person authored the
   change under review. On any team using AI coding agents seriously,
   that's no longer always true, and the book treats silently
   retrofitting the old plays to cover it as the same failure mode
   that produced the forty-one-page manual. Add this to whichever play
   applies:
   - **Version control:** record whether a change was AI-generated,
     AI-assisted, or independently authored — this is provenance
     information, not a compliance footnote, and it tells a future
     debugger how much independent reasoning went into the change.
   - **Code review:** for any AI-generated or AI-assisted change above
     a stated size or risk threshold, the reviewer must be able to
     explain, in their own words, why the change is correct — not
     just that tests passed. AI-generated code tends to fail by being
     confidently, fluently wrong about *intent*, which is exactly the
     failure mode a reviewer trained to catch sloppy human mistakes
     will walk past.
   - **CI/CD:** an AI-originated change earns the right to skip a gate
     the same way anything else does in this book — through a
     demonstrated, reviewed track record in a specific, narrow
     category, with a named human accountable for that category.
     Never a blanket exemption because the tool is generally reliable.
5. **Draft the play with at least one engineer who'll work under it,
   as a co-author, not a reviewer at the end.** Ask what goes wrong
   today that this play has to prevent, and confirm the play addresses
   what they named.
6. **Define one metric that will show, within a quarter, whether the
   play works** — lead time for changes, review turnaround, deployment
   frequency, or change failure rate, whichever maps most directly to
   the purpose sentence. If the metric hasn't moved after a quarter,
   rewrite the play. Don't enforce it harder.
7. **Write the second play only after the first has run a full
   quarter.** One tested play with real usage data beats a complete
   playbook written at an offsite and never tested under load.

## Part C: The adaptation mechanism (ongoing, once plays exist)

The mechanism that decides when and how the playbook changes — without
it, the decision defaults to whoever's loudest when something breaks.

1. **Sort every current play — written or unwritten — as core
   (immutable) or situational.** Apply this test: if someone deviated
   and the result was fine, would the conversation afterward be about
   the *situation* or about the *person*? "The situation" means
   situational — write it with room to flex. "The person" means core
   — it changes only through a deliberate, documented decision, never
   through individual discretion under pressure. Given real deviation
   examples from the user, apply the test yourself and state a
   candidate core/situational classification per play with the
   reasoning - the user and the engineer co-authoring still confirm or
   overturn each one, but from a reasoned starting sort, not a blank
   list.
2. **Name five or six leading indicators specific to this
   organization**, drawn from these categories: funding or ownership
   shifts, customer concentration or contract-size shifts, new
   regulatory exposure, incident frequency/severity trends, team
   composition changes, and (per the book's own addition) evidence
   that something which used to differentiate this company is
   becoming standard in the market. Write each one as something
   observable, not "watch for regulatory changes" — something like
   "if average contract size in the pipeline crosses $X ACV, revise
   the security and compliance playbook before procurement asks for
   evidence we don't have."
3. **Set a fixed review cadence and name stewards** — one person per
   major playbook category, not the user by default. Specify what
   someone has to bring to a review: a specific incident, a specific
   friction report, or a specific proposed change. A vague sense that
   something feels wrong doesn't qualify.
4. **Build a running three-input collection habit** before each
   review: cases where the team followed the playbook and the outcome
   was still bad; cases where someone deviated and it worked out
   better; friction reports where people route around a step because
   it's slow rather than wrong. Pick one place to capture these as
   they happen — a document, an issue tracker, a channel — so the
   evidence accumulates through the quarter instead of being
   reconstructed from memory the week before the review.
5. **Write the escalation rule for core changes now, in writing.** A
   core or immutable play must never change on one person's say-so.
   Decide in advance who approves a change to it — the user alone,
   the user plus a peer executive, or a board-level decision if it
   touches financial controls or compliance.
6. **Pilot every change before mandating it — including changes the
   user personally likes.** No playbook change moves from proposal to
   mandate without a two-to-four-week pilot on a limited scope. This
   has to be a standing rule, not a case-by-case judgment call, because
   confidence in a change is exactly when this step is most likely to
   get skipped.

## The check that catches this book's own failure mode

- **Every rule traces to a one-sentence purpose.** If a rule in any
  play can't be connected back to the purpose sentence that opened it,
  cut it or rewrite the purpose — an untraceable rule is the first
  brick of the forty-one-page manual this whole skill exists to avoid.
- **The "how" isn't standing in for the "why," and vice versa.** A
  play with no concrete guidance is a mission statement, not a
  playbook — it won't help anyone resolve a merge conflict at 11 p.m.
  A play with concrete guidance but no stated purpose is the rulebook
  failure mode. Confirm each play has both.
- **Nobody wrote the second play before the first ran a full
  quarter.** This is the single most commonly skipped constraint in
  the book's own account of how playbooks get built badly — check it
  explicitly before treating a multi-play rollout as complete.
- **The fourth assumption (who, or what, wrote the code) is stated,
  not silently assumed**, in every play that touches code review,
  version control, or CI/CD.