Nodes/Kemmy Sequential Prompt List/cn_02_kemmy_Sequential Prompt List (String)
ComfyUI Node

cn_02_kemmy_Sequential Prompt List (String)

The String version of Sequential Prompt List

By kemmy2302·Created 7 days ago·Updated 3 days ago· 0
cn_02_kemmy_Sequential Prompt List (String)
    • prompt
    records_json{"version": 1, "records": [{"id": "0d044803-7a5d-4b4f-b390-8b7d69458635", "enabled": true, "title": "List Item 001", "prompt": ""}]}
    prefix_prompt
    suffix_prompt

    The CONDITIONING version of this pack is a neat time-saver, but it has a ceiling: it encodes the text the moment the queue runs. The moment you want something to look at each finished prompt before CLIP encoding - an LLM rewriting it into better prose, an Ollama call, a text node that sanity-checks it - you've outgrown it. That's exactly the gap cn_02_kemmy_Sequential Prompt List (String) (class OPTSequentialPromptListString) fills. Same editor, same records, same prefix/suffix split, but instead of conditioning it emits the finished prompt strings, in order, and lets whatever you chain next have the final word.

    Reach for it when your workflow has a text-processing stage between "I typed the scenes" and "the model drew them." The classic setup, which is where this pack and the local-LLM pattern in ComfyUI meet: a fixed character prompt and a fixed style/quality prompt on either side, each scene as one list record, and an Ollama (or any LLM) node downstream that receives every completed prompt and produces one coherent final prompt per item before it ever touches a CLIP Text Encode. Because the LLM sees the character, the scene, and the style together for each item, it can keep the narrative coherent across the whole batch - which is the difference between a list and a story.

    How it works

    Under the hood it's nearly the same machine as the sibling node. Your records live in the records_json input (a JSON widget the in-node editor maintains - you don't hand-write it), and for every enabled, non-empty record the node builds:

    prefix_prompt
    <the record's prompt>
    suffix_prompt
    

    Each completed string is one element of the output list. Because the node declares its output as a list, ComfyUI maps compatible downstream nodes over the items in order - standard CLIP Text Encode handles this natively, and the author's tested Ollama Generate workflow does too. One queue action walks the whole list. Newlines inside a record are preserved and do not split it into extra items, which quietly saves people who write two-line prompts from a nasty surprise.

    The inputs and output that matter

    There is no clip input here - this node never encodes anything, which is the entire point.

    • records_json - the list itself, edited via the node's panel. One record = one scene/expression/pose.
    • prefix_prompt - optional STRING: character, outfit, fixed concepts.
    • suffix_prompt - optional STRING: style, lighting, quality, fixed finishing instructions.
    • Output: prompt - an ordered list of completed STRINGs, wired to an LLM node or to CLIP Text Encode.text.

    If you connect prompt straight to a CLIP Text Encode you've rebuilt the conditioning node manually - the String version earns its keep when there's a processor in between, or when you want to actually read the exact text that will reach the encoder.

    Installing it

    It ships in the same pack as its sibling, so one install gets you both. No Python dependencies, no models to download - it's frontend plus a couple of thin server routes. Either search ComfyUI Manager for cn_02_kemmy_ComfyUI-Sequential-Prompt-List, or:

    git clone https://github.com/kemmy2302/cn_02_kemmy_ComfyUI-Sequential-Prompt-List.git
    

    in ComfyUI/custom_nodes, then restart the backend (not just the browser) and hard-refresh with Ctrl+F5. Both nodes appear under Ordered Prompt Tools. Saved lists are shared with the conditioning node and stored at ComfyUI/user/ordered_prompt_tools/lists/, safe from plugin updates.

    Where people get burned

    The one real failure mode here is downstream, not upstream: the String node emits a ComfyUI list, and if the node you connect it to doesn't support normal list mapping, you'll only get the first item processed and wonder what happened. Standard CLIP Text Encode and the author's tested Ollama workflow map fine; an obscure third-party node may not - check for a list-aware alternative if you see exactly one result. Seed behavior, as ever, belongs to the sampler downstream of all this: set control_after_generate to fixed if you want each scene compared on identical noise rather than a mix of prompt change and seed change.

    CategoryOrdered Prompt Tools

    Inputs (3)

    NameTypeDefaultDescription
    records_jsonSTRING{"version": 1, "records": [{"id": "0d044803-7a5d-4b4f-b390-8b7d69458635", "enabled": true, "title": "List Item 001", "prompt": ""}]}
    prefix_promptoptSTRING
    suffix_promptoptSTRING

    Outputs (1)

    NameTypeDescription
    promptSTRING