Doordash Order Playbooks

DoorDash Order Playbooks

Saved orders with names and contexts, recalled safely. A playbook maps a

human name ("post-gym", "late-night deploy", "Friday ramen") to a concrete

DoorDash order that can be rebuilt with dd-cli order reorder — plus enough

stored detail to detect drift (menu changes, price hikes, substitutions)

before the user is ever handed a checkout link.

Unofficial community skill built on DoorDash's doordash-oss/doordash-cli.

dd-cli must be installed, on PATH, and logged in (dd-cli login).

Why this exists

dd-cli order history already lists past orders — but Claude has no

cross-session memory of *which* order is "the post-gym one", and plain

reordering silently accepts whatever the restaurant's menu says *today*:

substituted items, missing items, higher prices. This skill stores the

mapping AND makes a cart-diff against the stored baseline mandatory

before emitting any checkout URL. Silent drift becomes a caught event.

State

Single JSON file: ~/.claude/dd-cli/playbooks.json

{
  "playbooks": {
    "post-gym": {
      "order_uuid": "<uuid from dd-cli order history>",
      "restaurant": "Sweetgreen",
      "items_summary": [
        { "name": "Harvest Bowl", "qty": 1, "price": 13.95 },
        { "name": "Lemonade", "qty": 1, "price": 3.5 }
      ],
      "baseline_total": 17.45,
      "tolerance_pct": 10,
      "contexts": ["post-gym", "gym", "workout"],
      "last_used": "2026-07-19",
      "times_used": 4
    }
  },
  "preflight": { "verified": false, "notes": "" }
}

Create the directory and file on first use (mkdir -p ~/.claude/dd-cli).

Prices are pre-fee subtotals — say so when presenting totals.

Preflight (first use only — REQUIRED)

This skill assumes dd-cli order reorder --order-uuid Y returns a cart-uuid

that cart show and order checkout-url accept. That handoff is

load-bearing and must be verified empirically once per install:

to confirm flags.

contains a cart-uuid and that dd-cli cart show --cart-uuid <it> works.

preflight.notes) so future sessions skip this step.

If the handoff does NOT work as assumed, fall back to rebuilding the cart

manually (dd-cli search → cart add-items) and record that in

preflight.notes.

Flow 1 — Recall (the main flow)

User says something like "order my post-gym bowl" / "the usual after the gym":

Ambiguous → ask. No match → offer Flow 2 (capture) instead.

the cart-uuid from the output.

compare against the stored items_summary + baseline_total:

Present the diff table to the user. Never skip this step, even when

everything matches — say "matches your baseline" explicitly.

baseline_total by more than tolerance_pct, STOP and ask the user how

to proceed (accept, edit cart via cart remove-item/cart add-items, or

abort). Do NOT hand over a checkout link silently.

tripped): dd-cli order checkout-url --cart-uuid <cart-uuid>. Hand the

URL to the user — payment always happens on the DoorDash page, by the

human.

prices, offer to refresh items_summary and baseline_total.

Flow 2 — Capture

After ANY completed order (via playbook or bespoke), offer once — don't nag:

"Want to save this as a playbook?" If yes:

that was just built (or from the history entry if it shows detail).

Flow 3 — Staleness / self-heal

When order reorder fails or the diff shows the restaurant no longer offers

the stored items:

exists on DoorDash. Gone → offer to retire the playbook or find a

replacement.

needed), confirm with the user, and after a successful checkout-url

handoff refresh the playbook's order_uuid from dd-cli order history.

Rules

contract of the skill.

appear only on the DoorDash payment page. Say so.

dd-cli login — don't retry in a loop.