🔹 Keyword Match Gate
The string AND-gate that makes workflows react to your prompt
- gated_text
This is the node that lets a workflow decide things based on what your prompt says. KeywordMatchGate is a string-based AND gate: you give it text and a keyword, it tells you whether the keyword appears, and it returns a useful string either way - the keyword (or the whole input, your choice) on a match, or the literal "no match" when it doesn't. It's the backbone of the "prompt-reactive LoRA" pattern the Zlycoris README is built around: prompt says "cinematic" → light the cinematic LoRA; prompt says "anime" → drop the photoreal one.
The inputs that matter
input_text- your prompt or any text, multiline.match_keyword- what to look for. Empty values are treated as no-match, which is deliberate.case_sensitive- default off, so "CINEMATIC" and "cinematic" both hit.match_whole_word- default on. Uses word boundaries, so "cat" won't match "catalog". Turn it off for substring matching.echo_input- default off. On match, output the keyword; on, output the entire input text.
The single output is gated_text (STRING): match_keyword or input_text on a hit, "no match" otherwise.
How to actually use it
The return value is a string because that's what's pipeable. The pattern is: KeywordMatchGate → text → (via a text-to-anything or a widget-bypass node like PrimitiveWidgetToString) → strength. A gate that returns "no match" when closed is designed to be mapped to 0 strength - the node docstring literally says "explicit 'no match' so it can be mapped to 0 later." So you build a prompt-reactive system with three moving parts: a gate per concept, a mapping to a strength, and a stacker. The README's example: if prompt contains "cinematic" → enable lighting LoRA is exactly what this node plus a conditional wiring delivers.
Install
ComfyUI Manager (search ComfyUI-Zlycoris) or:
cd ComfyUI/custom_nodes
git clone https://github.com/TripleHeadedMonkey/ComfyUI-Zlycoris.git
Restart ComfyUI. Zero models, pure logic.
Where people get burned
- It returns a string, not a boolean. There's no TRUE/FALSE output. Every downstream consumer has to be able to read
"no match"- if you forget the mapping step, a closed gate feeds literal text into something expecting a number and the graph breaks or silently no-ops. - Whole-word matching is on by default. Most people who hit "why isn't my keyword matching" are looking for substring behavior and have it flipped the other way. If you're gating on a phrase like "golden hour," whole-word works fine (it's regex-word-bounded); if you're gating on a fragment, turn it off.
- It fires on the first match anywhere. No multiple-keyword support, no OR/AND of several keywords in one node. For "any of these words," chain multiple gates; for "all of these," feed the same text through several and combine the outputs.
IS_CHANGEDreturns a constant, which means the node re-runs every execution - that's intentional (it's a pure function), just don't be surprised by the log line spam in a big workflow.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| input_text | STRING | — | |
| match_keyword | STRING | — | |
| case_sensitive | BOOLEAN | false | — |
| match_whole_word | BOOLEAN | true | — |
| echo_input | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| gated_text | STRING | — |