Studio Delivery Plan

Every studio has that person who renames deliverables by hand and every file ends up as final_v2_REAL_v3_use_this.png. MKRStudioDeliveryPlan is the pack's answer: one node that holds every naming and metadata decision for a shot - project, sequence, shot, take, version, deliverable type, department, client, reviewer - and emits a consistent filename prefix plus a delivery_plan_json that every other Studio node can consume. Define it once, and slate, review frames, contact sheets, delivery sheets, and notes all agree on the same identity.

This is the spine of the MKRShift Studio pipeline. The other nodes' optional delivery_plan_json inputs exist to be fed by this. So the smart way to build a review workflow is: MKRStudioDeliveryPlan first, then wire its JSON into everything downstream.

The inputs that matter

• project / sequence / shot / take / version_tag - the identity core. These are what end up in the filename, so get them right the first time.
• deliverable - Review, Client Selects, Contact Sheet, Turnover, or Social Cut. This changes how the plan presents itself (a Contact Sheet deliverable expects a contact sheet; a Turnover expects an asset manifest).
• naming_mode - Compact, Editorial, or Client Friendly. This is the file-naming dialect: compact is short and pipeline-friendly, editorial is descriptive, client friendly drops the cryptic tokens.
• include_take / include_date / include_artist / include_client - toggles for what lands in the filename. Client-friendly mode + include_client = a filename a client can parse.
• extension - default png; the file type for the deliverable.

Optional inputs let you fold in the other Studio nodes' output - slate_json, review_frame_info, contact_sheet_info, selection_manifest_json, notes_json - so the plan reflects the whole review session, not just the shot card.

What comes out

• filename_prefix and subfolder - wire these into the pack's save/publish nodes and your exports land with the agreed names in the agreed folders.
• review_title - the title for the review package, derived from your metadata.
• manifest_notes_json - notes and manifest material combined.
• delivery_plan_json - the plan itself; the input to MKRStudioDeliverySheet and MKRStudioReviewNotes.

Installing it

Part of criskb/MKRShift_Nodes from Cris K B. ComfyUI Manager search "MKRShift_Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes

Restart. No pip requirements, no models.

The trap

The plan only helps if it's actually wired through. If you type the same metadata into the slate, the review frame, and the save node separately, you're back to hand-maintained naming and this node is decoration. The payoff is in the wiring: let the plan be the single source of truth and the whole Studio cluster stays in sync. It's plumbing, but it's the plumbing that kills the _FINAL_v4 filenames.