Bonus: LLM text → image intent (KSampler prompts)

The pack's flagship node writes text. But what do you do when that text is "generate an image of a red fox in a snowstorm" and you want the graph to actually do it? Copy the reply into a prompt box like it's 2023? This small bonus node is the non-copypaste answer: it reads the LLM's reply, decides whether it's a request for a brand-new image, and hands you clean KSampler-ready prompts plus a boolean that tells the rest of your graph whether to run the sampling stage at all.

How it works, and its limits

It's regex, not a second LLM. The node scans the incoming text for trigger phrases like "generate an image of …", "draw a picture …", "show me an image …", extracts the subject that follows ("a red fox in a snowstorm"), and stuffs it into positive_prompt, appending whatever positive_suffix you've set (default high quality, detailed, coherent - your style tag lives here). negative_prompt just passes through your default block. If no intent matches, run_image_gen comes back false and your graph can route around the sampler.

The "Bonus" in the name is doing a lot of work - this is a heuristic, and the author is upfront about it. English keyword matching only; no multilingual intent, no "sketch me a dragon" that doesn't hit a trigger, and it will happily misread "don't generate an image of X" if you're feeling adversarial. It's perfect for the narrow case it targets: an LLM that's been told to answer "yes, and here's a description" when it wants to render something. It is not a general-purpose prompt interpreter.

The outputs

Five outputs, and only a few you'll actually wire:

• run_image_gen (BOOLEAN) - the decision. Feed it into a switch/reroute to gate your sampler chain.
• positive_prompt / negative_prompt (STRING) - go straight into CLIP Text Encode → KSampler.
• run_image_gen_int (INT) - the same decision as 0/1, for nodes that can't take booleans.
• parse_note (STRING) - a human-readable note on what matched, handy for debugging why a prompt came out the way it did.

strip_thinking_tags (default true) is the sleeper: LLM replies often carry <think>…</think> reasoning blocks, and you do not want that scaffolding bleeding into your positive prompt. Leave it on unless you're deliberately testing the parser.

Where it shines: the "describe → prompt → generate → QC → edit" closed loop this pack is built around. Wire the main LLM node's text into this router, let it gate a KSampler, and you've got an agentic loop where the model literally decides when to render. If that's the workflow you're here for, this tiny node is doing the connective tissue that makes it feel magical. Just remember it's glue, not intelligence.