---
title: Playbooks
description: Repeatable briefs for common engineering jobs. Running one opens the Build composer with the brief filled in, ready to adjust and send.
---

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

![Six playbook cards — weekly dependency bump, production error triage, two-phase schema change, flaky test quarantine, dependency CVE sweep, endpoint latency hunt — each with its steps and a Run button](../assets/screens/playbooks.webp){ width="1600" height="901" }

## 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](../workers/index.md) instead.