Mtg Edh Upgrade

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

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

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

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 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
• Source: guuse/claude-mtg-skills
• License: MIT

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