Playbooks
Repeatable briefs for common engineering jobs. Running one opens the Build composer with the brief filled in, ready to adjust and send.
On this page
Playbooks are ready-made briefs for jobs teams run again and again. Running one opens the Build composer with the brief filled in; you choose the repository, adjust anything, and send.
The playbooks#
| Playbook | What it asks for |
|---|---|
| Weekly dependency bump | Minor and patch upgrades in one pull request; major upgrades split out with a risk note. Check outdated → bump and run the suite → one PR per major. |
| Production error triage | Reproduce the top new issue, find the release that introduced it, propose the smallest fix with a test. |
| Two-phase schema change | An additive migration, backfill in batches, verify counts, then drop the old shape. |
| Flaky test quarantine | Run the suspect test many times, quarantine it, then find the shared-state cause. |
| Dependency CVE sweep | Audit dependencies, patch the vulnerabilities your code can actually reach, note the rest. |
| Endpoint latency hunt | Profile the slowest route and land one measurable improvement. |
The same playbooks appear as Start from cards under the composer on the home screen.
How playbooks behave#
A playbook is a brief, not a stored automation. Running one starts an ordinary session: the same planning, checks, review and delivery rules apply, and you can edit the brief before sending.
To run something on a schedule — every Monday, every hour — use a worker instead.