How to use a playbook
A playbook is a numbered rubric for a fork engineering teams hit again and again. Not a checklist. Not a 40-page architecture-decision-record template. A short, opinionated set of questions in a deliberate order — and a default pick for when the meeting is going in circles.
- Triggers — what shape of problem this playbook is for. If your situation isn't on the list, the playbook isn't your tool.
- Signals — preconditions that mean you're actually ready to decide. If these aren't true, you're scoping, not deciding.
- The rubric — numbered criteria, weighted decisive · heavy · tiebreaker. Walk them in order; the first decisive answer often ends the meeting.
- Red flags — patterns that mean the playbook isn't your real problem. Worth ten minutes before picking up the rubric.
- Default pick — what to do if the rubric doesn't separate the options. An opinion, not a vote count.
- Applications — short examples of the playbook used in real teams, with context and outcome. Where possible, linked to a full decision brief.
Why opinionated?
Most decision frameworks try to be neutral. They produce checklists that make every option look reasonable, and that's exactly the failure mode we wanted to fix. A playbook here picks a side. If your context disagrees with the default — great, write down what your context is and ship the other option. The playbook gave you the words for the disagreement, which is what makes the next decision faster.
How does this fit with the briefs?
The Decision Library is post-hoc: real decisions that were made, anonymized, with the memo and the outcome. The Playbook is a-priori: the rubric you reach for before the decision, so the brief writes itself. Together: rubric → memo → outcome → next time, a sharper rubric.
Where does the product fit?
crastinating.pro is the decision queue that turns a stalled ticket into a brief. The Playbook is what the brief is written against — the shared rubric that makes "we picked option (b)" mean something specific instead of something vague.