# Mtg Edh Build

> Build a complete, balanced 100-card Magic the Gathering Commander (EDH) deck around a chosen commander. Use this skill whenever the user wants to build, brew, design, or upgrade a Commander/EDH deck, names a legendary creature and asks "build a deck around X", asks for a decklist for a commander, wants help picking cards that synergize with a commander, or wants a Commander deck within a budget or at a specific power bracket. Triggers on phrases like "build me a commander deck", "EDH deck for [commander]", "brew around [legendary creature]", "100-card singleton deck", "help me build my Atraxa deck", or any request that pairs a commander name with deckbuilding. The skill grounds the build in comparable proven decklists (EDHREC average/top/theme/budget pages, optionally top Archidekt/Moxfield lists), assembles a solid reference deck for the target bracket ignoring budget first, then budgets down by role-preserving swaps — prices everything via Scryfall (Cardmarket EUR), reports the deck's ACTUAL (strictly deter

- Skill: `guuse/mtg-edh-build` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add guuse/mtg-edh-build`
- Raw SKILL.md: https://api.skillmd.com/api/skills/guuse/mtg-edh-build/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Finance & Business
- Author: guuse (https://skillmd.com/u/guuse)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/guuse/mtg-edh-build

---


# MTG Commander Deck Builder

This skill builds a complete, well-tuned 100-card Commander deck around any commander the user
chooses. It combines two things: **proven card data** (what real players actually run, from EDHREC
via its JSON API, priced through Scryfall) and a **disciplined building methodology** that turns a
pile of synergistic cards into a deck that actually functions — correct card-advantage density, enough
ramp, enough interaction, the right land count, a sensible curve, and real win conditions.

A deck is not a list of the 99 most powerful cards in a color. It is a machine where the parts reinforce
each other. The whole job of this skill is to build that machine.

**The build is grounded in comparable real decklists, and the budget is hit by reduction, not by starting
cheap.** First pull the comparable proven lists for the commander and justify every inclusion by its
presence/inclusion-rate there or a clear synergy reason. Then assemble a **solid reference deck for the
target bracket *ignoring budget*** (allow a high ceiling — up to ~€1000 if that's what "solid" takes), and
only then **budget down** by swapping expensive cards, most-expensive-first, for cheaper cards that fill the
**same role/synergy**. If the budget can't be met while keeping the deck solid at the target bracket, say so
and step down a bracket rather than shipping a deck weaker than it claims. Full detail in
`references/methodology.md` — read it. Always report the deck's **actual** bracket (strictly determined per
`references/brackets.md`), not just the target.

**Build it with the user, not just for them.** After you've settled the commander and found the synergy
engine, check in on the **direction** before committing to a full 99, and present the near-final list for
reaction before writing files — invite them to swap pet cards in, push the power up or down, or change the
plan. Don't hand over a finished list as the first thing they see. Keep it light (this is a fresh build, so
fewer check-ins than an upgrade) but never one-shot: confirm the plan, then confirm the list.

## The deliverable

Always produce **three files** at the end (the user expects all three):

1. **The importable, role-tagged list** (`import.txt`) — the 100 cards as `1 Card Name`, ready to paste into
   Moxfield / Archidekt / mtggoldfish, **and** carrying each non-commander card's role tags so it doubles as the
   Moxfield tag source (no separate plain + tagged files — `import.txt` is the single source of truth). Commander
   first on its own line **with no tag**, blank line, then the 99. Tag each card with the **two-tier scheme** in
   `../mtg-edh-primer/references/tags.md`: a deck-flavoured **numbered engine** (`#1) … #2) …`, in execution
   order) then the **lettered support pillars** (`#A) Mana Advantage … #E) Lands`), `#…` unquoted, tier-ordered on
   the line. Note in `primer.md` that Moxfield's Import screen ignores `#tags` — apply them via **More → Bulk
   Edit**.
2. **The publish-ready primer** (`primer.md`) — **always created** (this is public, Moxfield-pasteable info):
   header + rating headline, TL;DR, how it wins, **card roles & tags** (the numbered-engine/lettered-pillar legend,
   then cards grouped by their most-defining tag with one-line explanations), play guide, strengths/weaknesses.
   **Link every card with Moxfield's `[[Card Name]]` syntax** (commander included) so the primer renders card
   links/hovers on Moxfield. Follow the structure + quality bar in `../mtg-edh-primer/SKILL.md`.
3. **Private status notes** (`deck.md`) — **private** working notes, *not* the public write-up: total price &
   owned-vs-needed buylist, the **build-transparency** sections below, and the **Deck Rating** scorecard. Keep the
   per-card explanations in `primer.md`, not here.
   - **Reference (pre-budget) base** — the solid target-bracket deck before budgeting, with its total price.
     (Omit only if the user set no budget cap.)
   - **Budget swaps** — every reduction as **cut `<card>` (€X) → add `<card>` (€Y)** with the shared
     role/synergy, plus the final price vs. the cap. (Omit if no cap.)
   - **Actual bracket** — the bracket the deck *actually is* by `references/brackets.md` (with the Game
     Changer count and combo/MLD/extra-turn confirmation), stated against the target if they differ, and a
     **"what's needed to go up one bracket" (and what would drop it)** note.
   - **Deck Rating** — an overall ★ rating at its bracket plus the per-dimension scorecard (see "Step 10").

Use the `present_files` tool to share all three, and **save them in their own folder under
`.mtg/decks/edh/`** in the user's current working directory: `.mtg/decks/edh/<deck-slug>/import.txt`,
`.mtg/decks/edh/<deck-slug>/primer.md`, and `.mtg/decks/edh/<deck-slug>/deck.md`. Create the folder if it doesn't exist. (Commander/EDH decks
live under `decks/edh/`; MTG Arena Standard decks live under `decks/std/`.) The slug is the
commander name (lowercase, spaces→hyphens, punctuation dropped), e.g.
`.mtg/decks/edh/atraxa-praetors-voice/`. If the user already has a folder for that commander and wants a
different build, add a short distinguishing suffix (e.g. `atraxa-praetors-voice-superfriends`) so
existing decks aren't overwritten. See "The `.mtg` workspace" below.

## Budget variants (only when asked)

The three files above are the default — **one deck**. Produce a **budget-variant ladder** *only* when the
user asks for one: multiple price points, a budget ladder, or a transition (e.g. "what can I get at €0 / €25 /
€100", or moving an owned deck to a new commander at several spend levels). Never emit variants unasked.

When you do, the deck's identity folder `<slug>/` holds **one subfolder per budget variant** — each a
**self-contained deck folder** carrying the same three files as a single deck (`import.txt`, `primer.md`,
`deck.md`) plus that variant's `buylist.txt`. Name each subfolder by its € budget (or a short name like
`cedh`); the cheapest/owned variant is **`base/`**. **Never suffix the filenames and never leave a deck at the
identity-folder root** — every list lives one level down, in a labelled variant folder. (So a folder, not a
filename, is what distinguishes variants — e.g. `meren-clan-nel-toth/base/import.txt`,
`meren-clan-nel-toth/25/import.txt`, `meren-clan-nel-toth/100/import.txt`.)

- **`<slug>/<label>/import.txt`** — that variant's 100, **role-tagged** exactly as above (commander first, no tag).
- **`<slug>/<label>/primer.md`** — that variant's public primer (`[[Card Name]]` links), cross-linking the sibling variants.
- **`<slug>/<label>/deck.md`** — that variant's **private** status notes (its price, owned-vs-needed, actual
  bracket, and Deck Rating). **One per variant** — there is no shared ladder-wide `deck.md`.
- **`<slug>/<label>/buylist.txt`** — the cards to **buy** for that variant, as a **raw, Cardmarket-paste-ready
  list**: one `<qty> <Card Name>` per line and **nothing else** (no prices, headers, or notes), so it pastes
  straight into Cardmarket's wants import. Put the **priced breakdown, totals, and the price-floor caveat**
  (cheapest copy each — a real single-seller/optimised cart costs more once shipping is counted) in this
  variant's `deck.md`, not in the buylist. The `base` variant is ~free, so it needs **no** buylist.
- **`<slug>/<label>/cuts-from-<prev>.md`** *(optional)* — the incremental **cut `<card>` (€X) → add `<card>`
  (€Y)** list for the step *into* this variant from the next-cheaper one, with the shared role and a short
  "what this step does / doesn't do" note. The `base` variant has none.
- **`<slug>/README.md`** — the **ladder index**, and the *only* file at the identity-folder root: a
  budget-variants-at-a-glance table (label · spend · actual bracket · Game Changers · one-line note), a pointer
  to the **recommended** variant, and links to each variant's folder.

Because each variant is a self-contained deck folder, the other skills (primer / upgrade / analyze) target a
**specific variant** at `.mtg/decks/edh/<slug>/<label>/`. An intermediate price point that doesn't warrant its
own folder can instead live as a documented **section** inside the nearest variant's primer (plus its priced
adds in that variant's `deck.md`) rather than a new subfolder. The term is **budget variant** (never "tier" — that already means
bracket / Standard wildcard tier; see `CONTEXT.md`).

## The `.mtg` workspace

All of this skill's file I/O lives in one **workspace** directory holding three subfolders —
`database/`, `decks/`, and `collection/`. It is resolved in this order:

1. **`$MTG_HOME`**, if that environment variable is set — the user's portable data location (e.g. a
   private `mtg-data` git repo they clone on each machine so decks + collection follow them
   everywhere; see the repo's `SYNCING.md`). Use it even if some subfolders don't exist yet — create them.
2. Otherwise the nearest **`.mtg/`** at or above the current working directory (conventionally
   git-ignored: built output and personal data, not source).

To see the resolved locations any time, run **`python scripts/scryfall_search.py --paths`** — it prints
the `decks/`, `collection/`, and `database/` paths as JSON (honouring `$MTG_HOME`) and creates nothing.
The `.mtg/…` paths written elsewhere in this skill are shorthand for "inside the resolved workspace."

**If `$MTG_HOME` is unset and there's no clear working directory to write to** — e.g. an interactive chat
with no project folder — **ask the user where the workspace should live** (prompt for a path, or suggest
they set `$MTG_HOME`) before reading or writing anything, and use that location for the rest of the session.

The subdirectories:

- **`.mtg/decks/`** — where built decks are written, **split by format**: Commander/EDH decks go
  under `.mtg/decks/edh/` and MTG Arena Standard decks under `.mtg/decks/std/`. **Each deck gets its
  own subfolder** — for this skill, `.mtg/decks/edh/<deck-slug>/`, holding that deck's three deliverable
  files (`import.txt`, `primer.md`, and `deck.md`). Create the directories if they're missing.
- **`.mtg/collection/`** — where the user's **existing card collection** lives (the cards they
  already own), so decks can be built from — or biased toward — what they have. At the **start of a
  build, check whether `.mtg/collection/` exists and holds a collection file** (a Moxfield /
  Archidekt / MTGGoldfish CSV export, or a plain `1 Card Name` text list). If it does, read it and:
  prefer cards the user already owns when two choices are otherwise close, and in the annotated
  decklist flag which cards they still need to buy and the cost of just those. If it's absent or
  empty, build normally and let the user know they can drop a collection export into
  `.mtg/collection/` to get collection-aware builds next time.

### Keeping decks in sync across machines (mtg-sync)

Decks live in the user's `mtg-data` git repo, and the user wants **every build to pull at the start
and push at the end** — the same way card data comes from mtg-db. **Don't try to judge whether
syncing is set up before acting — always run the sync commands and let the helper tell you.**
`sync.py` returns `skipped` when the workspace isn't a git repo, so an unconditional call is safe
everywhere; guessing whether to run it is exactly what makes pushing flaky.

- **At the start**, before reading the collection or writing anything, invoke **mtg-sync** to pull
  (`--pull`). This first brings down decks/collection built on another machine.
- **As the final action of the build** (see **Final step — always commit & push** at the end of this
  skill), invoke **mtg-sync** to push (`--push -m "<commander / archetype>"`), so the new deck lands
  on the repo's main branch and is available everywhere. This push runs **every time**, not only when
  you think sync is configured.

**Only the *result* is best-effort.** If the push reports `skipped` (syncing isn't set up) or
`FAILED` (e.g. offline), note it in one line and continue — the deck is saved locally and can be
pushed later. Never skip the *attempt*. To set syncing up the first time, use the **mtg-sync** skill
(`--bootstrap`).

## Before you build: always confirm bracket and budget

Two parameters change almost every card choice, so confirm them up front (the user has asked that you
always ask, unless they already stated both):

- **Power bracket (1–5)** — the official Commander power framework. This governs how efficient the
  interaction is, how many (if any) Game Changers are allowed, and whether fast/infinite combos are okay.
  See `references/brackets.md` for the definitions and the **strict determination logic**. Default to
  **Bracket 2–3** if the user is unsure. Note this is the **target**; you will report the deck's **actual**
  bracket at the end (and they can differ — a well-tuned deck with 0 Game Changers / no combos / no MLD is
  **Bracket 2**, not 3, however optimized it is).
- **Budget cap** — a total deck budget in EUR (Cardmarket pricing), or "no cap". This decides whether you
  reach for staples or for budget substitutes, and it constrains the land base most of all.

If the commander is also unknown ("just build me something fun"), help them pick one first using Step 1.

## The steps

Work through these in order. **Phase A first:** before Step 1, pull the **comparable proven decklists** for
the commander (EDHREC average/top/theme/budget via `scripts/edhrec_fetch.py`, optionally a top
Archidekt/Moxfield list) and keep them open — they are the build's backbone, and every inclusion is justified
by its inclusion-rate there or a clear synergy reason. Steps 2 and 6 carry the most weight, and **Step 8 (build
the solid reference deck, then budget down)** is what makes the price honest. Full detail, rubrics, and the
reasoning behind every number live in `references/methodology.md`; read it before building. The
**synergy-scoring loop that governs Step 2** (read → extract → map to tags → intersect → score, with the
≥2–3-points-of-contact rule) is in `references/synergy.md` — read it too. The Scryfall query cookbook for
each step is in `references/scryfall-syntax.md`.

### Step 1 — Pick / confirm the commander
The commander defines the deck's **color identity** (the only colors allowed in the 99) and its core
engine. If the user already named one, confirm its color identity and read its abilities closely. If they
haven't, offer a few options by the "rule of cool" (most fun / coolest, per the user's taste) tempered by
"don't pick something oppressive that stops others playing." Pull the exact card text from Scryfall so you
are working from the real Oracle wording.

### Step 2 — Find the themed cards (the synergy engine)
This is where the deck is won or lost, and it runs through the **synergy-scoring loop in
`references/synergy.md` — read it.** The rule it enforces: **every themed card must share at least 2–3
synergies ("points of contact") with the commander and ideally with the other cards — and the more, the
better.** A card with one point of contact is a cut candidate, not an engine card.

The loop, briefly: **(1) Read** the commander's exact Oracle text and type line (`--named`) — *you* decide
what matters. **(2) Extract** its key elements into a synergy vocabulary: triggers ("enters", "attacks", "a
creature dies", "leaves the battlefield"), actions ("sacrifice a creature", "+1/+1 counter", "create a
token", "draw"), the types it cares about, and keywords. **(3) Map** each element to a Scryfall handle —
curated **Tagger tags** `function:`/`otag:` for roles (`otag:sacrifice-outlet`, `function:card-advantage`,
`otag:token-maker`), `o:"…"` for specific phrases, `t:…` for types, `keyword:…` for keywords. **(4) Search**
each within the commander's identity and **intersect** — cards appearing under several handles are the
multi-synergy hits. **(5) Score** each candidate by its points of contact and keep the densest.

A good test of the result: *could this deck win without ever casting the commander?* If yes, the 99 are
pulling their weight. Source candidates **from the Phase-A comparable lists first** (`scripts/edhrec_fetch.py`
— the average deck, top, and high-"synergy" cards, each with an inclusion-rate you can cite), then use
**Scryfall to fill gaps** and surface spicy multi-synergy cards the aggregate buries (held to the ≥2–3 contact
bar). Gather **more than you'll keep** (~40+ themed candidates) so the reference deck has room; you'll cut
later. Apply the mana-value rubric in `references/methodology.md` as a first filter (expensive cards must earn
their slot).

**Check in on the direction here.** Before sinking time into the full build, tell the user the plan in a
couple of sentences — the theme/engine you're leaning into, how the deck intends to win, and a handful of
signature cards — and ask if that's the deck they want. This is the cheapest moment to change course (lean
more aggressive, swap the wincon, go budget, lean into a pet card). Adjust to their answer, then build.

### Step 3 — Card advantage (the hidden engine)
Dedicate **12+ cards** to *net-positive* card advantage — cards that replace themselves **and** draw more
(a card that draws 2 then discards 2 is **not** advantage). Aim ~8 of these at MV ≤ 3 and ~4 at MV ≥ 4,
with the expensive ones drawing explosively (5–6+ cards). Prefer pieces that also synergize with the
theme. Getting this right is the single biggest predictor of whether the deck works.

### Step 4 — Ramp
Include **~10–11 efficient ramp pieces** (mana rocks, mana dorks, land tutors) — cheaper is better — plus
a few **"explosive ramp"** pieces (mana doublers, rituals, treasure makers) to close games. Add more ramp
if the commander or curve is expensive, or if targeting a higher bracket.

### Step 5 — Interaction
Include **~10 dedicated interaction pieces** (removal, counterspells, protection) plus **2–4 board wipes**.
If the deck already has incidental interaction in its theme cards, trim the dedicated count by 1–2. Higher
brackets need more, and more *efficient*, interaction; lower brackets can run more synergistic/situational
pieces.

### Step 6 — Lands, then cut to 100
Run **~37–38 lands** — missing land drops loses games, so do not skimp. Mono-color decks lean on basics
plus colorless utility lands; multicolor decks need a majority of color-fixing lands and still need ~38.
Then **tally every category** and cut the themed pile down so the whole deck is exactly 100. Cut by
**curve first** (keep only 3–4 truly expensive cards) and **affinity second** (when torn between two cards,
keep the one with more synergy with the rest of the deck).

### Step 7 — Goldfish and lock in win conditions
Mentally "goldfish" the deck to ~turn 7 (play it out solo) and ask: *with a typical board, could this deck
actually win?* Ensure **3–4 real win conditions** — cards that, with the deck's normal board state, very
likely close the game. If a win con is missing, use Scryfall (search the commander's payoff keywords:
power, "loses life", artifact, etc.) to find the perfect closer and swap it in. Iterate until the deck has
a clear, repeatable path to victory.

### Step 8 — Assemble the solid reference deck (ignore budget), then budget down
What you have after Steps 1–7, with the **best** cards the comparables and synergy point to and **budget set
aside**, is the **reference deck** — the strongest honest version for the target bracket (allow a high
ceiling, up to ~€1000 if that's what solid takes). **Determine its actual bracket** (`references/brackets.md`)
and confirm it equals the target; pull back anything that drifted above (e.g. a 4th Game Changer or an early
combo) — that's a bracket fix, not a budget one.

Then, **only if a budget cap was set, budget down** (full algorithm in `references/methodology.md`): sort the
non-basics most-expensive-first and, for each, find a **cheaper card serving the same role/synergy** (same
function, color identity, comparable effect, ideally also in the comparable lists) and swap it — recording
**cut (€X) → add (€Y)** and the shared role, re-checking counts and bracket each time. If no adequate cheaper
substitute exists without weakening the deck's function or bracket, **leave that card and move on.** Repeat
until the budget is met or no beneficial swaps remain. **If the budget cannot be met while keeping the deck
solid at the target bracket, STOP, tell the user plainly, then step DOWN one bracket and rebuild/re-evaluate
there**, explaining why and what the lower bracket gets them. Keep the reference base and the swap log to show.

### Step 9 — Present the list and refine before writing files
**Show the user the finished list before you save anything** — including the **reference base, the budget
swaps, the final price, the actual bracket, and the move-up note**. Walk them through it briefly (category
counts, how it wins, the priciest cards, close calls) and invite changes: pet cards, cuts, more/less power, a
tighter budget. Make the swaps they ask for (re-checking counts, budget, and bracket each time) and keep going
until they're happy. **Only then** run the quality checks below, rank the deck (Step 10), and write the files.

### Step 10 — Rank the finished deck (★ rating)
Once the list is locked, **rate it before writing files** and embed the result in `deck.md`. Run
`python "${CLAUDE_SKILL_DIR}/scripts/analyze_deck.py" <import>.txt --commander "<name>" --json` on the final
list to pull the objective stats (curve, land/ramp/draw/interaction counts you can reconcile against your
build, the **EDHREC-rank staple signal**, Game Changer count, off-identity check, total EUR), then apply the
**five-dimension rubric in `references/rating.md`** — structure & consistency, synergy density (via
`references/synergy.md`), staples & card quality, win conditions, and bracket calibration — to award an
overall ★ rating *at the deck's actual bracket*. The rubric is **strict and evidence-based**: a deck that
merely *functions* is **★★★ (3)**, not 4, and **4–5 must be earned against the comparable lists** (score the
Staples and Synergy dimensions off the inclusion-rate / rank data from Phase A, and round **down** when the
evidence is thin). This is the same method as the dedicated **mtg-edh-analyze** skill; defer to it if you
prefer. Write a **Deck Rating** section into `deck.md`: the headline (e.g. `★★★½ (3.5/5) — a solid Bracket 2
deck`), the per-dimension scorecard with the numbers/evidence behind each, and one line on the deck's biggest
remaining weakness. Don't inflate the score because you built the deck — if it only rates 3, say 3 and name
what a comparable top list does better.

## How to drive the data sources

**EDHREC (JSON) is the backbone** for proven inclusions and **Scryfall** fills gaps and prices everything.
Full endpoint/fallback table: `references/data-sources.md`. Concretely:

1. **EDHREC JSON** — the authoritative "what comparable decks run" source. Use the bundled
   `scripts/edhrec_fetch.py "<commander>"` for staples, high-synergy cards, and the list of themes;
   `--average` for a literal ~100-card average decklist, `--theme <slug>` for a theme build, `--budget`
   for the budget list. It reads `https://json.edhrec.com/pages/commanders/<slug>.json` (slug = lowercase,
   drop `' , .`, other non-alphanumerics → `-`, e.g. *Atraxa, Praetors' Voice* → `atraxa-praetors-voice`)
   with a descriptive User-Agent + `Accept: application/json` and retry/backoff. **Never** fetch the
   Cloudflare-protected HTML at `edhrec.com`. If EDHREC 403s/404s, the script exits non-zero with a clear
   message — **fall back** to the local Scryfall DB ordered by EDHREC rank and tell the user the
   proven-inclusion data is lower-confidence.
2. **A user's existing decklist** — if they give an Archidekt or Moxfield link, run
   `scripts/import_deck.py <url>` to pull it via the site's JSON API (Archidekt `api/decks/<id>/`,
   Moxfield `api2.moxfield.com/v3/decks/all/<publicId>`). If the deck is private or the site errors, the
   script says so — ask the user to **paste** the list instead. Never invent a decklist.
3. **Scryfall** — the workhorse for filling category gaps, enforcing color identity, filtering by mana
   value, finding cards by oracle text, and **pricing**. Every Scryfall card object carries
   `prices.eur` and `prices.eur_foil`, which are **Cardmarket** prices in euros — use `prices.eur` as the
   per-card price for the deck total and for budget trimming. The query cookbook
   (`references/scryfall-syntax.md`) gives ready-made searches for each step.

**Scryfall reads come from the local card database.** The bundled `scripts/scryfall_search.py`
queries a **local SQLite database** (`.mtg/database/cards.sqlite`) built from Scryfall's bulk data
instead of hammering the API — see the **mtg-db** skill. The database is built
**automatically on first use** (a one-time ~78 MB download), so you don't need to run anything
first; just call the script. At the **start of a build**, if the script reports the data is **stale
(older than 30 days)**, tell the user prices may have moved and **ask** whether to refresh it (via
the mtg-db skill) before continuing — proceed either way. `function:`/`otag:` (Tagger)
tags aren't in bulk data, so those queries are routed to the live Scryfall API automatically.

**Retrieval mechanics — use whatever is available, in this order of preference:**

- **Code execution with network access** → run the bundled helper:
  `python "${CLAUDE_SKILL_DIR}/scripts/scryfall_search.py" "<query>" --limit 30`. It reads the local database (auto-building
  it on first use), enforces color identity, and prints each card's name, mana value, type, and EUR
  price (cheapest printing) as JSON or a table. This is the fastest, most reliable path. Run
  `python "${CLAUDE_SKILL_DIR}/scripts/scryfall_search.py" --help` for options. The script also fetches a single card's full
  details and price with `--named "Sol Ring"`. `function:` queries transparently use the live API.
- **No code-execution network, but web tools available** → `web_fetch` the **JSON** endpoints directly
  (they parse cleanly and don't need scraping): `https://json.edhrec.com/pages/commanders/<slug>.json`
  for staples/themes, `.../average-decks/<slug>.json` for the average list, and the Scryfall search page
  for card data. If `web_fetch` needs a URL from a prior search, `web_search` for the Scryfall query or
  the EDHREC commander page first. (No database can be built without code execution — that's expected,
  this is the fallback.)
- If neither has network to these domains, tell the user their environment needs network access to
  `api.scryfall.com` and `json.edhrec.com` (in Claude.ai/Code this may need enabling in settings, or an
  org owner may need to allow those domains), and offer to proceed from your own MTG knowledge with the
  caveat that prices, proven inclusions, and the latest cards won't be verified.

Once the database exists, queries are local and fast; only `function:` tags and a stale-data refresh
touch the network. If there's no clear working directory to write the database to, prompt the user for
a path for `.mtg/` first (see "The `.mtg` workspace" above).

## Putting it together — the target shape of a 100-card deck

Categories overlap (a treasure-making rock is ramp *and* sac fodder); count each card by its **primary**
role so the totals add to 100. A typical balanced build:

| Category | Count |
|---|---|
| Commander | 1 |
| Lands | 37–38 |
| Ramp | 10–12 |
| Card advantage (draw) | 12–13 |
| Interaction (incl. 2–4 board wipes) | 10–12 |
| Themed / synergy / payoffs / win conditions | remainder (~24–28) |

Adjust within these ranges for the commander and bracket, but treat large deviations (e.g. 30 lands, or 6
pieces of card advantage) as red flags to fix, not features.

## Budget and pricing

- Price every non-basic card with its Scryfall `prices.eur` (Cardmarket, EUR). Basics are free. Sum for
  the deck total and show it in `deck.md` — for both the **reference base** and the **final** deck.
- **Hit a budget cap by reducing the reference deck, not by starting cheap** (Step 8 / `methodology.md`):
  iterate the non-basics most-expensive-first and swap each for a **cheaper card serving the same
  role/synergy** (same function, color identity, comparable effect, ideally also in the comparable lists).
  The land base is usually where the most money hides (premium duals → taplands/basics), so the top of the
  price list yields the biggest savings first. If no adequate cheaper substitute exists without weakening the
  deck, **leave that card** and move on. If the cap can't be met while keeping the deck solid at the target
  bracket, **stop and step down a bracket** rather than shipping a weaker deck under a higher label.
- Show **every swap** as **cut `<card>` (€X) → add `<card>` (€Y)** with the shared role, plus final price vs.
  cap.
- Note honestly that `prices.eur` is Cardmarket market price and can move; for an exact Cardmarket
  *average sell* on a specific pricey card, the user can check that card's Cardmarket page directly.

## Quality bar before you hand it over

**Reconcile the files first.** Lock the 100-card list, then build `import.txt` (with its role tags) and write
`primer.md` and `deck.md` *from that same locked list* — don't assemble them independently, or they drift (e.g. a
card you cut for bracket reasons sneaks back into one file). Before presenting, verify `import.txt` sums to exactly
100 and that `primer.md`'s card lines match it. A one-line check works:
`awk '{s+=$1} END{print s}' <import>.txt` must print `100`, and
`sed 's/^[0-9]* //' <import>.txt | sort | uniq -d` must print nothing (no duplicate names; Commander is
singleton). This catches the most common failure mode: a popular card you deliberately excluded (a Game
Changer, or a combo piece above the bracket) reappearing in the import list.

Then re-read `references/methodology.md` and confirm: exactly 100 cards including the commander; ~38 lands;
≥12 net-positive card-advantage pieces; ≥10 ramp; ~10 interaction + 2–4 wipes; 3–4 real win conditions;
every card legal in the commander's color identity; the deck's **actual bracket** determined per
`references/brackets.md` (Game Changer count + combo/MLD/extra-turn limits) and matching the target (or the
difference stated); the **reference base, budget swaps, final price, actual bracket, and move-up note** all
present; within budget if a cap was set (or the honest stop reported). Only then present the files.

**Double-check colors:** confirm every card's color identity is within the commander's — vet with
`id<=<identity>` (NOT `c:`, which also matches off-identity multicolor cards) and glance at the search
**CI** column for each card. A single off-identity pip makes the card illegal in the deck.

**Include the rating:** `deck.md` must carry the **Deck Rating** section from Step 10 — the overall ★ rating
at the bracket and the per-dimension scorecard. Don't deliver a deck without it.

## Final step — always commit & push (every build ends here)

This is the step that gets missed, so treat it as part of the deliverable, not an afterthought.
**After the three files are written and presented, the last thing you do — every single time — is push
them** by invoking the **mtg-sync** skill: `--push -m "<commander / archetype>"`.

Run it **unconditionally**. Do *not* first reason about whether the workspace is a synced repo — just
run it. The helper handles every case and reports back:

- **`ok` (committed + pushed)** → confirm in one line that the deck was pushed to the `mtg-data` repo's
  main branch.
- **`skipped`** → the workspace isn't a synced git repo; say so in one line and stop (offer
  `--bootstrap` via mtg-sync if they'd like syncing set up).
- **`FAILED`** → e.g. offline or an auth issue; say so in one line — the deck is committed/saved
  locally and can be pushed later.

Only the *handling of that result* is best-effort. The **attempt is mandatory** — never end a build
without running the push.