Nodes/ComfyUI_EmAySee_CustomNodes/EmAySee Prompt State Parser
ComfyUI Node

EmAySee Prompt State Parser

' and 'STATE:' reply into two clean strings

By EmAySee·Created about a year ago·Updated 4 months ago· 2
EmAySee Prompt State Parser
    • prompt
    • state
    text_input

    EmAySee Prompt State Parser takes a single string and splits it around two markers - PROMPT: and STATE: - returning the text after each as its own output. It's a parser for a specific convention: LLM-based workflow nodes that answer with a prompt plus some state or status information in one blob, using those labels as the delimiters.

    The origin story is visible in the pack. The author's Oobabooga connector nodes and other LLM tools can return a combined reply - a generated prompt followed by a state marker like STATE: done or STATE: retry - and if you're feeding that into a prompt encoder you want the prompt only, with the state stripped out. This node does that stripping, and hands you both halves so you can route the prompt to your CLIP/text encoder and the state to a switch or a display. It's the "LLMs are great at producing the right thing wrapped in the wrong formatting" cleanup step.

    How it works

    The parsing is marker-based string slicing, in the most literal sense. It finds PROMPT: and STATE: in the input, then extracts the text after each marker up to the other marker (or the end of the string). The two sections can appear in either order - if the prompt comes first, the state is whatever follows its marker and vice versa. Text before the first marker is discarded, which means anything the model rambled before labeling its answer is dropped.

    Behavior worth knowing:

    • If a marker isn't found, that output comes back as an empty string rather than an error. A reply with no PROMPT: gives you an empty prompt output.
    • The markers are case-sensitive (PROMPT: not prompt:), so a model that doesn't follow the convention returns empty sections. The node is only as good as the model's formatting discipline.
    • Input is forceInput - it's meant to be wired from another node (like an LLM connector), not typed.

    The inputs that matter

    One input, two outputs:

    • text_input - a STRING, expected to contain the PROMPT: and/or STATE: markers.

    Outputs: prompt (STRING) and state (STRING). Route prompt into a CLIP Text Encode or prompt builder; route state wherever your workflow branches on LLM status.

    Installing it

    Part of the EmAySee pack:

    # ComfyUI Manager: search "ComfyUI_EmAySee_CustomNodes" and install
    # or manually:
    cd ComfyUI/custom_nodes
    git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes
    

    Restart ComfyUI. No requirements.txt, pure Python, nothing to install beyond the pack itself.

    Common issues

    The marker convention is the whole game, and it's a two-sided contract: your LLM node has to emit PROMPT: and STATE: labels for this parser to have anything to do. If your model replies with free-form text, both outputs come back empty and it looks like the node is broken when it's really the model not following the format. Some models are inconsistent about it - you'll see a PROMPT: on one run and a raw answer on the next. The practical fix is to make sure the system prompt your LLM uses explicitly demands those labels, since the parser has zero tolerance for variations. It's a thin, single-purpose node, and it's perfect for exactly the workflow it was built around.

    CategoryEmAySee/Text

    Inputs (1)

    NameTypeDefaultDescription
    text_inputSTRING

    Outputs (2)

    NameTypeDescription
    promptSTRING
    stateSTRING