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` ```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: 1. Run `dd-cli order reorder --help` and `dd-cli order checkout-url --help` to confirm flags. 2. On the first real recall, after running `reorder`, confirm the output contains a cart-uuid and that `dd-cli cart show --cart-uuid <it>` works. 3. Record the outcome in `preflight.verified` (+ any format notes in `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": 1. **Match**: fuzzy-match the request against playbook names and `contexts`. Ambiguous → ask. No match → offer Flow 2 (capture) instead. 2. **Rebuild**: `dd-cli order reorder --order-uuid <stored uuid>`. Capture the cart-uuid from the output. 3. **MANDATORY diff**: run `dd-cli cart show --cart-uuid <cart-uuid>` and compare against the stored `items_summary` + `baseline_total`: | | Stored | Current | |---|---|---| | Harvest Bowl | $13.95 | $14.95 ⬆ | | Lemonade | $3.50 | ❌ missing | | **Subtotal** | **$17.45** | **$14.95** | Present the diff table to the user. Never skip this step, even when everything matches — say "matches your baseline" explicitly. 4. **Gate**: if items are missing/substituted, or the subtotal exceeds `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. 5. **Checkout**: only after the diff is shown (and approved when the gate 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. 6. **Update**: bump `last_used` / `times_used`; if the user accepted new 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: 1. `dd-cli order history` — take the most recent order's uuid. 2. Ask for a name and optional context words ("when should I suggest this?"). 3. Write the entry with `items_summary` and `baseline_total` from the cart that was just built (or from the history entry if it shows detail). 4. Default `tolerance_pct`: 10. ## Flow 3 — Staleness / self-heal When `order reorder` fails or the diff shows the restaurant no longer offers the stored items: 1. Tell the user the playbook is stale and why. 2. `dd-cli search --query "<restaurant name>"` — confirm the restaurant still exists on DoorDash. Gone → offer to retire the playbook or find a replacement. 3. Rebuild an equivalent cart (`cart add-items`, navigating with `--help` as needed), confirm with the user, and after a successful checkout-url handoff refresh the playbook's `order_uuid` from `dd-cli order history`. ## Rules - **Never emit a checkout URL without showing the diff first.** This is the contract of the skill. - Read uuids from real command output; never fabricate or guess them. - One capture offer per order, max. Respect a "no". - Totals you can verify are pre-fee subtotals; final totals (fees, tip, tax) appear only on the DoorDash payment page. Say so. - If `dd-cli` reports auth/waitlist errors, stop and tell the user to run `dd-cli login` — don't retry in a loop.