> ## Documentation Index
> Fetch the complete documentation index at: https://gump.build/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Explore the Playbook

> Before writing your own workflows, explore what's already available.

# Explore the Playbook

Before writing your own workflows, explore what's already available. Gump ships with 7 built-in workflows covering the most common engineering patterns.

## List available workflows

```bash theme={null}
gump playbook list
```

```
Gump Playbook

  freeform            Single agent, no plan                      (built-in)
  tdd                 Test-first, implement, verify              (built-in)
  cheap2sota          Start cheap, escalate on failure           (built-in)
  parallel-tasks      Decompose, build all tasks at once         (built-in)
  implement-spec      Decompose, implement, adversarial review   (built-in)
  bugfix              Reproduce first, then fix                  (built-in)
  refactor            Change structure, keep behavior            (built-in)
```

## Inspect a workflow

```bash theme={null}
gump playbook show tdd
```

This prints the full YAML of the workflow — every step, every gate, every retry rule. You can copy and customize it.

## Which workflow to pick

The choice depends on what you're doing:

**Quick experiments** — Start with `freeform`. Single agent, no plan, no decomposition.

**Everyday tasks** — Use `cheap2sota`. Cheapest first, escalates only on failure.

**Quality-sensitive work** — Use `tdd` for test-driven development, or `implement-spec` for adversarial review with convergence.

**Large specs** — Use `parallel-tasks` if tasks have disjoint file scopes. Otherwise, `cheap2sota` or `tdd` process tasks sequentially.

**Bugs** — Use `bugfix`. It enforces the "reproduce first, fix second" discipline.

**Refactoring** — Use `refactor`. It validates that existing tests stay green after every change.

Each workflow is documented in detail in the Playbook section, with the full YAML, an explanation of how it works, and customization hints.

## Override a built-in

If you want to customize a built-in workflow, copy it to your project:

```bash theme={null}
gump playbook show cheap2sota > .gump/workflows/cheap2sota.yaml
```

Edit the file. Project workflows take priority over built-in ones — next time you run `cheap2sota`, Gump will use your version.

Workflows are looked up in this order:

1. Project: `.gump/workflows/<name>.yaml`
2. User: `~/.gump/workflows/<name>.yaml`
3. Built-in: shipped with Gump