H3 Context Plan

This is step two of the pack's smallest useful pipeline - Request → Plan → Compiler → Validator → Preview - and it's the step where your typed request becomes a structure with a shape you can inspect.

What it does

It normalises the typed request and assembles an explicit intent graph. Those are two jobs worth separating in your head.

Normalising means turning a request envelope into the canonical form the rest of the pipeline expects: task mode resolved, duration represented in a form H3 can deliver, hard constraints folded in as immutable constraints. If the incoming request contradicts itself, this is where it stops being a vague problem.

Assembling an intent graph means spelling out the structure of the shot - subjects, actions, scenes, camera, audio, timeline segments. And here's the design decision that defines the node: it does not infer from your prose. The node's description says the quiet part out loud - "omitted semantic detail remains a visible manual skeleton." What you didn't specify stays unspecified, marked as such, rather than being filled in by a language model reading between your lines.

That's the opposite of the usual prompt-enhancer pattern, where an LLM rewrites your rough idea into richer text and you find out later what it added (llm-in-comfyui.md). Many people want the enhancer. The argument for this approach is that a video prompt is a set of instructions, and instructions you didn't author are bugs you can't see (prompt-engineering.md).

Inputs and outputs

Required: request (H3_CONTEXT_REQUEST), from H3 Context Request.

Optional, both of which let you supply structure the plan would otherwise leave skeletal:

• reference_registry - explicit reference ownership from H3 Reference Registry. Connect it and the plan knows which assets exist and what roles they own.
• intent_graph - an explicit semantic graph from H3 Intent Graph Producer. The tooltip is a promise: no free-text inference. Hand it a graph and the plan uses that graph instead of a skeleton.

Outputs: plan (H3_CONTEXT_PLAN) and report (H3_CONTEXT_REPORT).

plan goes to H3 Context Compiler - that's the only consumer you need in the base route - and in longer chains it also feeds H3 Local Reconstruction Acceptance as a required stage. report goes to the Compiler's sibling nodes: H3 Context Validator, H3 Context Preview, and H3 Context Audit Override.

Install

The pack isn't in the Comfy Registry yet, so it's still a clone:

cd ComfyUI/custom_nodes
git clone https://github.com/rookiestar28/ComfyUI-MiniMaxH3-Studio.git
# restart ComfyUI

No Python dependencies declared (dependencies = []), nothing downloaded at install, prebuilt browser extension, Python 3.10+. You can run this entire pipeline with no model weights on disk - useful if you're writing prompts on a laptop and generating elsewhere, or if you want to teach someone what H3 expects before they commit 30GB of VRAM to it.

What the skeleton looks like

Think of the plan as a form you partially filled in. Fields you completed are assertions; fields you didn't are marked manual or unspecified, and the Compiler will render around them honestly - the pack's soundscape handling is the cleanest example, where an unmentioned soundscape stays visibly unspecified instead of being written as silence.

That's why the recommended beginner route goes Plan → Compiler → Validator rather than Plan → generate. The Validator is where "you didn't say anything about camera" becomes a diagnostic instead of a mystery. Fix what it names, re-plan, re-render.

Gotchas

The one that catches people: they expect reference_registry to be optional in the "not needed" sense and then wonder why the plan doesn't know about their reference images. Optional here means the socket can be empty - not that the plan will find the assets itself. On a reference-set job, wire the registry.

Second: an explicit intent_graph overrides the plan's own assembly. If you connect one and the output looks like it ignored half your request, the reason is sitting in that graph.

Third, a mild one that matters in longer chains: the plan is a normaliser, not a validator. It won't tell you your duration is unrepresentable - that happens at the timeline stage - and it won't catch a missing hard constraint. It builds the structure; the Validator audits it.