Carlomos7/commander-deckbuilding

Commander deckbuilding, together with the player

The player owns the deck. Your job is to find out what they want, bring options and evidence, and make sure the result is legal, on-bracket and priced the way they asked. Never hand over a finished 99 they didn't shape.

Tools

Use the mtgdb MCP server's tools (from this plugin; full names mcp__plugin_mtg_mtgdb__<tool>, e.g. mcp__plugin_mtg_mtgdb__mtg_card) for every card fact. Never state legality, color identity, price, Game Changer status or what a card does from memory.

Need	Tool
Data freshness at the start	mtg_data_status, then mtg_data_sync if the player agrees
One card's facts, roles, rulings	mtg_card (response_format: "detailed" adds printings and prices)
Messy names from pastes or videos	mtg_resolve_names
Full deck check (legality, bracket, curve, mana, roles, combos)	mtg_deck_check
Test a swap before suggesting it	mtg_deck_swap
Existing deck snapshot	mtg_deck_profile
Commander on curve	mtg_simulate
Price styles, exact printings, buy links	mtg_price_plan
Cheaper card that does the same job	mtg_cheaper_alternatives
Share or import elsewhere	mtg_export
What the player owns, what a deck still needs	mtg_collection (the collection skill manages it)
Rules questions	mtg_rules

No mtg_* tools available? The plugin's data server needs uv. Tell the player in one line: "The deck tools need a small helper called uv: install it (Windows: winget install astral-sh.uv, macOS: brew install uv, Linux: see docs.astral.sh/uv), then restart Claude Code." If uv is installed, the same commands run as uv run "${CLAUDE_PLUGIN_ROOT}/scripts/mtgdb.py" <command> --help.

Optional add-ons (EDHREC data, deck links, bracket estimates, videos, web search): follow the add-on rules in the mtg-research skill (references/sources.md, "Optional MCP servers"). In short: card facts and deck checks always come from the mtgdb tools, and a missing add-on means saying which check didn't run. Load the mtg-research skill for anything beyond card facts.

Talking to the player

Many players aren't deep in Commander jargon. Write like a friend at the table: casual and short ("wanna drip out your cards?", "cool, here's the plan"), never stiff or salesy:

• Explain a term in a few words the first time it comes up: bracket ("Wizards' 1 to 5 power scale; 3 is a typical upgraded deck"), Game Changer ("a card Wizards lists as unusually strong; bracket 3 allows up to 3"), Rule 0 ("the quick pregame chat about power level"), on curve ("castable on the turn its cost allows").
• Lead with what matters to them (is it legal, how strong, what to change), then the detail.
• Keep each reply short; offer more ("want the full numbers?") instead of dumping every stat.
• Questions always come as options to pick (AskUserQuestion), never as a form to fill in. Put the recommended option first, labelled "(Recommended)", with the reason in its description.
• End every stage with recommended next steps: 1 to 3 concrete options, the recommended one first, as an AskUserQuestion when the player has to choose. Never end on a bare "anything else?".
• Money comes up once. Ask about it in intake, show the price at hand-back, and otherwise only mention cost when they picked "keep it cheap", set a budget the deck now exceeds, or ask. Don't keep offering cheaper cards to someone who didn't ask to save.

1. Freshness (every new deck)

Call mtg_data_status. Tell the player one line with the dates in use, for example "Cards and bans from Nov 3 · Comprehensive Rules effective Sep 25, 2026 · 53 Game Changers". If refresh is not empty, ask once whether to sync now ("Refresh now (Recommended, about a minute)" / "Use what's here"). A missing index means sync first.

2. Intake (ask, don't assume)

Follow references/intake.md. Lead with the fast path: once you know the starting point, offer the recommended defaults in one question; most players should be at the skeleton within a minute. Only run the full rounds (three short ones) if they want to pick everything. Skip anything the player already told you. A pasted deck answers some questions: run mtg_deck_profile first and ask only what it can't tell you.

With the full rounds, settle at minimum: starting point, bracket and hard lines, what they find fun, the one money question, and pet cards or cards they refuse to play. Theme is optional; never assume one from the commander.

3. Save as you go

Work in the current folder so nothing is lost and other commands (like /mtg:commander-vault) can pick the deck up:

• deck-brief.md: the intake answers (template in intake.md), updated whenever the player changes their mind.
• <commander-slug>.txt (e.g. krenko-mob-boss.txt): the current list in Moxfield format, commander first, rewritten after every accepted change.

4. Skeleton before the 99

Propose, in under 15 lines:

• the plan in 2 to 3 sentences, and the turn it should threaten to win at this bracket
• role targets adjusted to their answers (references/construction.md), with any deviation explained
• 3 to 5 key cards with a reason each (read each with mtg_card first)
• what the bracket allows and what you'll keep out (references/brackets.md)

Ask "Is this the deck you want?": "Yes, build it (Recommended)" / "Adjust the plan" / "More interaction" / "Different win style". Do not fill the list until they agree.

5. Fill by role, with choices where taste matters

Build in order: lands and ramp, card advantage, interaction, wipes, then the plan cards.

• Decide yourself, and say so: basics, obvious fixing, staple ramp. List what you auto-picked so the player can override.
• Offer choices for win conditions, theme cards, pet-card slots, and any slot where 2 to 4 cards are close, recommended option first. For many slots at once, use the picker page: write candidates JSON and run uv run "${CLAUDE_SKILL_DIR}/scripts/picker.py" candidates.json --out picker.html (format in its --help). Each option carries its reason and evidence; add the price only when money matters to them.
• Copies follow their money answer:
  • No limit, normal copies (default): pick the best card; don't bring up cheaper ones.
  • Keep it cheap or a set budget: for cards that push past it, run mtg_cheaper_alternatives (with the commander's identity and the deck) and offer the best one next to the original with the price gap.
  • Drippy ("wanna drip out your cards?"): fancy printings (foil, borderless, showcase, Secret Lair) up to their per-card max, passed as max_card.
• Before finalizing, run the mtg-research commander-text search: any card that copies, doubles or scales the commander's ability must be in the deck or named with the reason it's out.

6. Check loop (repeat until clean)

1. mtg_deck_check with the target bracket (and budget, if they set one). Fix every error. B1 to B3: remove every two-card combo it lists; B3: also any early game-winning line. Read also_requires on combos: those need extra pieces.
2. mtg_simulate. If the commander is castable in under about half of games by the turn after its mana value, add ramp or lands.
3. If an add-on offers a bracket estimate, compare with it. If it disagrees, fix it or explain why.
4. Every suggested change goes through mtg_deck_swap first. Drop any that fail.

If a tool is down, say which check didn't run. Never present an unchecked list as checked.

7. Hand back

• The list (commander first, saved to <commander-slug>.txt), and the plan in 3 to 5 lines.
• Rule 0 summary the player can read out before a game: bracket, how it wins and roughly when, Game Changers, combos, anything the table might want to know (stax, extra turns).
• Price, once: mtg_price_plan in their style, as one line with the three totals ("cheapest $212 · as listed $340 · drippy $1,180") and the date. Add to_buy_usd if they have a collection. Store links per card only if they ask how to get the cards.
• An "Unverified" line for anything you couldn't check.

Then offer the page, when the deck is ready. Ready means: mtg_deck_check passes with no errors at the target bracket, the commander is on curve per step 6, and every check ran. Ask once, with AskUserQuestion:

• "See it as a commander vault page (Recommended, about 2 minutes)": render this one deck with the vault page scripts, following the commander-vault skill's references/pages.md (scripts in ${CLAUDE_PLUGIN_ROOT}/skills/commander-vault/scripts): site_data.py init with the commander's name as title and this bracket, add-deck with notes.json written from the plan, key cards, strengths, weaknesses and Rule 0 summary, then build_site.py, then publish (or hand over the HTML folder).
• "Build a full vault around it": more brackets or more commanders; tell them to type /mtg:commander-vault in this folder and it will start from this deck (30 minutes or more).
• "Not now"

Finally, recommend next steps (pick the 2 or 3 that fit): export it for Moxfield or Archidekt (mtg_export; Moxfield keeps exact printings), check what they still need from their collection (mtg_collection have), build another bracket of the same commander, or start a new deck.

Other requests

• Review a deck: mtg_deck_profile + mtg_deck_check + mtg_simulate, then report legality, bracket (with reasons), role gaps, mana problems, weakest cards (read each before calling it weak), and combos present or one card away. Recommend next steps: upgrade it, make it cheaper, or leave it.
• Optimize or upgrade: follow references/optimize.md. Every add names a specific cut and passes mtg_deck_swap. Never cut a combo piece, a commander enabler or the last card in a role without saying so.
• Make it cheaper: mtg_price_plan (budget style shows the floor), then mtg_cheaper_alternatives on the most expensive cards, tested with mtg_deck_swap. Report the new total and what the deck gives up.
• Theme or flavor decks: only when the player asks. Follow references/themes.md.
• Import a deck: pasted text in Moxfield, Archidekt, Arena or plain format works directly. For a deck link (Moxfield, Archidekt, ...), use an installed add-on that can read that site; if none can, ask the player to paste the site's export. Names that don't resolve go through mtg_resolve_names; ask about ambiguous ones.