doordash-order-playbooks

name	doordash-order-playbooks
description	Named, context-bound saved DoorDash orders ("post-gym", "late-night deploy") recalled through the DoorDash CLI (dd-cli) with a mandatory cart-diff before any checkout link is handed over. Use when the user names a saved order ("order my post-gym bowl", "the usual", "my Friday ramen"), wants to save the order they just placed as a playbook, or asks to list/remove saved orders. Persists name→order-uuid playbooks across sessions, catches silent menu/price drift on every recall, and self-heals stale playbooks when a restaurant's menu changes. Requires dd-cli (macOS Apple Silicon, waitlist-gated).
allowed-tools	Bash(dd-cli:*), Bash(command -v:*), Bash(mkdir:*), Bash(cat:*), Bash(jq:*), Read, Write, Edit
tags	["DoorDash","Food Delivery","CLI","Saved Orders","Reorder","Automation"]

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:

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.