> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. # Playbooks > Install a whole job, ready-made, that a teammate runs on its own and earns more autonomy as you approve its work. A playbook is a whole job, ready to install: what starts it, the steps to follow, the Apps it needs and the writes it may make. Installing one sets up its [triggers](/docs/triggers.md), [schedules](/docs/routines.md) and [skills](/docs/skills.md) for you, then a teammate runs it each time an event comes in. ## Available playbooks Playbooks have their own page in the sidebar, **Playbooks**: the ones installed, then a **Catalog** of the ones you can still install. Brigade ships one today: ### Support and bugs Sorts the support inbox, answers customers, fixes the bugs they report and tells them when it is fixed. * **Apps**: **Gmail** (read and write) and **GitHub** (read and write). Optional, read-only: **Stripe**, to look up a customer, and an analytics tool (**Mixpanel** or an MCP server). * **Two roles**: one teammate answers customers; another fixes bugs in the code, in sub-threads the first one hands it. The same teammate can do both. * **Starts on**: each email to your support address in the Gmail inbox you choose. Gmail's Promotions, Social and Updates tabs and automatic replies never start a run. * **Every Monday at 08:00**: a weekly review of last week's cases, what was answered and what is still open. * **At most 100 runs a day.** Past that, new events wait, and the owner gets a ticket. ## Install a playbook Installing happens in a conversation with a teammate. 1. In **Playbooks**, choose **Install** next to a playbook in the **Catalog**. A new thread opens with a teammate, its first message ready to send. 2. The teammate asks its settings one question at a time. For Support and bugs: which teammate answers customers, which product, which Gmail account receives the mail, which address customers write to, where your public docs are, which repository bugs are fixed in, which teammate fixes them, and an optional analytics account. 3. When an App the playbook needs isn't connected or given to the teammate, it asks for it in a ticket under [Needs you](/docs/needs-you.md). Connect or grant it there. 4. The teammate offers a dry run, then a card with an **Activate** button. Nothing runs until the playbook is activated. The playbook runs on the accounts of the member who installed it, its owner. ## Dry run A dry run tries the playbook on real past events before it goes live. For Support and bugs, it replays the latest 20 emails that match its search. Each event runs as it would once active, except that every write is simulated: nothing is sent, labeled, merged or pushed. The report shows, for each event, the case it found, what it would have done, and the session minutes it took, with an estimate for a week. ## Activate Choose **Activate** on the card in the thread, or in the playbook's menu on its page. Only owners and admins can activate a playbook, since it then acts with no one checking each step. A member sees **Ask to activate** instead, which sends one ticket to owners and admins. Once active, each event starts a run. A run's thread stays out of your sidebar until a person takes part in it, by sending a message or taking control. Each run's thread has only the tools of the Apps the playbook declares. ## What it does on its own Each write a playbook may make is an action, with a level: * **Asks first**: a person approves each time, in the thread and under **Needs you**. * **On its own**: it acts without asking. * **Never**: it doesn't. Support and bugs starts with these levels: | Action | Starts at | Notes | | - | - | - | | **Reply to the customer** | Asks first | Can be limited to some kinds of case | | **Draft a reply** | On its own | | | **Label the mail** | On its own | | | **Open a pull request** | On its own | | | **Merge a pull request** | Asks first | On its own only when the checks pass | A write the playbook doesn't list always asks. Each action also has a ceiling the playbook sets, which no one can go past. ### How autonomy grows * **Your decisions build trust.** When 95% of the last 30 decisions on an action are approvals, its owner gets a ticket offering to let it act on its own. Nothing raises a level without a person. * **You change levels yourself.** On the playbook's page, under **Actions**, use an action's menu. The owner, an owner or an admin can change it. Only owners and admins can let it merge on its own. * **Mistakes send it back.** Under **Done on its own**, choose **Mark as wrong** on a call: its action goes back to **Asks first**, and trust counts again from then. On its own holds only while the action's conditions and daily caps do. Otherwise that call asks, and the level stays. ## The playbook's page Open a playbook from **Playbooks** to see its status, whose accounts it runs on, the week's numbers (runs, share unattended, first response time, bugs fixed and more), then its **Actions**, **Apps**, **Entries** (its triggers and schedules), **Settings** and **Recent runs**. From its menu, the owner, an owner or an admin can **Pause**, **Resume** or **Uninstall** it. Uninstalling removes its triggers, schedules and skills. A playbook's triggers, schedules and skills belong to it: they change only through the playbook. ## Update to a newer version When Brigade ships a newer version, the page shows "Version 1.2.0 ยท 1.3.0 available" and an **Update** button, for the owner, an owner or an admin. The update dialog shows what changes. * Your answers are kept. A new required setting is asked first, in the dialog or in a chat. * Its triggers and schedules change in place, so a Gmail trigger misses or repeats no mail. * Its skills take the new version, except one your workspace edited, which you choose to keep or replace. * Autonomy never grows with an update. An action whose tools or conditions changed goes back to **Asks first**. * Its runs, numbers and history stay, and it stays active or paused as it was. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.