Save System Prompt

Why bother

You spend an evening tuning a captioning instruction. The captions come out right - dense, plain, no "Certainly!", no hallucinated backstory. And that prompt is now sitting in a text widget on one node in one workflow, which is the least durable place you could have put the most valuable thing you made.

Save System Prompt is the write half of the pack's prompt library. It takes a system prompt, writes it to ComfyUI/user/was-node-suite/system_prompts as a .txt or .md file with front matter describing it, and hands the text straight back out so the same run can use it. Load System Prompt sees the file immediately - no restart, no refresh.

That loop is the useful part: experiment in a graph, when you land on something good, save it from the graph, and every future workflow loads it by name. If you're building a caption corpus for a LoRA the way the KB's lora-training doc describes - auto-caption a big set with a VLM, audit a small one by hand - a stable, versioned instruction file is the thing that keeps run 1 and run 400 describing images the same way.

How it works

It writes a real file, in plain text, with YAML front matter on top:

---
name: Detailed Caption
description: One dense paragraph for training captions
model_family: [Qwen, Gemma]
---
You describe pictures for an image model in one plain paragraph.

name becomes the library label and the filename, so Detailed Caption writes Detailed Caption.txt. Characters a filename can't hold turn into _. folder makes a nested path inside the library (Captioning/Qwen) and creates it if it's missing; leave it empty to save at the top.

The node is fussy about one thing and rightly so: the folder is an allowlist. A Windows drive letter, a leading /, or .. anywhere gets refused, because a node that writes arbitrary files wherever a workflow says is a liability, not a feature. It's the same instinct as the pack's read allowlist.

If the text you save already begins with front matter, that front matter is kept - with name, model_family and description overwritten by whatever you put in the widgets. Any other keys (tags, say) survive. Same for reading: the front matter never reaches the model.

Then it returns the text without front matter, and that's deliberate - you can chain it directly into a model's system_prompt input and get the clean prompt, not a prompt with YAML stapled to the top.

Inputs and outputs

The ones that matter for a first run:

• system_prompt - the instructions, multiline. Type them, or wire them in from a text node.
• name - what the library will call it, and the filename. Leave this empty and the node errors, which surprises people on the first try.
• overwrite - off by default, and with it off, saving a name that already exists stops with an error unless the text is byte-identical, in which case it reports "unchanged" and moves on.

The rest: folder, model_family (comma-separated, used for filtering in the loader), description (one line, shown under the name), and file_type - txt or md. Pick md if you're writing skill files, since the loader treats a folder's SKILL.md as that folder's entry.

Outputs are system_prompt (the saved text, front matter stripped) and name (the name it was saved under). The node is an output node, so it runs when it's in the executed branch even if nothing downstream needs its sockets.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui.git

Or Manager, search WAS Node Suite v3. ComfyUI 0.14.0+ and Python 3.10+, no pip step - requirements.txt is a comment and nothing is installed on start. First launch writes the config and the folder tree under ComfyUI/user/was-node-suite/, which is also where your saved prompts live, so they survive pack updates.

Where people get burned

overwrite is off and you forgot. The second save of Detailed Caption errors out. Flip the checkbox if you meant to replace it; leave it off if you want the mistake to be loud.

Empty name, empty text. Both are errors. Wire a text node that came back empty and the run stops here, which is the right time to find out.

Saving something you can no longer edit. Once it's a file, it's a file - edit it in a text editor or overwrite from the graph. There's no in-node editor for the library; that's what the folder is for.

Assuming a save means a reload. A prompt saved and then loaded in the same run does work - the loader validates any key and reads fresh from disk - but if you saved over a prompt an already-executed node used earlier in that run, the earlier node read the old text. Order in the graph is order of execution.