JB · Builder

Most text encoders take a flat comma sentence. Some - newer structured-prompt models, JSON-prompt workflows, and the Z-Image-style setups this pack targets - respond to actual structure: a nested document where character_1 is a block containing hair, outfit, and pose as labeled fields. JB · Builder is the tool for hand-authoring exactly that. You type a tree of key: value rows with indentation for nesting, or pull a pre-built snippet from the built-in catalog, and it emits the whole thing as a JSON string ready for a CLIPTextEncode.

It's the centerpiece of the pack's JB (JSON Builder) suite - the five nodes that assemble structured prompts instead of flat ones. Builder is the one where you write raw structure by hand; the blocks and stitcher handle the "more than one character" assembly.

How it works

The UI is a row editor: each row is [key] [value] [⋮], and indentation defines nesting. Two levels deep:

character_1
  hair: short brown
  outfit: red dress

becomes {"character_1": {"hair": "short brown", "outfit": "red dress"}}. The Insert ▾ dropdown (the catalog) drops ready-made snippet trees into the editor - the reference workflow uses it to insert a full face block (east_asian_young_woman and friends) instead of typing twenty rows.

Two features elevate it beyond a text editor:

• Wildcards: row values can contain __wildcard__ tokens that expand from text files in the pack's wildcards/ directory. Same seed + same rows + same wildcards = identical output, so you can get seeded variety from a single authored tree.
• Variable recall: the optional context_from_prompt_generator input accepts a DICT from an adaptiveprompts PromptGenerator's context output, letting a value bound earlier as __name^var__ be recalled later as __^var__. This is how you keep one name consistent across every field of the tree without typing it four times.

Output format is your choice via output_format: pretty_json, compact_json, or loose_keys. The loose_keys mode drops the quotes around keys - technically not valid JSON, but many SD-era encoders and tokenizers cope better with bare keys, which is why it's the default. The raw_json output is always strict JSON for tools that demand it.

Inputs and outputs

Inputs: rows (the hidden row data owned by the widget - you don't type JSON here, you edit rows), seed (for wildcards), output_format, and the optional context dict. Outputs: raw_json (strict) and string (the chosen format) - wire string into a JB · Stitcher input or straight into CLIPTextEncode.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/ping1979ping/comfyui-FVMtools

No extra Python dependencies (numpy and pydantic 2 are already in ComfyUI). Restart and the whole JB suite appears under FVM Tools/JB.

The honest warning

The mental model matters more than the node. If your model doesn't read structured prompts, {key: value} JSON in a prompt is just noise tokens - this entire suite is wasted effort on a plain SDXL checkpoint. It earns its keep specifically with structured-prompt-friendly models and with the multi-character problem, where a character_1 block keeps attributes anchored to a name the way flat prompts can't. Also watch loose_keys vs strict JSON: if you're piping raw_json into a strict parser, the loose-keys string will fail it. Pick the format to match the downstream consumer, not the prettiest one.