Outfit Set

MKROutfitSet is the wardrobe department for the pack's character branch. It takes a character state record - the JSON from MKRCharacterState - and adds or updates a named outfit inside it, then emits the resolved prompt for that look. Keep the character's face and body stable in the state record, and swap costumes by pointing at a different outfit name downstream. It's a small node, but it's the thing that makes "same character, different clothes" reproducible instead of prompt-roulette.

Character consistency is the community's most complained-about problem (the modidex knowledge base tracks it as the perennial top pain point), and the pack's answer is structural: keep identity in one state record and treat outfits, poses, and expressions as composable layers on top of it. MKROutfitSet is one of those layers. It doesn't generate anything itself - it builds data and a prompt string that your sampler prompt encoder turns into pixels.

The inputs that matter

• character_state_json - the character record from MKRCharacterState (or a previous OutfitSet output, since it passes the state through). Feed the updated state back into the next node in the chain.
• outfit_name - the label for the look (Base Look default). Reusing a name updates that outfit rather than duplicating it - the author's own docs call this out, and it's the key to not accumulating junk outfits.
• outfit_prompt - the costume description itself. This is the core of what lands in the resolved prompt.
• silhouette_notes / material_notes - two short fields the pack treats as first-class ("clear read from distance", "distinct material breakup"). They're appended to the resolved prompt as separate chunks, which genuinely helps - models read "silhouette" and "material" as distinct concepts.
• accessories_csv and palette_csv - comma-separated tokens (hat, belt, scarf / crimson, gold, teal) that get deduped and folded into the prompt.
• match_strength - 0–1, default 0.82. How tightly this look should track the base identity. Stored per-outfit so a wacky variant can loosen up without touching the base.
• set_as_default - make this outfit the default in the state record.

The outputs

• character_state_json - the updated record, with the outfit stored and default_outfit possibly changed. This is the wire to the next node.
• outfit_json - the isolated outfit record. Inspect this to see exactly what got stored.
• resolved_prompt - the combined string: character anchor + outfit prompt + silhouette + material + accessories + palette + mood. This goes into your CLIP text encode.
• summary_json - character name, outfit name, count, match strength, accessory count.

Installing

Standard pack install:

cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes

restart, or ComfyUI Manager → "MKRShift". No dependencies, no models - all the heavy lifting is in your sampler.

Gotchas

The obvious one: this node produces a prompt string, not magic. The identity only stays consistent if the rest of your pipeline does - MKROutfitSet appends the outfit to whatever positive_anchor lives in the state, and it's on you to use a character setup that actually holds identity (the pack's own MKRCharacterCustomizer is the companion piece, or your LoRA/reference stack). Also, match_strength is stored metadata for downstream nodes; in a bare prompt-pipeline it's descriptive, not a lever - don't expect the number itself to change the image. And remember the state record is JSON text: keep it flowing through the chain as strings and it works; snap the chain and you've lost the wardrobe.