/mercadona-shop

name: mercadona-shop
description: >-
  Do the grocery shop at Mercadona (tienda.mercadona.es) by driving the local `mercadona`
  CLI: turn a shopping list into real priced products, fill the cart, prepare delivery
  checkout, and (only on explicit go-ahead) place the order. Use this whenever the user
  wants to shop, price a grocery list, build a cart, or check out at Mercadona — including
  Spanish phrasings like "hazme la compra", "haz la compra de Mercadona", "compra en
  Mercadona", "añade X al carrito", "pídeme estos productos", "¿cuánto cuesta esta lista?",
  and English ones like "do my Mercadona shop", "price this grocery list at Mercadona",
  "fill my Mercadona cart", "order these groceries". Trigger even when the user just pastes
  a list of groceries and mentions Mercadona without saying "skill" or "CLI". Also use when the
  user wants to cook a dish or recipe and buy the ingredients at Mercadona ("quiero hacer una
  paella", "ingredientes para una cena para 6"): it asks how many people and any allergies before
  it prices, so it never guesses the headcount. Always confirm the resolved products before
  touching the cart, and never place the order without explicit consent. Do NOT use for other
  supermarkets (Carrefour, Lidl, Amazon) — this is Mercadona-only.

Mercadona shop

Turn a shopping list into a real Mercadona order by driving the `mercadona` CLI — search prices, fill the cart, set delivery, and place the order. The CLI talks to the same HTTP endpoints `tienda.mercadona.es` uses; this skill is the playbook for using it safely on a real account.

The two safety gates (read first)

This spends real money on a real account, so two points are non-negotiable:

1. **Confirm before touching the cart.** Reading and pricing are free and side-effect-free — do them freely. But before the *first* `cart add`/`cart set`, show the user the resolved plan (each list item → the exact product you picked, with id, name, size and price) and wait for an explicit OK. Product matching is fuzzy (see below), so this is where the user catches a wrong brand or size — cheap to fix now, annoying to fix after the cart is full. 2. **Never submit without explicit consent.** `checkout submit` is irreversible and places a paid order. Run it only when the user has clearly said "yes, place it" (or "dale") *for this specific order*, after you've shown them the full total. The CLI also requires `--yes` as a hard backstop — never add `--yes` on the user's behalf to "save a step".

Everything else (search, batch pricing, `cart get`, `checkout create`, `checkout slots`, `set-delivery`) is reversible and fine to run as you work toward those two checkpoints.

Spending cap (defense in depth)

On top of the two gates, put a hard euro ceiling on every cart/checkout command with `--max <eur>`, so a wrong product match or a fat-fingered quantity can't quietly run up a huge order. Choose the cap:

• the user's stated budget if they gave one ("máximo 80€", "no más de 100"); otherwise
• the agreed plan total from Gate 1, rounded up with a small margin.

Any `cart add/set/set-many/clear` or `checkout create/set-delivery/submit` whose total would exceed `--max` fails with `error: BUDGET EXCEEDED …` and a non-zero exit, so you stop instead of overspending. `set-many`/`add`/`set` refuse *before* writing (they price the basket first), so a breach leaves the cart untouched. `submit` fails **closed**: with a cap set, if it can't read the order total it refuses rather than pay. Treat a budget error as **stop-and-report** — only raise the cap if the user explicitly raises the budget. (You can also set it once for the run: `MERCADONA_MAX_EUR`, or `[limits].max_eur` in `~/.mercadona/config.toml`; precedence is flag > env > config.)

**Three different euro figures — don't conflate them:**

• **Minimum order ≈ 60€** — a *floor* the product subtotal must clear or checkout is refused. The

CLI surfaces the gap ("faltan X€…") in `cart get` and `checkout create`; if you're under, add items, don't fight it.

• **`--max` on the cart** — a *ceiling* on the product subtotal. Set it at or just above the agreed

basket total **with a little headroom**: real prices are discrete, so a "≈60€" target often lands at, say, 60.10€ — `--max 61` clears it, `--max 60` would wrongly refuse.

• **Delivery fee ≈ 8.20€** — added by the API at checkout (it's the slot price), *on top of* the

products. So the **`checkout` `--max` must cover products + fee** (e.g. a ~60€ basket → `--max 70` on `checkout create/set-delivery/submit`), while the **cart `--max` covers products only**. Using the cart cap on `submit` will refuse a perfectly fine order.

Locate the binary

Run `mercadona` from `PATH`. If it isn't installed, install it (npm `@ivorpad/mercadona`, the `curl | sh` script, or a GitHub release — see the project README) and confirm with `mercadona version`. Never hardcode a local path or a build-from-source step: this skill ships to every CLI user, not one machine.

Pin the warehouse to the user's area — ids and prices are **per-warehouse**. First check whether it's already pinned (`grep -E '^\s*(warehouse|postal_code)' ~/.mercadona/config.toml`): if a warehouse is set there (from a prior `set-postal` or `import-har`), it's done — **don't ask for the postal code again.** Only if none is set, ask their postal code and run `mercadona set-postal <cp>` once: it resolves and saves the right warehouse as the default (no login needed). Without any of this the default is `mad1` (Madrid); you can still override per-command with `--wh`/`--lang` (e.g. `--wh bcn1`). Always price and shop in the warehouse that will actually deliver.

Authenticate (bring-your-own credentials)

Reads/search need no login. Cart and checkout need a Bearer token. The catch: **password login requires a Google reCAPTCHA Enterprise token**, so it can't be done headlessly — the *first* login has to happen in a real browser. The good news: the