Umi Prompt Inspector

The Wildcard Processor is cheerful about doing a lot of things at once - expanding wildcards, resolving variables, merging presets, hiding negatives, patching LoRAs. When the result isn't what you expected, the question is always the same: which step added that? Umi Prompt Inspector answers it inside the graph, by comparing the prompt you wrote against the prompt the processor produced.

What it compares

Three required inputs: input_prompt, processed_prompt and profile. Two optional: negative_prompt and lora_info. The wiring is a straight copy from the processor - input_text → input_prompt, text → processed_prompt, and if you have them, input_negative → negative_prompt and lora_info → lora_info.

It then produces three outputs:

• diff_json - changed, plus added and removed lists and the input/output character counts. Comparison is case-insensitive on comma-separated pieces, and the splitter is smarter than text.split(","): it respects quotes, angle brackets and parentheses, so <lora:style_x.safetensors:0.8> stays one item instead of shredding at the wrong place.
• lint_warnings - the same profile lint the Profile node runs, against the processed prompt: missing quality tags for the chosen profile, negative prompt missing the profile's negatives, prompt too short for the target, a prose-style profile fed a tag list, and the "LoRA tags present but no LoRA info" case.
• sections_json - the parsed [section:name] blocks. Note this is read from the input prompt, not the processed one, because sections are a structure in your template that the processor flattens on the way out. Feed the original template to input_prompt and you get back each section's body, the order they appeared in, and whatever text sat outside any section.

That last one is quietly the most useful output. It's how you check that section_order is doing what you think - a section name you typo'd won't error, it'll just sit in the wrong place, and this tells you which section names the parser actually saw.

Why not just read the panel?

The pack's Run Inspector sidebar shows the last processing trace - the phases, the wildcard resolutions, the variables, the warnings. It's good, and it covers ground this node can't. Two differences matter. First, the panel's disk-backed endpoint is disabled until persist_run_inspector is turned on in umi_settings.json, whereas this node always reports. Second, and more importantly, the panel shows you the latest run; the node lets you route the data. diff_json can go to a save node alongside the image, or into the same metadata pipeline as the prompts themselves, so a batch's diffs are auditable later instead of being overwritten by the next queue.

A prompt inspector that writes its finding into the image metadata is, honestly, the version of this feature that survives contact with a 40-image batch.

Where it's weak

The diff is comma-based. On a tag prompt that's ideal - you see exactly which tags the roll added. On a natural-language paragraph in the LLM-encoded style, your whole prompt is one or two "tokens" and the diff degenerates into "changed: true, added: [the entire thing]". Use the counts and the warnings on those, or read the full trace in explain_json from the processor instead - that has the per-phase text.

It's also not a validator. It compares two strings you hand it; if your processed_prompt is fed from the wrong socket, it will happily and accurately diff the wrong things. If the diff looks like added: [] on a run you know expanded something, check the wiring before you distrust the node.

Install

Core node, no separate install. ComfyUI Manager (search the pack title) or clone into ComfyUI/custom_nodes and pip install -r requirements.txt (pyyaml). Restart, then look under UmiAI/prompt - it's usually parked next to the Syntax Lint node, and they pair well: lint the template before the run, inspect the diff after it.