From mtg-skills
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 pulls proven cards from EDHREC and mtgdecks.net, fills gaps and prices everything via Scryfall (which carries Cardmarket EUR prices), and applies a disciplined 7-step methodology to produce a tuned list with per-card pricing and a budget/bracket target.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mtg-skills:mtg-commander-deckbuilderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill builds a complete, well-tuned 100-card Commander deck around any commander the user
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 and mtgdecks.net, priced through Scryfall) and a disciplined 7-step 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.
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.
Always produce two files at the end (the user expects both):
<commander>-deck.md) — cards grouped by role (Commander, Lands, Ramp,
Card Advantage, Interaction, Synergy/Themed, Win Conditions), each line showing the card name, mana
value, a one-line reason it's in the deck, and its Cardmarket price in EUR. Include the category
counts, the total deck price, the target bracket, and a short "how the deck wins" paragraph.<commander>-import.txt) — one card per line as 1 Card Name, ready to
paste into Moxfield / Archidekt / mtggoldfish. Put the commander on its own first line.Use the present_files tool to share both, and save them in their own folder under
.mtg/decks/ in the user's current working directory: .mtg/decks/<deck-slug>/deck.md and
.mtg/decks/<deck-slug>/import.txt. Create the folder if it doesn't exist. The slug is the
commander name (lowercase, spaces→hyphens, punctuation dropped), e.g.
.mtg/decks/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.
.mtg workspaceAll of this skill's file I/O lives in a .mtg/ directory in the user's current working directory,
conventionally git-ignored (built output and personal collection data, not source).
If there's no clear working directory to write to — e.g. you're running in an interactive chat with no
project folder — ask the user where the .mtg/decks/ and .mtg/collection/ directories should live
(prompt for a path) before reading or writing anything, and use that location for the rest of the session.
The subdirectories:
.mtg/decks/ — where built decks are written. Each deck gets its own subfolder,
.mtg/decks/<deck-slug>/, holding that deck's two deliverable files (deck.md and import.txt).
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.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):
references/brackets.md for the definitions and how to enforce them. Default to Bracket 2–3 if
the user is unsure.If the commander is also unknown ("just build me something fun"), help them pick one first using Step 1.
Work through these in order. Steps 2 and 6 carry the most weight — the synergy-finding in Step 2 is what
makes the deck yours, and the cutting in Step 6 is what makes it function. Full detail, rubrics, and
the reasoning behind every number live in references/methodology.md; read it before building. The
Scryfall query cookbook for each step is in references/scryfall-syntax.md.
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.
Break the commander's text into keywords (e.g. "enters", "attacks", "sacrifice a creature", "+1/+1 counter", "leaves the battlefield"). The deck wants cards that share multiple overlapping synergies with the commander — not one synergy, several — and that also synergize with each other. A good test: could this deck win without ever casting the commander? If yes, the 99 are pulling their weight.
Source the candidates primarily from EDHREC and mtgdecks.net for this commander (this is what real,
winning lists run), then use Scryfall to fill gaps the proven lists miss and to surface budget or
bracket-appropriate alternatives. Gather ~40 themed candidates; 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.
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.
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.
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.
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).
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.
Show the user the finished list before you save anything. Walk them through it briefly — the category counts, how it wins, the priciest cards, and any close calls you made (the "I kept X over Y because…" choices) — and invite changes: pet cards to slot in, cards to cut, more or less power, a tighter budget. Make the swaps they ask for (re-checking the category counts and budget each time) and keep going until they're happy. Only then run the quality checks below and write the two files.
The user wants EDHREC + mtgdecks.net as the backbone (proven inclusions) and Scryfall to fill gaps and price everything. Concretely:
https://edhrec.com/commanders/<commander-slug> (slug = lowercase, spaces→hyphens, drop punctuation,
e.g. Atraxa, Praetors' Voice → atraxa-praetors-voice). The JSON endpoint
https://json.edhrec.com/pages/commanders/<slug>.json is easier to parse when reachable. EDHREC also
has theme/budget pages (e.g. .../<slug>/budget) useful under a cap.https://mtgdecks.net/Commander then the commander's page.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-scryfall-database skill. The database is built
automatically on first use (a one-time ~540 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-scryfall-database 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:
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.web_search to surface the relevant
Scryfall search page, EDHREC page, or mtgdecks list, then web_fetch the result. web_fetch only
accepts URLs returned by a prior search, so search first (e.g. search scryfall id<=WB function:ramp),
then fetch the page that comes back. (No database can be built without code execution — that's fine,
this is the fallback.)api.scryfall.com, edhrec.com, and mtgdecks.net (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 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).
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.
prices.eur (Cardmarket, EUR). Basics are free. Sum for
the deck total and show it in the annotated file.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.Reconcile the two files first. Build the annotated list, then generate the import list from it —
don't assemble them independently, or they drift (e.g. a card you cut for bracket reasons sneaks back into
the import list). Before presenting, verify the import list sums to exactly 100 and contains the same
cards as the annotated list. 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; bracket rules satisfied (Game Changer count, combo
restrictions — see references/brackets.md); within budget if a cap was set. 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.
Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.
npx claudepluginhub guuse/claude-mtg-skills --plugin mtg-skills