Wildcard And Lora Syntax Processor (Mikey)

This is Mikey Nodes' LoraSyntaxProcessor with one thing added: it also resolves __wildcard__ file-based tags in the same pass. If your prompt text mixes both tricks - a wildcard pulling a random line from a text file, and an inline <lora:name:weight> tag applying a LoRA - this node handles both in one step instead of needing a Wildcard Processor node feeding into a separate LoraSyntaxProcessor node.

Why this exists as a separate node

Wildcards and LoRA tags solve different problems but show up together constantly in practice - a wildcard picking a random character archetype, paired with the specific LoRA that character needs, all typed into the same prompt block for convenience. Rather than forcing you to chain two processor nodes to get both effects, the pack bundles the combination into one. The schema is otherwise identical to plain LoraSyntaxProcessor: same four inputs, same four outputs, same tag syntax.

The syntax it reads

Two systems, both documented in the README, both resolved here:

• LoRA tags: <lora:lora_name> for default weight, or <lora:lora_name:0.8> for an explicit weight - same syntax LoraSyntaxProcessor reads on its own.
• Wildcards: __word__ pulls a random line from wildcards/word.txt, with the same modifier syntax as the standalone Wildcard Processor node - 2$$__word__ for multiple selections, __word|term__ to filter lines containing "term," __!word__ to lock the pick to your seed, and __+word__/__-word__/__*word__ for offset and forced-different selections.

Inputs and outputs

model, clip - your base checkpoint's outputs. text - a multiline block that can contain wildcard tags, LoRA tags, or both mixed together with regular prompt text; default placeholder is <lora:filename:weight>. seed - drives both the LoRA-tag-adjacent randomness and the wildcard line selection, so the same seed reproduces the same combination of resolved wildcards and applied LoRAs.

Four outputs: the patched model, the patched clip, the fully resolved text (wildcards expanded, LoRA tags stripped, ready for a CLIP Text Encode node), and unprocessed_text (your original input, unchanged, for logging what you actually typed).

Installing

Ships with the full Mikey Nodes pack - ComfyUI Manager, search "Mikey Nodes," install, restart, or cd ComfyUI/custom_nodes && git clone https://github.com/bash-j/mikey_nodes and restart manually. Two things need to be in place separately for this node to do anything useful: a wildcards folder in your ComfyUI root with .txt files for whatever tags you reference, and your LoRA files present in ComfyUI/models/loras under the exact names your <lora:> tags use.

Where people get tripped up

• A wildcard resolving to text that then breaks LoRA tag parsing. If a wildcard line itself contains something that looks like a malformed <lora:...> tag (stray angle brackets in a wildcard file, for instance), it can confuse the LoRA parser. Keep wildcard file contents to plain prompt text unless you're deliberately nesting a LoRA tag inside a wildcard entry.
• Forgetting trigger words still aren't automatic. This node applies the LoRA weight and strips the tag, but it has no knowledge of what trigger word a given LoRA actually needs - that's still on you to include in the surrounding prompt text, same as with plain LoraSyntaxProcessor.
• Missing wildcard file silently producing empty text. If a __tag__ doesn't resolve because the matching .txt file doesn't exist in wildcards/, you can end up with a gap in your final prompt that's easy to miss - check the resolved text output directly (not just unprocessed_text) if your generations look off compared to what you expected to type.