Templates¶

Most of the ideas in this playbook only become real when somebody writes something down. A team does not have risk tiers because it discussed them in a meeting; it has them when a matrix says which paths are tier 3 and who stands behind an auto-merged change. A gate is not a gate until someone has defined what the person at it sees. A harness is not a team's harness until the people who do the work have challenged a description of it.

These templates are the documents I would want a team to write. Each one protects a specific decision, and each comes with guidance on when to use it, who owns it, how to fill it in, and a complete worked example. Copy them into your own repository or docs and adapt them. They are deliberately short. A template nobody fills in is worse than none, because it creates the feeling of a process without the substance of one.

How the templates fit together¶

The templates follow the life of a team harness rather than the order of the chapters. Some are written once and revisited occasionally: the brief that describes a step, the instruction file, the risk tiers. Some are written for each piece of work that passes through: the gate decisions, the impact review. And some are written when something changes or goes wrong: the change record, the postmortem, the scorecard. Together they form a loop. What you learn after shipping, or after an incident, flows back into the design of the harness, with a record of why.

flowchart TD
    subgraph Design["Design the harness"]
        HB[Harness Brief] --> AG[AGENTS.md Skeleton]
        HB --> SK[Skill Template]
        HB --> HG[Human Gate Definition]
        RT[Risk Tier Matrix] --> HG
    end
    subgraph Pilot["Pilot a workflow"]
        FP[Factory Pilot Canvas]
    end
    subgraph Run["Build, ship and learn"]
        GD["Gate decisions<br/>(Human Gate Definition)"] --> IR["Impact Review<br/>(pilot end, day 7, day 30)"]
    end
    subgraph Evolve["Evolve the harness"]
        PM[Agent Incident Postmortem]
        TS[Tool Scorecard]
        HCR[Harness Change Record]
    end
    Design --> Pilot
    Pilot --> Run
    RT --> FP
    Run -->|incident| PM
    IR -->|what the harness got wrong| HCR
    PM --> HCR
    TS -->|model or tool change| HCR
    HCR -->|steering loop| Design

Designing the harness. The Harness Brief comes first: it describes one workflow step precisely enough for an agent to execute and for the team to challenge. What the team agrees then becomes concrete components — always-on context in an AGENTS.md, procedures as skills, and stopping points as gate definitions. The Risk Tier Matrix sits alongside, deciding which gates each kind of change must pass and how much autonomy it gets.

Piloting a workflow. Before anything runs in the background, the Factory Pilot Canvas sets the baseline, the checks, the human gate and — most importantly — the promotion threshold, agreed before anyone has seen the results.

Building, shipping and learning. Gates turn into decisions on every piece of work. After release, the Impact Review returns to the hypothesis at the end of the pilot, at 7 days and at 30 days, and ends with keep, iterate or reconsider.

Evolving the harness. When something goes wrong, the Agent Incident Postmortem asks what the harness allowed. When a new model or tool arrives, the Tool Scorecard evaluates it on your own work. Every resulting change — and every removal — gets a Harness Change Record with its reason and its expiry. That record is what lets the loop run in both directions: adding controls when failures recur, and removing them when they stop earning their place.

The templates¶

One imagined team, ten documents¶

The worked examples follow a single hypothetical team: seven engineers, a product manager and an engineering manager building a subscription-billing product. Marta, a staff engineer, owns the harness; Lena owns the billing area; Daniel is the team's most constructive sceptic. None of them are real, and the numbers in their documents are invented for illustration. What is meant to be realistic is how the documents connect. An August incident produces a postmortem, which produces five harness changes — among them a skill, a CI check and a tier change, each with its own change record — and a new eval task. A rollout gate catches something no metric showed, and the 30-day impact review credits it. Reading the examples in order is a reasonable way to see the whole loop in motion.

Where to start¶

If you only use one, use the Harness Brief. Writing one part of your workflow down precisely enough for an agent to execute — and then taking it to your team — is the highest-leverage exercise in this playbook. It will tell you which of the other templates you need next.

If your team already uses agents heavily and has no written risk tiers, the Risk Tier Matrix is the most urgent: it turns review decisions that are currently improvised under pressure into ones the team has made on purpose. And if you have already had an incident involving agent-written code, start with the Agent Incident Postmortem — the harness changes it produces are usually the most valuable ones you will make.

Related pages¶

• Designing a Team Harness — The process most of these templates support.
• Testing & Evolving the Harness — How the loop on the right of the diagram works in practice.
• Engineering Leadership Playbook — Resources — ADRs, postmortems, working agreements and more, in the same format.