Jingyuma Split Shots

A text router, and the honest way to storyboard

The Storyboard node hands you a prompt per shot, one per line: [Shot 001] wide shot, rooftop at night…. You cannot feed that block into a CLIP Text Encode and get forty images. You'd get one image conditioned on forty mixed prompts, or on whatever survived truncation. Split Shots exists to take that blob and hand back exactly one line.

It's the smallest node in the pack and the one you'll touch most, because per-shot generation is how storyboards actually get made. Queue all forty at once and you'll keep maybe five. Generate shot 3, look at it, fix a word, regenerate, move on - that's the loop, and this is the node that makes the loop cost one keystroke.

How it picks the shot

The matching is dumb and predictable, which is what you want. It looks for a line starting with [Shot NNN], zero-padded to three digits - so shot_index of 3 hunts for the literal string [Shot 003] - and returns everything after the bracket, stripped. The prefix never reaches your conditioning, so you're not paying prompt tokens for bookkeeping.

There's a fallback worth knowing: if no line matches the prefix, it counts non-empty lines and takes the Nth one, stripping anything before the first ]. So this node also works on a plain newline-separated list of prompts you pasted in yourself from anywhere, not just on the Storyboard node's output. Free utility.

The failure mode is also worth knowing. If your index doesn't exist - you asked for shot 12 in a 10-shot free-tier result - it returns an empty string. CLIP Text Encode happily accepts an empty prompt and samples from nothing. You get a blank-ish image and no error at all. If an image makes no sense, check your shot count before you blame the sampler.

Inputs and outputs

prompts is a multiline string with forceInput set, meaning the pack deliberately removed the text box - there is nothing to type into, you must wire it to the image_prompts output of Jingyuma Storyboard. If the node looks like it's missing a field, that's why.

shot_index is an integer, default 1, range 1 to 9999, and it's the only thing you change per generation.

The single output is prompt - a STRING with the bracket prefix gone, ready to drop straight into the positive CLIP Text Encode. Keep your negative prompt as a fixed widget; in the pack's own full example it's worst quality, low quality, blurry, watermark, text, feeding an SDXL base checkpoint at 1024×1024 with dpmpp_2m/karras, 25 steps, CFG 7.

The nice part: cycling shots is free

Because shot_index is a widget on this node, changing it invalidates only this node and everything downstream. The Storyboard node upstream sees unchanged inputs, so ComfyUI doesn't re-execute it - no API call, no credits burned. You can walk 1→40 changing nothing else and only pay for the generations you actually look at. That's the whole reason this pair of nodes is pleasant to iterate with, and it's the reason the pack doesn't try to batch your shots for you.

What this node does not do is anything about consistency. It's a text router; it has no idea that shot 4 and shot 19 are the same character. Keeping a face stable across forty generations is a downstream problem - a character LoRA, a reference image stack, or simply reusing a seed and prompt skeleton - and it's the part of multi-image storytelling that still eats the hours. Splitting the shots just gets you to the point where you can work on it one frame at a time.

Install

Same pack, same steps: ComfyUI Manager → search Jingyuma Storyboard (publisher huchengAI), or:

cd ComfyUI/custom_nodes/
git clone https://github.com/huchengAI/comfyui-jingyuma-storyboard.git
pip install -r requirements.txt

Restart, and the three nodes appear under the Jingyuma category. The dependency is requests and nothing else - no models to fetch. The node itself needs no API key, but the node feeding it does, so register at https://shotstory.cn/?register=1 (phone + SMS, key lands in your clipboard) before anything upstream will run.