Build (and Keep Alive) Your Engineering Playbook

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…

Download SKILL.md

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

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.
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.
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.

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.
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.
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.
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.
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)

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.
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.
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.
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.
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.
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.
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.

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.
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."
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.
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.
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.
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.