WP Context

WP Context is the heart of Wildcard Pipeline. Everything else in the pack - the loop, the assembler, the debug inspector - exists to feed this node or read from it. If you've only ever used Impact Pack's __wildcard__ syntax or a flat wildcard file, here's the pitch: instead of a prompt where each slot rolls independently, WP Context runs a stack of modules that read what the modules before them picked. $mood can react to $weather. A combine can stitch $style and $subject into a $scene. You get one coherent prompt per Generate instead of a Frankenstein concatenation.

How it works

Drop it on the canvas and it shows two things: a seed input and a wp_modules socketless widget. That widget is where the real work happens - it's a module stack, and the order matters because the engine executes modules top to bottom and each one publishes $variables that the ones below it can read. You'll add wildcard modules (weighted random pick from a pool you build in the manager SPA), fixed_values (static name → value bindings), combine (a template that interpolates earlier vars), derivation (IF/ELIF rules), constraint (re-weights a downstream wildcard based on an upstream pick), and bundle (a frozen group of modules you drop in as a unit).

The seed input is the starting point for the whole roll. Keep it the same and the same modules pick the same options; change it and everything re-rolls. The tooltip points at the trick you'll actually want: right-click → Convert widget to input to drive the seed from another seed node - that's how you make the roll reproducible across workflows or chain it into a loop.

The single output is context of type PIPELINE_CONTEXT. Wire it into WP Prompt Assembler, WP Var → Int/Float/Bool, or WP Debug. There's also an optional upstream input: connect another context here and this node extends it - upstream vars pass through, and this node's modules add or override bindings on top. Leave it unconnected to start fresh. That's how you build a pipeline out of context nodes instead of one giant stack.

Install

ComfyUI Manager → search Wildcard Pipeline by dumiflex → Install → restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/DumiFlex/ComfyUI-Wildcard-Pipeline
cd ComfyUI-Wildcard-Pipeline
pip install -e .
pnpm install && pnpm run build   # needs Node.js + pnpm

Two things to flag before you clone. First, this pack needs ComfyUI ≥ 0.3.36 - it uses the newer V3 io node schema, and older runtimes will fail at import rather than degrade gracefully. Second, the manual build is heavier than most custom nodes: the frontend is a full SPA (the manager app with SQLite-backed library), so the pnpm step is mandatory if you clone by hand. There are no model downloads and no Python dependencies beyond what ComfyUI already ships - the engine is pure Python plus SQLite. License is GPL-3.0.

Common issues

Where people get burned: this is not Impact Pack wildcards. The {a|b|c} syntax from Impact Pack won't populate WP Context modules, and __wildcard__ files won't either - this pack has its own library and its own $variable system, so a workflow you pulled from the community will quietly resolve nothing if the modules weren't embedded. Relatedly, workflow JSON embeds module snapshots, but nested wildcard refs get resolved against the live library on your machine at run time. If the database isn't reachable (embedded ComfyUI without the SPA stack), you'll see "Unknown wildcard ref" warnings in WP Debug instead of a pick. If you're mid-roll and a module "never fires," check the constraint's carrier wiring first - that's the fiddly one.

WP Context is the node you'll build every workflow around once you've tasted it, but it's also the one with the steepest learning curve, because the real UI is the manager SPA, not the canvas. Budget an evening.