Conditions: The Deep Dive

Conditions are the single feature that decides whether a large component collection is maintainable or a nightmare. Get them right and items design themselves. Get them wrong and you'll be hand-assigning frames forever. They evaluate only properties from the active component type.

There are two independent condition systems in ShuffleKit, and confusing them is the most common source of trouble:

The operators themselves are the same in both places. They are driven by the property's type, not by which system you're in. This tutorial covers the first system. See Element Visibility for the second.

The resolution model

Every face (front, back) has its own list. Open the Designs panel in the Design editor's left rail and each face lists its rules first, in the order they are checked, then the fallback (Every other card) and, when there are any, a Not used heading.

Four consequences worth stating plainly:

1. Order is logic. Moving a rule up or down changes which cards it captures.
2. First match wins. A card never uses two front layouts, and never "merges" them.
3. The fallback catches the remainder. It should have no condition.
4. A layout with no rule never wins by position. Only one rule-less layout can be the fallback; any other goes under Not used and draws nothing.

Writing a condition

1. Open Design for the active collection.
2. Find the layout in the Designs panel, the first tab in the left rail.
3. Click Edit in the strip under its name (When Type equals living). To remove the rule, use Clear in the popover. On a layout under Not used, click Add rule in its amber strip (or Make default to make it the fallback instead), or choose Give it a rule… from its ⋯ menu. The rule popover opens beside the panel.
4. Fill in the row under "Use “” for cards where": [property] [operator] [value].
5. Click Apply.

The popover opens with focus on the first Property picker. Each extra row has an x (Remove condition) at its end. Apply stays disabled until every row is complete. Clear, shown only when the layout already has a rule, removes the condition entirely. Unless the layout is the fallback, it then draws nothing and the Designs panel lists it under Not used.

The value control follows the property type:

How a layout's state shows

Each row in Designs says who gets the layout and how many:

While the open layout is under Not used and the Designs panel isn't showing, the header shows an amber Not used chip beside its name; click it to open Designs. Opening the rule popover from a row explains the state at the top. For Not used it names the fallback (Cards that match no rule get "RPG Split".) and offers make it the fallback instead, warning when that would leave the old fallback with nothing. For a saved rule that no card resolves to, it says No card uses this layout. Edit its rule below, and on a deck rule adds a reminder to check that the deck it names still has cards in it.

The line beside Apply always names where unmatched cards go: Cards that match no rule get "RPG Split" ★, Cards that match no rule get this layout ★ on the fallback itself, or No fallback: cards that match no rule get no layout on a back with none.

As you build the rule, the popover counts it against your real cards: "5 of 19 cards use this layout", with a bar, thumbnails of the first few cards it catches, and, when rules higher in the list take some of its matches, "3 more match this rule but land on a higher-priority layout first." Two of its readings are warnings:

• "No card satisfies this rule (0 of 19 cards). This layout won't be used."
• "All 8 matching cards are already claimed by a higher-priority layout, so this layout won't be used. Raise its priority to change that."

The count isn't shown on the fallback layout, where a rule filters nothing. Read that footer before you click Apply and you'll catch most mistakes on the spot.

A saved rule is watched after you close the popover as well; see the states above.

The operators depend on the property type

There is no single fixed operator list. The Operator dropdown offers only what makes sense for the property you picked. The condition row shows the short labels in brackets; the visibility panel and the Why this layout? dialog spell them out.

Three of those are worth calling out:

is any of is a Select feature. It's the operator that keeps layout counts down: three near-identical elemental frames become one layout with a three-value rule. It only appears when the property is a Select (or when you're conditioning on Deck). Its value is picked from a checklist of that Select's options, so a typo is impossible.

Numbers get real comparisons. greater than and less than are there, so a range-based frame is a single clause: Cost ≥ 4. No helper property needed.

contains reads free text. It matches when the value appears anywhere in the text, ignoring case, so Type line contains tactic catches Tactic, Tactic / Instant and Instant Tactic. It's how some template packs send each card to its own design.

is empty has a use that isn't obvious: it's a work-in-progress detector. A layout at the top of the list with Artwork is empty and an obvious placeholder design makes unfinished cards impossible to miss in a print proof.

Conditioning on a deck

The Property dropdown has one entry that isn't a property: Deck (membership). It reads which decks the card belongs to, so Deck is any of Expansion gives an entire expansion its own frame without adding a column to hold that fact. The Designs panel writes it as When in Expansion. On a board layout the same entry is named after that type's collections.

It's multi-valued, which is why it only offers the set operators. Deck is empty catches cards that haven't been filed into any deck yet.

Multiple conditions

Click Add another condition under the first row. An and divider separates each new row from the one above:

Type    is         creature
──────── and ────────
Rarity  is any of  rare, mythic

It's AND, always. There is no OR at this level.

To express OR you have two options:

• Use is any of on a single Select property. Covers most cases.
• Split into two layouts at adjacent priorities, with the same design. Slightly more maintenance, but it handles OR across different properties: Type equals hero OR Faction equals royal, which is any of can't handle.

In that worked AND example, a premium frame goes to high-rarity creatures only. Both rows must hold. A rare artifact fails the first; a common creature fails the second.

Don't put a condition on the fallback

The fallback row in Designs has no Edit, because a rule there filters nothing. But a front fallback you never picked is just the first front layout, and that one may already carry a rule; it then appears twice, as a rule and as the fallback. Open that rule and ShuffleKit tells you it won't do what you meant:

This is the front fallback (★). It catches every card that matches no other rule, so this rule won't hide it from any card. Put the rule on another front layout instead.

This is worth understanding rather than just obeying. The fallback is defined as "what happens when nothing else matched". A card that fails the fallback's own condition has, by definition, already failed every other rule, so it lands on the fallback regardless. The condition can never exclude anything; the most it does is let the fallback win matching cards at its place among the rules, which the Designs panel shows as Every other card, and rule 1.

If you find yourself wanting to condition the fallback, what you actually want is a new layout carrying that condition, with the fallback left bare.

On a face with only one layout you get a grey note instead: "Your only front layout. Every card uses it. This rule starts filtering once you add a second front layout." Nothing is wrong; the rule simply has nothing to filter against yet.

Debugging: "Why this layout?"

When a card renders with the wrong frame, don't guess. Select the card in the spreadsheet and click Why this layout? under the preview. (Flip to the back and the same link reads Why this card back?.)

The dialog, titled Why these layouts? once your project has a back layout, shows the result for FRONT and BACK separately:

• The layout In use, with Matched because: and a tick beside each clause of its rule, and an Edit link to jump straight into it. A card that no rule claimed reads "Chosen as the default layout (★): no other layout's condition matched this card." (On a back with no chosen default, the rule-less back says it "Has no condition, so it catches every card that doesn't match another card back".)
• Why not the others: every layout that lost, each with a specific reason:
  • "Needs Type to be "space", but this card's Type is living." The rule was evaluated and failed.
  • "Also matches, but RPG Split ranks higher." It would have worked, but priority went the other way. These rows get a Use this button that moves the layout above the current winner in one click.
  • "No condition: applies only as the default." It was never in the running for this card.

Those last two are the ones that catch people out, and they need opposite fixes: the first is an ordering problem, the second means the layout can only ever be reached as the fallback.

The Card Details panel also states the outcome in one line without opening anything:

This card uses layout RPG Split, because Type equals "living".

Select a different card and the sentence changes. Clicking through five or six cards is the fastest sanity check there is.

Choose the right property type

Conditions compare values. That makes the type of the property you condition on a design decision, not a detail.

Use Select. A Select property offers a fixed list, so a condition on it can never miss because of a typo, and it's the only type that unlocks is any of. Type as a Select with options living / space / artifact is robust.

Be careful with Text. With equals, Living, living (trailing space) and livng are three different values, and only one of them matches your rule. The card silently falls through to the fallback and the design looks "randomly wrong". contains is more forgiving (it ignores case), but a typo still misses.

Yes / No is fine for on/off distinctions, such as Legendary equals true.

Number is fully ordered, so cost bands and power tiers work as plain comparisons rather than needing a helper column.

If you inherit a project built on Text properties, converting the column to Select before you build conditions is time well spent. See Properties & Columns.

Patterns that work

The ladder. Most specific at the top, broadest at the bottom, plain fallback last.

Rules
1  Legendary Frame   Rarity equals mythic
2  Creature Frame    Type equals creature
3  Spell Frame       Type equals spell
Fallback
   Basic Frame       no condition

The WIP catcher. A loud placeholder layout at rule 1 with Artwork is empty. Unfinished cards announce themselves.

The one-property switch. A single Select property that exists purely to drive layout choice, called Frame, with options that name the designs. When a card needs a specific frame for reasons no rule can express, you set Frame directly and the condition system stays simple. Use this design in the spreadsheet's row menu builds the same thing for you: it adds a Design column when no existing column describes the cards you picked. See Conditions.

Fold near-duplicates. Before adding a fourth layout, ask whether it differs from an existing one by a badge or a colour. If so, it's one layout with a conditional element, not a new design to maintain.

Pitfalls

Broad rule above narrow rule. The narrow one never fires. The popover's live count says so: "All N matching cards are already claimed by a higher-priority layout". The resolution dialog says the same thing for each card.

Two layouts, same condition. The second is unreachable. The Designs panel lists it under Not used: Never used: same rule as "Creature Frame" (rule 2), which is checked first.

A second layout with no rule. It never draws. The Designs panel lists it under Not used, the header shows an amber Not used chip while it is open, and leaving Design asks whether you want to make it the default or give it a condition.

Conditioning on a property that isn't on the layout. Perfectly legal and often correct. Type can drive layout choice without ever being printed. The coverage note in Layers doesn't flag a column that any rule on the face reads, even when it's Required, and that column's header in the spreadsheet says Picks which layout a card uses, not on the card itself. See Data Binding.

Editing the condition of a layout you're not looking at. The rule popover edits the row you clicked in Designs, which may not be the layout open on the canvas. Check the row's name and face before you click Apply.

Forgetting card backs. Backs have their own list and their own fallback. A front-side change never affects them.