Prompt String Editor

Ever built a prompt you liked, then spent ten minutes painfully editing it back every time you want to swap "red dress" for "white dress"? That's the copy-paste shuffle this node exists to kill. PromptSE (display name "Prompt String Editor") turns one node into a mini prompt manager: you keep several prompt snippets as separate entries, tick them on and off, give each one an attention weight, drag them into order, and it hands you a single combined string at the end.

It's the kind of thing rgthree's pack does with plain text nodes - except this one ships its own full UI instead of making you wire a graph together. There are no inputs to plug in and no model files to download; it's a self-contained editor with one job, and one wire out.

How it works

The trick is that the node has no visible inputs - it's driven entirely by a hidden widget called promptse_data, a single JSON string that holds everything: your entries (id, title, content, enabled, weight), the connector, the mode, and the lexicon. The frontend JavaScript builds the whole interface - entry cards, the editor popup, the gear settings panel - and writes all of it back into that one widget. That's also why your prompts survive saving and reloading the workflow: the state lives in the saved graph, not in some external file.

When you hit Queue, the backend parses that JSON and does the assembly in process():

• Mode M (multiple) - joins every enabled entry with the connector (", " by default).
• Mode S (single) - outputs only the first enabled entry. That's your A/B switch: enable one of three style variants, queue, tick the next one, queue again.
• Weights - each entry's weight becomes (content:1.2) or [content:1.2], and a weight of exactly 1.0 emits the plain text.

The one output, output_string, is a plain STRING - wire it into a CLIP Text Encode prompt input (or whatever your checkpoint's text encoder wants) and you're done.

The inputs that matter

None, honestly. Everything is UI: the + / - buttons add and remove entries, the checkbox enables/disables, click an entry to edit its title and content, drag to reorder. The ⚙️ button sets the connector (try ", " vs "\n"), and the weight format toggle switches between parentheses and brackets. The lexicon feature - import a UTF-8 .txt where each line is english,chinese, search, click a tag to append it - is a genuinely nice touch for Japanese/anime tagging, though it's very much a "nice to have."

Install

Via ComfyUI Manager, search for "PromptSE" or "ComfyUI-PromptSE" and hit install. Or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/RainyN0077/ComfyUI-PromptSE

Then restart ComfyUI. There are no dependencies - pure Python stdlib plus vanilla JS, no requirements.txt, no model downloads.

Where people get burned

The weight formatting is CLIP-only. (keyword:1.2) attention syntax works on SD 1.5, SDXL, Illustrious, Pony - the whole SDXL lineage. On Flux's T5 encoder it's largely ignored, and on the new LLM-encoded models (Anima, Flux 2 Klein, Z-Image) it's worse than useless: those encoders read your parentheses and colons as literal punctuation inside your instruction. If you're on a modern LLM-encoded checkpoint, leave every weight at 1.0 (or set weight format to "none") and treat the node as a plain text combiner. Check what your checkpoint is built on before you trust the (prompt:1.3) this thing is happy to generate.

One real gotcha in the README: it tells you to place the files in a folder named PromptSE/, but the pack's registered Python module path is custom_nodes.ComfyUI-PromptSE. If you're cloning, keep the repo's own folder name and ComfyUI will load it fine - just don't follow the manual-copy instructions literally and rename the folder.

Be honest about its pedigree. This is a young, single-author, fairly obscure pack - no real community footprint yet, and the repo's own planning docs list things like lexicon polish as still-in-progress. The custom UI means it's also exposed to ComfyUI frontend changes; if a ComfyUI update breaks the node's display, check the repo for a fix before assuming you did something wrong. It's a handy tool, not battle-tested infrastructure. Given that, I'd keep prompts you care about backed up in a text file - this node is more "organized lab notebook" than "source of truth."

If that tradeoff sounds fine, it's a nice quality-of-life add for the SDXL prompt-tweaker crowd.