Deck Strat

Deck Strat

Produce a Strategy Guide for a finished MTG deck — a markdown document that explains how to pilot the deck, organized into a fixed core spine plus archetype-conditional sections, with every rules-adjacent claim verified against the Comprehensive Rules. Each recommendation MUST be grounded in actual oracle text and CR citations — never training data.

deck-strat is read-only on the deck. It does not propose cuts, adds, or tuning changes. If the user wants to tune the deck first, point them at /deck-wizard, then run /deck-strat on the finished list. Both skills share the working dir and the SHA-keyed hydrated cache, so chaining is transparent.

The Iron Rule

NEVER assume what a card or rule does. Before writing any clause into the guide:

• For a card's behavior: look up its oracle text via scryfall-lookup or read it from the hydrated cache. Training data is not oracle text.
• For a rule's behavior: look it up via rules-lookup (--rule, --term, or --grep) and quote the verbatim text. Training data is not the CR.

A confidently wrong claim about commander-zone behavior, stack timing, or a replacement-effect interaction makes the entire guide untrustworthy. The Rules Audit subagent (Step 10) is the discipline gate that catches slipped claims — but every authored sentence should be cite-defensible before it gets there.

Scope

deck-strat supports Commander, Brawl, and Historic Brawl (singleton multiplayer formats with commanders). 60-card constructed formats are out of scope in v1 — their strategy artifact is a sideboard plan + matchup matrix, which is a different shape and is already produced by /deck-wizard Step 12.

Competitive Brawl (competitive_brawl) is supported and is its own format — not a variant to audit as historic_brawl. It is always 1v1, 25 life, and has no free mulligan, so do not cite CR 903.12g's free-first-mulligan rule for it; that rule governs ordinary Brawl. It shares the brawl legality key but legalizes everything that key marks banned, enforcing its own ten-card list by name (format_config.COMPETITIVE_BRAWL_BANNED). Guides for this format should skip multiplayer/politics sections entirely.

If the user invokes deck-strat on a 60-card constructed deck, decline and redirect: "This skill produces multiplayer strategy guides for singleton commander formats. For Standard/Modern/Pioneer/etc., run /deck-wizard — its Step 12 finalize includes a sideboard guide."

Progress Tracking

Before starting, create a TodoWrite list with these 10 items. Mark each in_progress when you begin and completed the moment it finishes — never batch.

1. Parse deck + set commander(s)
2. Hydrate via scryfall-lookup --batch
3. Baseline diagnostics
4. Commander Interaction Audit
5. Archetype detection
6. Combo + near-miss detection
7. EDHREC research
8. Rules verification pass
9. Draft Strategy Guide
10. Rules Audit subagent + revise

Step 4 is long enough that you should expand it inline when you start it (sub-todos: keyword combos, trigger multiplication, feedback loops, recurring cards, commander multiplication, combo detection). Step 10 is also long enough to expand (dispatch audit, process report, revise draft).

Iteration after step 10 (user-requested edits) is not a fresh pipeline run — handle each user request as an Edit to the existing guide.

Setup (First Run)

uv sync --directory <skill-install-dir>
download-mtgjson
download-rules --output-dir <working-dir>

Subsequent runs skip if .venv exists, bulk data is fresh (24h), and CR is fresh (24h). The CR file MUST live in the working dir, not the skill install dir — rules-lookup and the Rules Audit subagent both look there.

Tooling Notes

Working dir & paths

• Absolute paths only. uv rebases the working directory to the skill install; relative paths resolve against the wrong root.
• Cache directory: <working-dir>/.cache for hydrated card data.
• CR file: <working-dir>/comprehensive-rules-YYYYMMDD.txt.
• Bulk data: <skill-install-dir>/default-cards.json.
• Output: <working-dir>/STRATEGY-GUIDE.md.

Reused CLIs

deck-strat ships no CLIs of its own. Every tool below is re-declared from mtg_utils in deck-strat/pyproject.toml. Invoke via uv run <name> from the skill install directory.

JSON file writing

Use the Write tool, not Bash heredocs, for any JSON file containing card names. Apostrophes break shell quoting; Write-tool permissions cache cleanly across the session.

Scratch file paths

Reuse these stable paths within a session: /tmp/audit-claims.json (used by the Rules Audit subagent), /tmp/combo-search.json (combo detection output if --output not specified).

Warning: /tmp files persist across sessions. At session start, Read each scratch path you plan to reuse before the first Write, or run Write sequentially and verify success before the dependent Bash call.

Hybrid rules-lawyer integration

See ADR-0008. deck-strat uses two paths for rules verification:

1. CLI (rules-lookup, rulings-lookup) — routine claims. Default to this when a claim can be verified from one rule number, one glossary term, or one narrow regex. Examples: "does shroud block self-targeting?" → rules-lookup --term shroud; "is the free first mulligan a Commander rule?" → rules-lookup --grep "first mulligan".
2. Skill tool (Skill(rules-lawyer, ...)) — nuanced claims. Escalate when (a) the claim spans two or more rules and their interaction is the load-bearing part, (b) the relevant rule's prose is thin and a section slice is needed, or (c) verification requires reasoning about layers, replacement-effect ordering, or stack timing across triggered and activated abilities. The rules-lawyer skill carries its own Phase 1/2/3 escalation discipline (including subagent dispatch) that you do not duplicate here.

Both the Phase 3 rules verification pass (Step 8) and the Rules Audit subagent (Step 10) follow the same escalation rule.

Re-hydration

If for any reason the deck JSON is edited mid-session (e.g., the user notices a wrong card name during iteration and you re-parse), re-run scryfall-lookup --batch — the hydrated cache is SHA-keyed against the deck JSON's content, so a stale cache_path gives stale data.

Phase 1: Acquisition

Step 1: Parse + set commander(s)

Accept either a raw deck list (.txt, Moxfield export, MTGO format, pasted) or an already-parsed deck JSON. If raw:

parse-deck <path> --format <commander|brawl|historic_brawl> \
    --output <working-dir>/deck.json

If the input is already a parsed deck JSON, accept it as-is and verify its format field matches one of the three supported formats.

Always pass --format explicitly when parsing. Without it, parse-deck defaults to commander and downstream tools see the wrong format.

If the parsed deck's commanders list is empty (common with Moxfield exports that lack //Commander headers), ask the user who the commander is. Don't guess — the first card isn't always the commander. Supports:

• Single commander: set-commander <deck.json> "Name"
• Partner / Friends Forever: set-commander <deck.json> "Name1" "Name2"
• Commander + Background: set-commander <deck.json> "Commander" "Background"

set-commander is idempotent — safe to chain after parse-deck even when the deck file already had a commander header.

Pilot bracket question

After parsing, ask the user:

"What power bracket are you piloting this at? (1-5 / casual / upgraded / optimized / cEDH, or auto.) This determines how the guide weights politics, combo prominence, and threat assessment."

Default to auto: count Game Changers (from deck-stats), count game-winning combos (from combo-search, run later), assess curve. The mapping:

• 0 GC, 0 infinite combos, curve ≥ 3.5 → Bracket 2 (casual)
• 1-2 GC, 0-1 combos, curve 3.0-3.5 → Bracket 3 (upgraded)
• 3+ GC, 2+ combos, curve ≤ 3.0 → Bracket 4 (optimized)
• All fast tutors + free interaction → cEDH (Bracket 5)

If the user gives an explicit bracket, prefer it. Auto-detect only when they say auto or don't answer. Record the resolved bracket — every downstream step uses it.

Step 2: Hydrate

scryfall-lookup --batch <working-dir>/deck.json \
    --bulk-data <skill-install-dir>/default-cards.json \
    --cache-dir <working-dir>/.cache

Stdout is a JSON envelope with cache_path, card_count, missing, and a digest containing counts + curve. Do NOT Read the cache file directly — it's large and floods context. Use card-summary, Grep, or targeted scryfall-lookup "<Name>" calls for inspection.

If missing is non-empty, the user's deck contains unrecognized card names — ask them to verify. Common causes: typos, set-code suffixes that didn't get stripped, Arena/paper crossover renames (Paradise Chocobo = Birds of Paradise, Skittering Kitten = Masked Meower, etc.).

Phase 2: Analysis

These five steps read the hydrated cache independently — you can run their CLI calls in parallel where useful. Each populates context that later steps depend on.

Step 3: Baseline diagnostics

Run in this order (cheapest-to-fail first):

legality-audit <deck.json> <hydrated.json>
deck-stats <deck.json> <hydrated.json>
mana-audit <deck.json> <hydrated.json>
card-summary <hydrated.json> --nonlands-only
card-summary <hydrated.json> --lands-only

• legality-audit must PASS. If FAIL, surface the violation and ask the user how to resolve (the guide can't be authored against an illegal list). Don't propose fixes — that's deck-wizard's job.
• deck-stats gives the Game Changer count, curve, color sources, ramp count, and alternative-cost cards. Record alternative-cost cards (suspend, foretell, evoke, escape, flashback, adventure) — these evaluate at their alt cost in the strategy guide, not their printed CMC.
• mana-audit may return WARN or FAIL — note it but don't propose fixes. The guide can call out the mana base as a tuning consideration.
• card-summary is for your reading; do not paste it verbatim into the guide.

Step 4: Commander Interaction Audit

This step is the highest-leverage analysis in the pipeline — it surfaces the synergies that are invisible when reading cards in isolation. Inherited verbatim from deck-wizard Step 5; the dimensions are the same.

For each commander (and for partner/background pairs, both), and for the deck as a whole, work through these six dimensions and write down what you find. The Strategy Guide's "core loop", "synergies", and "common lines" sections derive from these notes.

Sub-todos (expand into TodoWrite when starting Step 4):

4a. Keyword combinations

List the commander's keywords and any keywords granted by cards in the deck. Check every pair for emergent effects:

• Evasion stacking: menace + "can't be blocked by more than one creature" = unblockable. Any blocking restriction combined with a conflicting blocking requirement may create unblockable.
• Damage multiplication: double strike + combat damage triggers = double triggers. Double strike + lifelink = double life. Trample + deathtouch = 1 damage kills, rest tramples over.
• Protection stacking: ward + hexproof, indestructible + regenerate. Identify which are redundant vs. complementary.

4b. Trigger multiplication

Identify the commander's core multiplier (extra upkeeps, extra combats, extra turns, extra phases, trigger copying, token doubling, etc.). For every triggered ability in the deck that fires during the multiplied window, calculate output at 1×, 3×, and 5× the base rate. The Strategy Guide presents the multiplied value as the realistic case, not the 1× base.

For commanders whose trigger scales with combat damage, identify pump as a strategic pillar — each +1 power isn't just +1 damage, it's +1 trigger of every effect in the multiplied window.

4c. Feedback loops

For each card, ask: "Does this card's output feed back into its own input or the commander's trigger condition?" Examples:

• A +1/+1 counter source on a commander whose trigger scales with power.
• A token creator that increases a count used by another card's scaling.
• A theft effect where stolen permanents change type to match a tribal count.

Cards with feedback loops are almost always stronger than they appear in isolation. The guide should flag them in the "synergies" section.

4d. Recurring cards

Identify all cards that return themselves to a usable zone: re-suspend, buyback, retrace, escape, flashback, "return to hand" clauses, "exile with time counters" effects. The guide evaluates these on per-game value (total free casts over a typical game), not per-cast value.

4e. Commander multiplication

Identify cards that multiply the commander's impact:

• Commander copies: Helm of the Host, Spark Double, Clone effects, Mirror March, Followed Footsteps. Non-legendary copies bypass the legend rule and retain all triggered + activated abilities.
• Ability copiers / trigger multipliers: Strionic Resonator, Rings of Brighthearth, Panharmonicon (for ETB commanders), Teysa Karlov (death triggers), Isshin (attack triggers), Seedborn Muse (extra activations).

Scan oracle text directly — these are force-multipliers and earn prominent placement in the guide's "synergies" section.

4f. Combo detection

This sub-step bridges into Step 6. Run:

combo-search <deck.json> --hydrated <hydrated.json> \
    --output <working-dir>/combo-search.json

Distinguish:

• Game-winning combos (result contains "infinite" or "win the game"): flag prominently. These are central to the guide's "win conditions" and "combo execution" sections.
• Value interactions (non-infinite synergies): note as context.

Before recommending a near-miss combo as something the guide should mention as a "1-card-away" finishing line, Read the full description field for that near-miss from the JSON. The compact text report omits required pieces that aren't in the card list.

Step 5: Archetype detection

Run archetype-audit with a curated preset list to identify which conditional sections the Strategy Guide will render. The result is a set of theme densities — themes above the warn threshold trigger their corresponding conditional section.

archetype-audit <deck.json> <hydrated.json> \
    --include-commanders \
    --preset tokens \
    --preset sacrifice-outlet \
    --preset reanimate \
    --theme 'goad=goad|attacks each combat if able' \
    --theme 'aristocrats-drain=whenever .* creature .* dies|sacrifice .* creature' \
    --theme 'token-doubler=create twice that many|tokens .* plus that many' \
    --theme 'opponents-create-tokens=that.*player.*creates|each.*opponent.*creates' \
    --theme 'extra-combats=additional combat phase|extra combat' \
    --theme 'extra-turns=take an extra turn|additional turn' \
    --theme 'big-mana=add (any|four|five|six|seven|eight)' \
    --min-density 4 --warn-density 6 --show-matches

Always pass --include-commanders — for commander formats the commander is usually the biggest theme piece.

Map theme density (in card copies) to conditional sections:

Voltron-shaped commanders are identified manually: oracle text gives the commander evasion + power-scaling, the deck has 6+ equipment / aura slots, and the deck lacks wide-board engines.

Step 6: Combo + near-miss detection

The combo-search call from Step 4f already populated this. Now do the bracket check:

• Bracket 1-2: intentional two-card infinite combos are prohibited by the bracket policy. If the deck has an infinite combo, the guide flags it as a bracket compliance issue and asks the user whether to treat it as an unintended line or a real wincon.
• Bracket 3: infinite combos allowed but should not reliably fire before turn 6. Guide notes timing.
• Bracket 4 / cEDH: no restrictions. Combo lines are central in the guide.

Near-misses (1-card-away from a combo): the guide includes a "Known near-miss completions worth knowing" callout listing the missing piece

• what the closed combo would do. This is informational, not a recommendation to change the deck.

Step 7: EDHREC research

edhrec-lookup "<Commander Name>"

For partner pairs:

edhrec-lookup "<Commander 1>" "<Commander 2>"

EDHREC gives community top-cards, high-synergy cards, and deck count. Use it to:

• Confirm the deck's archetype identification is reasonable.
• Spot cards in the deck that EDHREC flags as high-synergy (these get prominent placement in the guide).
• Spot cards EDHREC marks as commonly included that are NOT in this deck — note as "deliberate omissions" in deck notes.

Brawl/Arena caveat: EDHREC data is sourced from Commander/EDH decks. For Brawl/Historic Brawl, EDHREC suggestions must be legality- checked against the deck's format before referencing in the guide.

Fallback if EDHREC has no data (new or obscure commanders):

1. Use card-search with the commander's mechanics keywords to find synergistic cards in the color identity.
2. Look up the archetype rather than the specific commander.
3. The guide proceeds without the "community comparison" callouts.

Use WebSearch + WebFetch sparingly — only if you need strategic context for an obscure commander. Use web-fetch script as a fallback if WebFetch is blocked.

Phase 3: Authoring

Step 8: Rules verification pass

Before writing the guide, list every rules-adjacent claim you intend to make. These come from Step 4 (commander interaction audit) and Step 6 (combo execution lines). For each, verify via the CLI or escalate to the rules-lawyer skill per the hybrid integration rules above.

Common claim types and their verification:

Record each claim + its CR citation in your working notes — the draft step quotes the verbatim CR text.

Step 9: Draft Strategy Guide

Write the guide to <working-dir>/STRATEGY-GUIDE.md. The structure is a fixed core spine + the conditional sections triggered in Step 5.

Core spine (always render, in this order)

1. Title + identity block.

   • Deck name (commander[s], color identity, format).
   • One-sentence archetype label (e.g., "Politics-driven aristocrats", "Voltron with reanimator subtheme", "Stax-control with combo finish").

2. Core loop. 3-5 sentences describing how the deck wins. Derives from Step 4 (commander interaction audit) — name the multiplier, the engine pieces, and the terminal effect.

3. Win conditions. Ordered by likelihood:

   • Primary plan (the core loop's terminal event).
   • Secondary plan (engine grind / commander damage / pump alpha-strike).
   • Tertiary plan (combo, if present and bracket-allowed). Each plan gets 2-4 sentences naming the cards involved.

4. Mulligan guide. What a keepable hand looks like. Reference the free first mulligan rule (CR 800.6) once. Common shapes to mulligan into. Common shapes to mulligan away from.

5. Turn-by-turn pacing. T1-T8+ sketch. What to deploy each turn range. Where the deck shifts from setup to harvest. Bracket-aware: faster brackets need a shorter setup window.

6. Threat assessment. Cards / decks to fear (sorted), cards / decks to eat for breakfast. Bracket-aware: Bracket 4 fears specific cards (Drannith, Null Rod, Cursed Totem) where Bracket 2 fears mass removal.

7. Common lines + stack tricks. Stack ordering on key sequences. The pre-wipe sequencing question (sac iteration vs. one wipe). Commander damage math. Equipment timing. Every claim in this section gets a CR citation.

8. Deck quirks. Borderline mana base, single Game Changer, weird reprint names (e.g., Paradise Chocobo = Birds of Paradise), suspended self-sac clauses (Endrek Sahr). Things that surprise a first-time pilot.

9. Cheat sheet. A bulleted per-turn checklist: "Did a token die → Joel triggered. Did opponents fight → Karazikar drew. Did a token enter → Mirkwood Bats / Impact Tremors fired." Strip names to the triggers a pilot needs to remember.

10. Appendix: Verified card interaction notes. A list of the rules- adjacent claims with their CR citations. This is the audit trail — the Rules Audit subagent (Step 10) verifies against this list.

Conditional sections (render when triggered in Step 5)

Each conditional section names its trigger at the top so a future re-run reproduces the same shape if signals fire again.

• Politics scripts (triggered by goad + opponents-create-tokens): scripted lines for steering opponent attention, who to curse first, when to deploy goad effects.
• Aristocrats sequencing (aristocrats-drain + sacrifice-outlet): the pre-wipe-iterate-sacs question with sac-trigger vs. death-trigger asymmetry called out. Per-payoff trigger count.
• Combo execution (game-winning combo present): step-by-step stack ordering of the combo, required board state, protection options, near-miss completions.
• Voltron commander damage math (voltron-shaped commander): base power → equipment stack → growth-per-turn → turns to lethal. Hexproof / shroud / protection tooling.
• Token doubling math (tokens + token-doubler): with N doublers out, M token producers fire X tokens. Includes Chatterfang/Parallel Lives stacking semantics.
• Extra-combats / extra-turns sections: mana flow + threat density needed to make these worthwhile.
• Reanimation lines (reanimate density): which graveyard fillers feed which reanimators, exile-vs-graveyard differentiation.
• Mana-pump payoffs (big-mana): the X-spell finisher line, the Kessig Wolf Run line, the Helix Pinnacle line.
• ETB multiplication (Panharmonicon-likes): which ETB triggers in the deck benefit most, ordering on the stack.

Writing style

• Cite CR rules verbatim, not paraphrased. Quote the rule number
  • the trimmed sentence: "Per CR 903.9a: 'If a commander is in a graveyard or in exile and that object was put into that zone since the last time state-based actions were checked, its owner may put it into the command zone.'"
• Reference cards by full oracle text when the behavior is load-bearing. Paraphrase only for obvious cases (Sol Ring).
• Adapt tone to experience level (see table below). If not stated, ask the user during Step 1 acquisition or default to intermediate.
• No emojis. No marketing fluff. The guide is a reference document.

Step 10: Rules Audit subagent + revise

HARD GATE. Before presenting the guide, dispatch one general- purpose Agent with this exact charter:

You are a Rules Audit agent for an MTG Strategy Guide. The guide is at <absolute-path-to-STRATEGY-GUIDE.md>. The deck's hydrated card data is at <cache_path>. The CR is at <working-dir>/comprehensive-rules- YYYYMMDD.txt.

Your task: for every rules-adjacent claim in the guide (stack timing, replacement effects, commander-zone behavior, keyword interactions, intervening-if clauses, layers, trigger ordering, oracle text quotations), verify the claim against:

1. The card's actual oracle text via scryfall-lookup "<name>" or by reading the hydrated cache.
2. The relevant CR rule via rules-lookup --rule <n> / --term <keyword> / --grep "<regex>".
3. For multi-rule reasoning, escalate to the rules-lawyer skill via the Skill tool — the rules-lawyer skill's own escalation rules apply.

Return a JSON report at /tmp/audit-claims.json with this shape:

{
  "errors": [
    {"section": "...", "claim": "...", "cr_says": "...", "fix": "..."}
  ],
  "unsupported": [
    {"section": "...", "claim": "...", "needed_citation": "..."}
  ],
  "verified": [
    {"section": "...", "claim": "...", "cr_rule": "...", "match": "exact|paraphrased"}
  ]
}

Be specific. If the guide says "the trigger goes on top of the spell," cite CR 603.3. If the guide says "shroud means can't be targeted," cite CR 702.18a. Errors are claims that are factually wrong. Unsupported claims are factually fine but need a citation added. Verified claims are correct and cite-defensible.

Arithmetic is in scope and must be re-derived, not read. Any combo loop cost, threshold ("profits at five Elves"), damage total, turn count, or card count in the guide: compute it yourself from the oracle text and report the number you got. Do not confirm a number because the guide's reasoning around it sounds right. Where a loop has a per-cycle cost and a per-cycle yield, simulate several iterations — a loop that looks break-even on iteration one often diverges by iteration three (self-pumping effects compound), and a loop that looks infinite may be bounded by a resource the guide didn't track.

Count anything the guide counts. "N cards with X", "N lands enter tapped", "N sources of colour C" — recount from the decklist and report your number even when it matches.

Check internal consistency, not just external truth. Guides repeat claims in a cheat sheet, a summary, and a body section. Flag any place two sections disagree, and any place a "Requires:" header contradicts the prose beneath it. These are the most common survivors of a fix round, because a correction gets applied in one location only.

Do NOT propose strategic / deck-tuning changes. Your scope is rules verification, arithmetic, and internal consistency.

While the subagent runs, do nothing else — wait for the report.

Process the report:

• Errors: edit the guide in place to correct each one. Quote the CR text in the edit.
• Unsupported: edit the guide to add the missing CR citation.
• Verified: no action.

Two rules when applying fixes — both exist because fix rounds routinely introduce fresh errors:

1. Propagate every correction to all its surfaces. Before moving to the next item, Grep the guide for the card, rule, or number you just changed. A claim corrected in the combo section usually also lives in the cheat sheet, the win-conditions summary, and a "Requires:" header. A fix applied in one place and not the others produces a guide that contradicts itself, which is worse than the original error.
2. Re-read any rule you cite while fixing. Do not add a citation from memory of what the audit said. A correction that cites the wrong rule — or over-applies a right one, e.g. invoking CR 302.6 summoning sickness against a noncreature artifact — is a new error introduced by the repair.

If the subagent reports zero errors and zero unsupported claims, present the guide. Otherwise fix and dispatch another round with the same charter, repeating until a round comes back clean.

Rounds should converge fast. If round 2 still reports errors, that is a signal about this SKILL.md, not just about the draft — note what class of claim keeps slipping through (arithmetic? cross-section consistency? a card type the charter doesn't mention?) and surface it to the user with the finished guide so the charter can be sharpened. Do not silently grind extra rounds.

Step 11: Present + iterate

Show the user the path to the guide and a brief summary of what's in it (which conditional sections rendered, which combos detected, which bracket-flag warnings if any).

Iteration is user-driven and in-place:

• User asks to add / remove / rewrite a section → Edit the existing STRATEGY-GUIDE.md file. Don't regenerate from scratch.
• User reports a rules error you missed → rules-lookup the relevant rule, fix in place, note that the Rules Audit missed it (this is a signal that the audit charter may need sharpening over time).
• User reports the deck changed (different cards) → restart the pipeline. The SHA-keyed hydrated cache will rebuild automatically; the guide gets rewritten.

Failure Modes

Experience-level Adaptation

Inherit deck-wizard's table for prose tone. Default to intermediate if the user doesn't say.

Red Flags

These thoughts mean STOP — you're rationalizing:

Decision Table