# Mtg Edh Build > >- - **Type:** Skill - **Install:** `agentstack add skill-guuse-claude-mtg-skills-mtg-edh-build` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [guuse](https://agentstack.voostack.com/s/guuse) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [guuse](https://github.com/guuse) - **Source:** https://github.com/guuse/claude-mtg-skills/tree/main/mtg-skills/skills/mtg-edh-build ## Install ```sh agentstack add skill-guuse-claude-mtg-skills-mtg-edh-build ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 `` (€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. 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//`, 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](https://github.com/guuse) - **Source:** [guuse/claude-mtg-skills](https://github.com/guuse/claude-mtg-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-guuse-claude-mtg-skills-mtg-edh-build - Seller: https://agentstack.voostack.com/s/guuse - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.