CB String List Match Index ⚡️

Where this belongs in a workflow

Sooner or later you want the graph to decide something rather than you deciding it before queueing. Does this prompt mention a character? Which style keyword is in it? Is the trigger word actually present, or did the LoRA silently do nothing because it wasn't?

That's this node. You give it a string, a list of strings, and a rule for what counts as a match. It gives you back where the match was, and whether there was one at all. Classic plumbing: turn text into a number and a boolean, then let the rest of the graph route on them.

The mechanism, including the bit people get backwards

Five inputs, two outputs, and one genuinely confusing detail.

It strips your input_string, lowercases it if case_sensitive is off, splits string_list on the chosen delimiter, strips and drops empty entries from the list, and walks the list looking for the first item that matches. First match wins - it stops there, which is why order matters.

The confusing part is direction. For Contains, Starts with and Ends with, the list item is the needle and your input string is the haystack. The code is literally compare_item in target, target.startswith(compare_item), target.endswith(compare_item). So if your input is a long prompt and your list contains red dress, Contains asks "does this prompt contain 'red dress'" - which is almost always what you want, but it reads backwards in the dropdown unless you know.

The output is a 1-based index - 1 for the first list entry - and 0 when nothing matched. 0 doubles as "not found" and "you forgot to fill in the list", so the matched boolean is the cleaner thing to gate on. Empty lines are filtered before indexing, so the index counts items, not lines in your text box.

Inputs and outputs

| | | |---|---| | input_string (STRING) | the text you're searching - usually a prompt | | string_list (multiline STRING) | your keywords, one per line (default apple\nbanana\ncherry) | | delimiter (enum: newline, comma) | how the list is split | | match_mode (enum: Equal, Contains, Starts with, Ends with) | the matching rule | | case_sensitive (BOOLEAN, default True) | whether Apple and apple are different | | index (INT, output) | 1-based position of the first match, 0 if none | | matched (BOOLEAN, output) | did anything match |

Wiring it up

Two patterns cover most of it.

Keyword to index. Feed index into something that routes on a number - an index selector, a switch, or a CB String Selector to pick a matching style line. Watch the off-by-one: that selector is 0-based, so a match at index 1 selects its second line. Subtract one, or put a throwaway entry at the top of the list.

Presence to gate. Feed matched into whatever your graph already uses to switch branches on/off. A boolean is a boolean; a bypass switch, a mask node, or an optional-input gate all take it.

Installing it

Manager → Custom Nodes Manager → search ComfyUI CoolB Nodes → Install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/CoolBreeze164/ComfyUI-CoolB-Nodes

No extra packages, no models. Pure string work - it will never be your bottleneck.

Common issues

"It matched when it shouldn't have." Contains is substring matching with no word boundaries, so cat matches concatenate. If that matters, use Equal on cleaned-up input, or put the more specific entries at the top of the list and accept the first-match-wins behaviour.

"It didn't match at all." case_sensitive defaults to true, so Apple vs apple fails out of the box. That's the one to check first, before you suspect the code.

"Wrong index." Blank lines and whitespace-only lines are discarded before numbering, so the index is a position in the cleaned list. And with Contains in a list of five things where three of them appear in your prompt, you get the first one, because it stops at the first match.

You wanted a fuzzy match. There isn't one. This is exact substring work, with no typo tolerance and no regex. If you need regex-style matching, that's a different tool - and this pack is deliberately a collection of small, predictable primitives rather than a rules engine.

One caution on trust. Matching a prompt tells you a word is present, not that the model acted on it. Trigger-word presence is genuinely worth testing for - plenty of "my LoRA does nothing" reports end at a missing trigger word - but passing this node isn't proof the LoRA fired.