FEBCPrompt

Most ComfyUI prompt-generator nodes treat the LLM as a one-shot oracle: one user message in, one prompt out. FEBCPrompt is the piece that lets you do better - it assembles a conversation for the pack's local-LLM node (FEGenStringBCDocker) instead of a single message. You chain these nodes together, each one appending a message to a growing PROMPTS list, and the final list becomes the context for the generation call.

Each instance is one message. You pick a role - user or assistant - type the message content into system_prompt (misnamed for the role you'll mostly use, but that's the widget), and optionally chain the output of a previous FEBCPrompt into prev_prompt. The node appends your message to the incoming list and passes the whole thing along. Build a chain like system instruction → user request → assistant example → user request, and the LLM gets the full history instead of a single line.

The inputs

• role - user or assistant. Set this correctly; it's what makes multi-turn work.
• system_prompt - the message text (multiline). Despite the name, it's just the content of this turn.
• prev_prompt (optional) - the PROMPTS list from a previous FEBCPrompt, so messages accumulate.

Output is prompts, type PROMPTS, which plugs into FEGenStringBCDocker's optional prompt_list input.

Honest context: "BC" here is the author's own local LLM setup - FEGenStringBCDocker talks to a TGI-style inference container you'd have to run yourself, and without that server the whole generation side of this pack does nothing. FEBCPrompt is only useful inside that ecosystem. But if you do run the BC docker endpoint, this is the difference between getting a flat one-shot reply and building an actual back-and-forth that knows what you asked two messages ago - which, for iterative prompt refinement ("now make it more cinematic"), is a real quality jump.

A couple of mechanical notes. The message list is passed by reference and mutated - prev_prompt['prompts'].append(...) - which works fine in linear chains but means branching off one conversation into two paths can give you surprises if both branches append to the same list. And the node is marked to always re-execute (the pack forces it), so your conversation is rebuilt fresh on every queue run; it won't accidentally accumulate across generations.

It's a narrow tool for a narrow setup, and you'll know within a minute whether it's for you: if you're not running a BC-style local LLM, this node is just a well-behaved building block waiting for a server that isn't there.