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.

1. 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.

1. 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 ` (€X) → add ` (€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//import.txt, .mtg/decks/edh//primer.md, and .mtg/decks/edh//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 / 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.)

• //import.txt — that variant's 100, role-tagged exactly as above (commander first, no tag).
• //primer.md — that variant's public primer ([[Card Name]] links), cross-linking the sibling variants.
• //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.

• //buylist.txt — the cards to buy for that variant, as a **raw, Cardmarket-paste-ready

list: one 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.

• //cuts-from-.md (optional) — the incremental **cut ` (€X) → add `

(€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.

• /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///. 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.

1. 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//, 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 ""), 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-"syn

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: guuse
• Source: guuse/claude-mtg-skills
• License: MIT

Install and usage instructions live in the source repository linked above.