# Mtg Edh Upgrade > >- - **Type:** Skill - **Install:** `agentstack add skill-guuse-claude-mtg-skills-mtg-edh-upgrade` - **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-upgrade ## Install ```sh agentstack add skill-guuse-claude-mtg-skills-mtg-edh-upgrade ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # MTG Commander Deck Upgrader This skill takes a Commander deck the user **already has** and makes it meaningfully better. It uses the same proven building methodology as the deckbuilder — the target shape of a functioning 100 (right land count, enough card advantage, enough ramp, enough interaction, a sensible curve, real win conditions) — but applies it as a **diagnosis-and-swap** pass: find where the current list is weakest, then spend a (usually small) budget on the changes that fix the most for the least. The core idea: **an upgrade is not a rebuild.** A few well-chosen swaps often improve a deck far more than their cost suggests. Respect what the user already owns and likes; change what's actually holding the deck back. **Work interactively — this is a conversation, not a one-shot transform.** The user knows how their deck actually plays; you know the card pool and the methodology. Combine them: ask what's wrong, react to what they tell you, propose changes in digestible batches, and refine based on their feedback. Do **not** dump a finished 100-card list and call it done. Talk through your reasoning, surface options, and only write the final files once the user has agreed to the changes. Default to asking a question rather than assuming. ## Start here: paste your decklist The user provides their **current decklist inline** in their prompt (pasted text — a Moxfield/Archidekt export, a `1 Card Name` list, or even a rough list). Begin by parsing it: - Identify the **commander** and its **color identity** (the only colors legal in the 99). Pull the real Oracle text from Scryfall. - Read the **theme/engine** the deck is already going for — don't impose a new plan, sharpen the existing one (unless the user asks to re-pivot). - **Price and categorize** every card via Scryfall (`prices.eur`, Cardmarket), tallying the current category counts (lands / ramp / card advantage / interaction / themed / win cons) and the total value. If the pasted list is short of 100, malformed, or ambiguous, say what you found and ask the user to confirm before proceeding. ## Ask what's wrong and what they want improved Before you diagnose anything yourself, **ask the user what they think is wrong with the deck and what they want it to do better.** They've played it; that's information you can't get from the list alone. Ask in plain language (a few questions, not a wall) — for example: - **What does it struggle with?** Slow starts / mana problems, runs out of cards, can't close games, folds to board wipes or removal, loses to a particular deck or player at your table. - **What do you want it to do better?** Faster, grindier, more resilient, lean harder into the theme, hit a higher or lower power level. - **What's off-limits or precious?** Pet cards you want to keep, cards you already own vs. won't buy, things you've tried that didn't work. Let their answers steer the upgrade — **their lived pain points outrank your own read** when they conflict. But if your tally later surfaces a problem they didn't mention (e.g. only 33 lands, or two pieces of card advantage), **raise it and ask** whether they want it addressed rather than silently "fixing" it. ## Then confirm: bracket and upgrade budget Two parameters, same as the builder — confirm them up front unless the user already stated both: - **Power bracket (1–5)** — where the user wants the deck to land (it may differ from where it is now). See `references/brackets.md` for the **strict determination logic**. Default to keeping the deck at its current bracket if unsure. This is the **target**; you'll report the deck's **actual** bracket (before and after) determined from concrete signals — and a tuned deck with 0 Game Changers / no combos / no MLD is **Bracket 2**, not 3, however optimized. - **Upgrade budget cap** — a total spend in EUR (Cardmarket) for the changes, or "no cap". **Because this is an upgrade, the budget can be much lower than building from scratch** — even €10–30 of well-targeted swaps can noticeably improve a deck. Ask for their cap, suggest that a small budget is fine, and make the spend count: prioritize the cheapest changes that fix the biggest weaknesses first. ## The deliverable Always produce **three files**, saved 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 missing; slug = the commander name, kebab-case, with a suffix like `-upgraded` if a folder already exists). (Commander/EDH decks live under `decks/edh/`; MTG Arena Standard decks live under `decks/std/`.) See "The `.mtg` workspace" below. 1. **The importable, role-tagged list** (`import.txt`) — the upgraded 100 as `1 Card Name`, commander first on its own line **with no tag**, blank line, then the 99, each non-commander card carrying its **two-tier role tags** (deck-flavoured numbered engine `#1) …` then lettered pillars `#A) … #E) Lands`, `#…` unquoted, tier-ordered) per `../mtg-edh-primer/references/tags.md`. This single file is both the import **and** the Moxfield tag source — no separate plain/tagged files. Generate it *from* the locked upgraded list so nothing drifts. (Moxfield's Import screen ignores `#tags`; apply them via **More → Bulk Edit** — say so in `primer.md`.) 2. **The publish-ready primer** (`primer.md`) — **always created** (public, Moxfield-pasteable): 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). Follow `../mtg-edh-primer/SKILL.md`. 3. **Private status notes** (`deck.md`) — **private** working notes, *not* the public write-up. **Open with the "Changes" section** that is the heart of an upgrade: each change as **— Cut `` (€X) → Add `` (€Y) (shared role/reason)**, grouped by the weakness it fixes, plus the **total upgrade spend vs the budget cap** and a short "what these changes do" paragraph. Include an **Actual bracket** line — the bracket the upgraded deck *actually is* by `references/brackets.md` (with Game Changer count and combo/MLD/extra-turn confirmation), stated against the target if they differ, plus a **"what's needed to go up one bracket" (and what would drop it)** note. Close with a **Deck Rating** section — an overall ★ rating at the actual bracket plus the per-dimension scorecard, **before vs. after** (see "Step 6 — Rank the upgraded deck"). Keep per-card role explanations in `primer.md`, not here. Use the `present_files` tool to share all three — but **only at the end**, once the user has agreed to the changes through the interactive method below. The files are the record of a conversation, not its opening move. ## Budget variants (only when asked) The three files above are the default — **one** upgraded deck. Produce a **budget-variant ladder** *only* when the user asks for one: an upgrade path at several spend levels (e.g. "what does €25 vs €100 of upgrades get me"), or a transition that ladders. Never emit variants unasked. When you do, follow the **same layout as `mtg-edh-build`** (see its "Budget variants" section): the identity folder `/` holds **one subfolder per variant**, each a self-contained deck folder — `//` with its own `import.txt` (role-tagged), `primer.md` (public, `[[Card Name]]` links, cross-linking siblings), `deck.md` (that variant's private status — **one per variant**, not shared), and `buylist.txt` (a **raw, Cardmarket-paste-ready** ` ` list — prices, totals, and the price-floor caveat go in that variant's `deck.md`, not in the buylist). The user's current list is the **`base/`** variant (no buylist); an optional `cuts-from-.md` per step documents the incremental cut→add list; and a single `/README.md` at the root indexes the ladder and names the recommended variant. **No suffixed filenames, no shared root deck.md, no plain-`import.txt` alias** — every list lives in a labelled subfolder. The term is **budget variant**, never "tier" (see `CONTEXT.md`). ## The `.mtg` workspace All of this skill's file I/O lives in one **workspace** directory holding `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 writing anything, and use that location for the rest of the session. The subdirectory: - **`.mtg/decks/`** — where upgraded decks are written, **split by format**: Commander/EDH under `.mtg/decks/edh/` and MTG Arena Standard under `.mtg/decks/std/`. **Each deck gets its own subfolder** — for this skill, `.mtg/decks/edh//`, holding `import.txt`, `primer.md`, and `deck.md`. This is the same decks folder the other deckbuilding skills use. Create the directories if they're missing. (The pasted decklist is taken from the prompt, not a file — there's no input file to read.) ### Keeping decks in sync across machines (mtg-sync) Decks live in the user's `mtg-data` git repo, and the user wants **every upgrade 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 writing anything, invoke **mtg-sync** to pull (`--pull`), bringing down any decks built on another machine first. - **As the final action of the upgrade** (see **Final step — always commit & push** at the end of this skill), invoke **mtg-sync** to push (`--push -m ""`), so the upgraded 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`). ## The method (diagnose, then upgrade) The target shape of a functioning 100 and the reasoning behind every number live in `references/methodology.md` — read it before diagnosing. The **synergy-scoring loop** for choosing adds (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 finding upgrade candidates is in `references/scryfall-syntax.md`. Work in this order: ### Step 1 — Diagnose the current list against comparable lists, then talk it through First **pull the comparable proven decklists** for the commander (`scripts/edhrec_fetch.py ""` for top/high-synergy with inclusion rates, `--average`, `--theme`/`--budget`) — they're the benchmark and the source of candidates. Tally the existing deck and compare it to the methodology's targets *and* to those inclusion rates: ~37–38 lands, **12+ net-positive** card-advantage pieces, ~10–11 ramp, ~10 interaction + 2–4 board wipes, 3–4 real win conditions, a sensible curve, color-identity legality. Note the **biggest gaps** — too few lands, thin card advantage, inefficient interaction, a top-heavy curve, no clear closer, or low-inclusion filler where the proven lists run high-inclusion staples. **Also determine the deck's ACTUAL bracket now** from the signals in `references/brackets.md` (Game Changer count, early two-card combos, MLD, chained extra turns, fast mana + tutor density) and compare it to the target — don't inflate a tuned-but-vanilla deck to B3. Then **share a short, readable diagnosis** and reconcile it with what the user told you in "Ask what's wrong": where do their complaints and your tally agree, and where does your tally (or the bracket determination) reveal something they didn't raise? **Agree on the top 2–3 priorities together before proposing any cards.** ### Step 2 — Rank upgrade candidates by impact per euro For each gap, gather candidates **primarily from EDHREC's JSON API** (`scripts/edhrec_fetch.py ""` — what proven lists run that this deck lacks), then fill with **Scryfall** for budget- and bracket-appropriate options (`references/scryfall-syntax.md`). Favor cards that fix a real weakness *and* synergize with the existing theme. Cheaper-but-sufficient beats expensive-but-marginal — the goal is the most improvement within the cap. **Hold every *themed* add to the synergy bar in `references/synergy.md` (read it):** each must share at least **2–3 points of contact** with the commander and the rest of the deck — more is better. Run the loop on the existing deck's vocabulary: **read** the commander's Oracle text, **extract** its key elements, **map** each to a Scryfall handle (curated `function:`/`otag:` Tagger tags first — `otag:sacrifice-outlet`, `function:card-advantage`, `otag:token-maker` — then `o:"…"`, `t:…`, `keyword:…`), **search and intersect**, and **score** candidates by points of contact, taking the densest. A swap that drops a one-note card for a card pulling 2–3 jobs is exactly the kind of high-impact upgrade this skill is for. (Structural fixes — lands, generic ramp, catch-all interaction — fill required roles and are exempt, but prefer the version that also synergizes.) ### Step 3 — Choose the swaps (what to cut) For every add, name the **cut**: the weakest card serving the same or a lower-priority role (off-theme filler, an overcosted card the curve doesn't need, a win-more card, a strictly worse duplicate effect). Keep the deck at exactly **100**. Don't cut cards the user flagged as favorites unless they're clearly hurting the deck — and if so, explain why and offer the choice. ### Step 4 — Respect budget and bracket (role-preserving swaps; honest stop) Keep the running spend under the cap. If a high-impact add blows the budget, find a **cheaper card serving the same role/synergy** — same function, color identity, comparable effect, ideally also in the comparable lists (`function: id` filtered by `eur.txt --commander "" --json` to pull the objective stats (curve, category counts, **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 — for 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 Staples/Synergy off inclusion-rate/rank data, round **down** when evidence is thin). This is the same method as the dedicated … ## 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-upgrade - 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%.