MiniMax H3 Chained Multishot Output

Chained multishot is the pack's way of generating a multi-scene video as separate passes: instead of one prompt trying to do everything, you get a JSON array of autonomous prompts, one per shot, each complete enough to render on its own. The problem is that a JSON array is not what H3 multishot samplers ingest - they want a script. The MiniMax H3 Chained Multishot Output node is the adapter between those two shapes: it validates your canonical JSON, checks it against the multishot contract, and emits the ----separated script the samplers accept.

How it works

The format is deliberately simple on the input side - a JSON object with a prompts array, where each element is a standalone prompt string for one shot:

{
  "prompts": [
    "Shot 1 complete autonomous prompt text...",
    "Shot 2 complete autonomous prompt text...",
    "Shot 3 complete autonomous prompt text..."
  ]
}

Feed that into prompts_json and the node does three jobs. First, it normalizes the input - canonicalizing the JSON so subtle formatting drift can't break the parser downstream. Second, it validates it against the chained-multishot contract: expected shot count, continuity locks, and the H3 structure of each item. Third, it joins the cleaned prompts with --- separators into multishot_script, which is the string you wire into your H3 multishot sampler.

The inputs that matter

• prompts_json - the array of shot prompts. If you're building this from the enhancer, the pack's multishot path hands you the canonical JSON; this is where it lands.
• duration_per_shot - seconds per shot, default 5. The tooltip is worth quoting: H3 was trained around 5–15 seconds; longer generations are experimental and need much more memory.
• expected_shot_count - set it if you know how many shots you're expecting; a mismatch fails validation rather than silently producing a wrong-length script.

The three continuity locks - identity_lock, voice_lock, setting_lock - are the interesting part. Each is free text describing who the characters are, what their voices sound like, and where the scene takes place. In a chained pipeline these get repeated verbatim into every segment, because each shot renders as an independent pass and nothing carries state between them. That repetition is the whole trick behind keeping a character looking like the same person across three separately-rendered shots. If you're generating with the enhancer's chained_multishot mode, these same strings feed the locks there - this node re-checks them so the final script can't drift.

Outputs

multishot_script (the ----joined string for the sampler), prompts_json (the normalized JSON, for feeding the next stage or saving), valid (boolean), validation_report (JSON diagnostics), and total_duration_seconds - duration_per_shot × shot count, handy for configuring the downstream sampler's total length without doing the multiplication in your head.

Install

Same pack, same command:

cd ComfyUI/custom_nodes
git clone https://github.com/hyukudan/ComfyUI-MiniMax-H3-Prompt-Enhancer.git

Restart ComfyUI. Pure string/JSON work here - no model, no API, no dependencies.

The gotcha

Because each shot is fully autonomous, the quality of the final video is only as good as the weakest segment. The validator will tell you if a segment is structurally broken, but it can't tell you if shot 2 forgot who the protagonist is - that's what the continuity locks are for. If you're seeing characters change appearance between shots, the locks were probably left empty. And keep duration_per_shot honest: four shots at 30 seconds each is technically allowed, but you're squarely in the experimental zone and your VRAM will let you know.