TermsToList

Quick honesty check before anything else: this node ships with no description and doesn't appear in the pack's README at all, so everything below is read off its inputs and outputs, not off documentation someone wrote for it. What the schema tells you is this - one input, terms, that accepts any type at all, and one output, one_list, that's a genuine ComfyUI list of that same type. In plain terms: it takes whatever single value you wire in and hands it back wrapped as a one-item list.

Why you'd want that

A plain wire between two nodes in ComfyUI carries one value. Nodes that are built to run in list mode - process each item in a batch one at a time, or iterate over a set of things - only kick into that mode when what feeds them is an actual list-typed output, not a single value. If you've got one value sitting on a wire and something downstream needs to see it as "a list containing that value" to behave correctly, this node is the adapter. It doesn't change the value, it just changes the container it's traveling in.

The inputs and outputs that matter

There's exactly one of each, and the wildcard typing (*) means it doesn't care what you plug in:

• terms - the single value going in. Text, a number, an image, whatever your graph is producing - the node accepts it untyped.
• one_list - the same value, coming back out as a one-item list instead of a bare value.

Because it's an untyped *-to-* node, it's on you to make sure whatever you wire in downstream is expecting the type you actually sent - the node itself won't stop you from connecting mismatched types, and ComfyUI's own type-checking is the only thing that will.

How to install it

Search RuiquNodes for ComfyUI in ComfyUI Manager, or clone it directly:

cd ComfyUI/custom_nodes
git clone https://github.com/ruiqutech/ComfyUI-RuiquNodes

Restart ComfyUI and it's ready - no model files, and nothing in the README suggests dependencies beyond plain Python, so there's no download step to wait through.

Where people get burned

The obvious one first: this node has a single terms socket, not a variable number of them, so you can't wire nine different values into it and expect a nine-item list to come out the other side. One value in, one-item list out - if you need to build up a longer list from several separate sources, you'll need to combine them upstream first (or chain outputs together some other way); this node isn't a collector, it's a wrapper.

Second, since there's no node_description and the README talks about an entirely different family of nodes in this pack (EvaluateMultiple1/EvaluateMultiple3, which run arbitrary Python fragments), there's genuinely no written source to fall back on if it doesn't behave the way you expect - and no community threads either, this pack has essentially zero footprint outside its own repo. If one_list isn't triggering the list-mode behavior you expected downstream, the most likely explanation is that the receiving node isn't actually built to consume a list in the first place, rather than anything wrong with this node's output.