Train, monitor, manage · Lesson 4 of 6
How does a Team's Playbook learn your rules?
Published June 9, 2026 · Updated September 25, 2026
A Team's Playbook is the shared set of rules it has learned for how the work gets done. Rules come from real decisions: when your corrections show a pattern, the Team proposes a rule, and it is active until a person adopts or dismisses it behind the Playbook card on the Team page.
What is a Playbook rule?
A plain sentence about how the work gets done here. “Any migration that adds a lookup needs an index in the same pull request.” “Webhooks retry through the queue, never on a schedule.” “Anything touching billing gets the database check on review.”
Each rule is readable, dated, and traceable to the work it came from. Together with the sentence a Team owns, it defines the Team: the mandate you write, and the method that accumulates under it.
Where do proposed rules come from?
From decisions people make, not from a configuration screen.
You send the same thing back in two plans and the third arrives in the shape you wanted. You decline a proposal and the boundary it found gets written down. You request changes on a pull request and the reason is a rule rather than a one-time note. When the pattern is clear enough, the Team proposes the rule.
A proposed rule is active from the moment it is proposed. It sits behind the Playbook card on the Team page marked as proposed, and a person adopts it, which settles it, or dismisses it, which removes it and records the disagreement. Corrections take effect immediately either way. Nothing waits for a retraining cycle.
What is the difference between a business rule and a guardrail?
Who writes it, and in what language.
A product manager writes a business rule in plain words: how a claim is priced, what a customer may never be shown, which state a record has to pass through. No syntax, no prompt engineering, no ticket to an engineer.
An engineer writes the guardrail: the migration convention, the dependency policy, the test that has to exist before a change lands. Both go in the same Playbook, and both are read before a plan is written and again during review.
Can a rule be scoped to a repo or a path?
Yes, and most of the good ones are. A rule can apply to the whole Team, to one of its repositories, or to a path inside one, so the convention that governs the payments directory does not follow an Agent into the design system. Scoping is what keeps a Playbook usable as it grows: rules stay specific enough to be true.
Who owns the rules?
The Team. A rule reads as the Team’s, “the Checkout Team learned to gate schema changes on a migration plan”, never as one person’s setting.
That matters when someone is on holiday. When a rule lives in one person’s local configuration, quality depends on who is on duty. When the Team owns it, a new teammate joins the same method. It also feeds the Ladder: a line that follows the Playbook builds the record a person reads before moving it to autonomous.
What is a Play?
A bounded, multi-day run of work a Team proposes from its Playbook: the goal, the steps, what it may spend, and the deadline. A dependency upgrade across six repositories is a Play. You approve it once, and it runs over days.
Rules are the method; a Play is an instance of it. Approving one confers bounded Authority for that run only, every step still leaves a Receipt on Work, and a Play that proves out often leaves a new rule behind.
Can you take the Playbook with you?
Yes. Rules, plans, and decisions export to Confluence or Drive on request. It is your company’s judgment written down, so the door out is part of the product rather than a concession we make when asked.
Common questions
Do I have to write the Playbook myself?
No. Rules accumulate as a byproduct of people reviewing the work: you send a plan back, decline a proposal, request changes on a pull request, and the Team proposes the pattern back as a rule. You can write one directly, and you can edit any rule it proposed, but the writing is not your job.
What happens to a proposed rule before I answer it?
It is already active. A proposed rule is the Team acting on what it just learned, not a request to start. It sits behind the Playbook card on the Team page marked as proposed until a person adopts it, which settles it, or dismisses it, which removes it and records that you disagreed.
How is the Playbook different from the decision ledger?
The ledger, on Decisions, records judgment calls: what was chosen, what was rejected, and why, so the next plan reads it instead of guessing. The Playbook holds standing rules of method. A ledger entry is history that informs; a Playbook rule is an instruction that binds every run on the Team.
How is a rule different from a line's instructions?
A rule belongs to the Team and every line reads it. Instructions belong to one line: what Reeve should push back on when it reads plans, what Proctor should treat as clean on this repository. Put the convention in the Playbook and the point of view on the line.
Can we take the rules with us if we leave?
Yes. Plans, decisions, and Playbook rules export to Confluence or Drive whenever you want them. The knowledge is your company's, and the escape hatch is deliberate.