Prompt Store Custom (CCN)
Five sections you get to name yourself
- headings
- prompt
- section_1
- section_2
- section_3
- section_4
- section_5
The built-in Prompt Store and Prompt Store B give you two hard-coded sets of labels - scene/detail vocabulary or quality/mood vocabulary. Prompt Store Custom is the escape hatch: the same session-memory storage, but you decide what the five sections mean.
You get five sections, named by wiring in a Prompt Store Headings node. Want sections called "subject", "lighting", "composition", "camera", "vibe" because that matches how you actually write? Now you can, and the sections store under those names like any other Prompt Store. If you don't wire headings (or leave them empty), the sections fall back to generic section_1…section_5 keys - fine, just less readable.
How it works
The mechanism is identical to the other stores: each section's text is stored under the store name in session memory, input_mode (override / merge / append) decides how new input combines with what's already there, empty inputs keep the stored value, and clear wipes it. There's one wrinkle the author handled nicely: store keys are lowercased from your headings so Prompt Store Get's case-insensitive lookup finds them, while the display names keep your original casing for prefix_sections output. If two headings collide after lowercasing (e.g. "Subject" and "subject"), they share a store key and the node emits the section only once - no double-prompting.
Inputs and outputs
- store_name / input_mode / separator / clear / delimiter / prefix_sections - the standard store controls.
- section_1 … section_5 - your five text boxes.
- headings - the CCN_PROMPT_HEADINGS input, wired from a Prompt Store Headings node.
- Outputs: assembled
promptplus section_1…section_5 individually, keyed in the order your headings defined.
Install
Part of ComfyCollectorNodes, one install:
cd ComfyUI/custom_nodes
git clone https://github.com/valkymaera/ComfyCollectorNodes
then restart, or install via ComfyUI Manager ("ComfyCollectorNodes"). No models, no extra deps.
Where people get burned
Two things. First, headings are per-node configuration via a wire - if you rename a heading, the stored values under the old key don't follow you, because the store already saved them under the old name. You'll see the classic "where did my text go" moment if you rename after saving. Second, the session-memory caveat from the rest of the family applies: values persist across workflows until restart, so a section from a previous session can resurface in an unrelated run. And if you expected the sections to be a fixed vocabulary - they're not, by design; the labels are just what you wired in.
Inputs (13)
| Name | Type | Default | Description |
|---|---|---|---|
| store_name | STRING | default | — |
| delimiter | STRING | \n\n | — |
| prefix_sections | BOOLEAN | false | — |
| clear | BOOLEAN | false | — |
| input_mode | COMBO | override | 3 options: override, merge, append |
| separator | STRING | , | — |
| section_1opt | STRING | — | |
| section_2opt | STRING | — | |
| section_3opt | STRING | — | |
| section_4opt | STRING | — | |
| section_5opt | STRING | — | |
| headingsopt | CCN_PROMPT_HEADINGS | Wire from Prompt Store Headings to name the five sections. | |
| debugopt | BOOLEAN | false | — |
Outputs (6)
| Name | Type | Description |
|---|---|---|
| prompt | STRING | — |
| section_1 | STRING | — |
| section_2 | STRING | — |
| section_3 | STRING | — |
| section_4 | STRING | — |
| section_5 | STRING | — |