Skill v1.0.1
currentAutomated scan96/100+5 new
version: "1.0.1" name: comfyui-core description: Core ComfyUI knowledge — workflow format, node types, pipeline patterns, and MCP tool usage globs:
- "**/*.json"
ComfyUI Core Knowledge
Workflow JSON Format (API Format)
ComfyUI workflows are JSON objects mapping string node IDs to node definitions:
{"1": {"class_type": "CheckpointLoaderSimple","inputs": { "ckpt_name": "sd_xl_base_1.0.safetensors" },"_meta": { "title": "Load Checkpoint" }},"2": {"class_type": "CLIPTextEncode","inputs": { "text": "a cat", "clip": ["1", 1] },"_meta": { "title": "Positive Prompt" }}}
Key Rules
- Node IDs are strings of integers (
"1","2", etc.) - `class_type` is the exact Python class name of the node
- `inputs` contains both widget values (scalars) and connections (arrays)
- Connections use the format
["sourceNodeId", outputIndex]— a 2-element array where: - First element: string node ID of the source node
- Second element: integer index into the source node's
outputlist (0-based) - `_meta` is optional, used for display titles only
Connection Examples
"model": ["1", 0] // Connect to node 1's first output (MODEL)"clip": ["1", 1] // Connect to node 1's second output (CLIP)"vae": ["1", 2] // Connect to node 1's third output (VAE)"positive": ["2", 0] // Connect to node 2's first output (CONDITIONING)"samples": ["5", 0] // Connect to node 5's first output (LATENT)"images": ["6", 0] // Connect to node 6's first output (IMAGE)
Important: API Format vs Web UI Format
- API format (for execution/analysis):
{ "1": { class_type, inputs }, "2": { ... } }— compact, used byenqueue_workflow,validate_workflow,modify_workflow, etc. - Web UI format (for saving and frontend editing):
{ "nodes": [...], "links": [...] }— includes layout positions, sizes, groups, and visual metadata so ComfyUI's canvas can open and edit it - Execution tools expect and return API format
- Save in Web UI format so saved workflows stay readable and editable in the ComfyUI frontend. A raw API-format save is NOT canvas-editable — it "exists" in the library but loads blank in the canvas, which strands users (and tempts agents into creating yet another new workflow instead of reopening the old one). Because of this,
save_workflowauto-converts API-format input to Web UI format with a generated layout — but prefer passing real Web UI format (fromget_workflow format="ui") since a generated layout loses the original node positions/groups <!-- API-vs-UI save-format clarification adapted from 1696762169/comfyui-mcp@3da56c9 --> get_workflowdefaults toformat="api"for analysis/execution; useformat="ui"when loading a workflow to re-save or edit in the canvas- Muted/bypassed nodes are preserved with
_meta.mode: "muted"— these are inactive but visible for understanding the workflow - Get/Set virtual wire nodes are preserved with
_meta.titleandConstantkey for tracing data flow
Workflow Library Tools
- `analyze_workflow(filename)` — use this first to understand any saved workflow. Returns a structured text summary with sections, node IDs, key settings, virtual wires, and connection graph. No raw JSON — just what you need to reason about the workflow. Supports views: summary (default), overview (mermaid), detail (section mermaid), list, flat.
- `list_workflows` — list all saved workflows in ComfyUI's user library
- `get_workflow(filename)` — load raw workflow JSON. Only use when you need the actual JSON for
enqueue_workflow,modify_workflow, orsave_workflow. Useanalyze_workflowinstead for understanding. For `save_workflow`, request `format="ui"` so the workflow stays editable in the frontend. - `save_workflow(filename, workflow)` — save a workflow to the user library. Pass Web UI format (`{ nodes, links }`) so it keeps its real layout in ComfyUI's canvas. API-format graphs are accepted and are auto-converted to Web UI format (with a generated layout) precisely because a raw API-format save is not canvas-editable — the frontend cannot open it. When re-saving an existing workflow, load it with
get_workflow format="ui"and edit that, so positions/groups survive.
Data Types
ComfyUI nodes pass typed data through connections:
| Type | Description | Common Source | |
|---|---|---|---|
MODEL | Diffusion model weights | CheckpointLoaderSimple (output 0) | |
CLIP | Text encoder | CheckpointLoaderSimple (output 1) | |
VAE | Variational autoencoder | CheckpointLoaderSimple (output 2) | |
CONDITIONING | Encoded text prompt | CLIPTextEncode (output 0) | |
LATENT | Latent space tensor | EmptyLatentImage, KSampler, VAEEncode | |
IMAGE | Pixel image tensor (BHWC) | VAEDecode, LoadImage, SaveImage | |
MASK | Single-channel mask | LoadImage (output 1) | |
UPSCALE_MODEL | Upscaling model | UpscaleModelLoader |
Standard Pipeline Patterns
Text-to-Image (txt2img)
CheckpointLoaderSimple → MODEL, CLIP, VAE├─ CLIP → CLIPTextEncode (positive) → CONDITIONING├─ CLIP → CLIPTextEncode (negative) → CONDITIONING│EmptyLatentImage → LATENT│KSampler (model, positive, negative, latent_image) → LATENT│VAEDecode (samples, vae) → IMAGE│SaveImage (images)
Node IDs typically: 1=Checkpoint, 2=Positive, 3=Negative, 4=EmptyLatent, 5=KSampler, 6=VAEDecode, 7=SaveImage
Image-to-Image (img2img)
Same as txt2img but replace EmptyLatentImage with:
LoadImage → IMAGEVAEEncode (pixels, vae) → LATENT → KSampler.latent_image
Set KSampler.denoise to 0.5–0.8 (lower = closer to input image).
Upscale
LoadImage → IMAGEUpscaleModelLoader → UPSCALE_MODELImageUpscaleWithModel (upscale_model, image) → IMAGESaveImage (images)
Inpaint
LoadImage (image) → IMAGE → VAEEncode → LATENTLoadImage (mask) → MASKSetLatentNoiseMask (samples, mask) → LATENT → KSampler.latent_image
MCP Tool Usage Guide
Quick Generation
create_workflowwith template"txt2img"and your paramsenqueue_workflowwith the returned JSON — returnsprompt_idimmediately- Poll
get_job_statuswith theprompt_iduntildoneis true - Use
list_output_images(limit 1) to find the generated image, thenReadto display it
Inspect & Modify
get_node_info— query what nodes are available and their schemasmodify_workflow— patch an existing workflow (set_input, add_node, remove_node, connect, insert_between)visualize_workflow— see a workflow as a mermaid diagram
Reverse Engineering
visualize_workflow— workflow JSON → mermaid diagrammermaid_to_workflow— mermaid diagram → workflow JSON (uses/object_infofor schema resolution)
Model Management
list_local_models— see what's installedsearch_models— find models on HuggingFacedownload_model— download to ComfyUI's models directory
Important: Never ask the user to manually download models. If a required model is missing, proactively search for it and download it yourself:
- Check
list_local_modelsfirst - If missing, search HuggingFace via
search_modelsor CivitAI via their REST API - Use
download_modelto install it directly to the correct subfolder
CivitAI API (when CIVITAI_API_TOKEN env var is available):
- Search:
GET https://civitai.com/api/v1/models?query={query}&types=Checkpoint&sort=Most+Downloaded&limit=5 - Details:
GET https://civitai.com/api/v1/models/{modelId} - Download:
GET https://civitai.com/api/download/models/{modelVersionId}?token={token}
CivitAI is preferred for fine-tuned models, community-rated checkpoints, and specialized LoRAs. HuggingFace is preferred for official/base models (SDXL, Flux, SD 1.5).
Custom Nodes
search_custom_nodes— search the ComfyUI Registryget_node_pack_details— get details about a specific packgenerate_node_skill— auto-generate a skill file for a node pack
Workflow Execution
enqueue_workflow submits to ComfyUI's queue and returns prompt_id + queue position immediately. It does NOT block.
Background Progress Monitoring
After enqueuing one or more workflows, use a background Bash task to monitor progress silently:
# Single jobBash(run_in_background: true):node "${CLAUDE_PLUGIN_ROOT}/scripts/monitor-progress.mjs" <prompt_id># Multiple jobs (batch)Bash(run_in_background: true):node "${CLAUDE_PLUGIN_ROOT}/scripts/monitor-progress.mjs" <id1> <id2> <id3>
The script connects to ComfyUI's WebSocket and reports:
- Step-by-step progress (e.g.,
KSampler step 12/20 (60%)) - Success with output filenames and timing
- Errors with node details and messages
Standard generation pattern:
create_workflowor build workflow JSON +enqueue_workflow(repeat for batch)- Start background monitor with all prompt_ids
- Continue conversation — results appear when jobs finish
- Use
list_output_imagesorReadto display the generated images
Do NOT poll get_job_status in a loop. The background monitor replaces polling entirely.
Fallback: If the monitor script is unavailable, use get_job_status to poll until done is true.
Queue Management
get_queue— shows running/pending job counts and prompt_idsget_job_status— check if a specific prompt_id is running, pending, or donecancel_job— interrupt a running job (pass optionalprompt_idto target a specific one)cancel_queued_job— remove a specific pending job from the queue byprompt_idclear_queue— remove all pending jobs (does NOT stop the currently running job)
When to use queue tools:
- To check status:
get_job_statusfor a quick boolean check (prefer background monitor for ongoing tracking) - To abort:
cancel_jobstops what's running now;cancel_queued_jobremoves a pending one - To start fresh:
clear_queuethen optionallycancel_job
Monitoring & Recovery
get_system_stats— GPU, VRAM, Python version, OS detailsget_queue— see running/pending jobs (also listed above under Queue Management)
When ComfyUI is unresponsive or crashed:
- Try
get_system_stats— if it fails, ComfyUI is down - Use
restart_comfyuito restart it (preserves launch args from priorstop_comfyui) - If restart fails (no saved process info), use
start_comfyuior ask the user to start it manually - After ComfyUI is back, re-enqueue any failed/lost workflows
When a job appears hung (monitor shows `[STALL]`):
- Check
get_system_stats— look at VRAM usage (OOM causes hangs) - Try
cancel_jobto interrupt the stuck job - If cancel fails, use
restart_comfyuito force-restart - Use
clear_vramafter restart to free GPU memory before retrying
KSampler Parameters
| Parameter | Type | Common Values | |
|---|---|---|---|
seed | int | Random (0 to 2^48). Omit to auto-randomize. | |
steps | int | 20 (standard), 4-8 (turbo/lightning models) | |
cfg | float | 7-8 (SD 1.5/SDXL), 1.0 (Flux), 3.5 (turbo) | |
sampler_name | string | "euler", "euler_ancestral", "dpmpp_2m", "dpmpp_sde" | |
scheduler | string | "normal", "karras", "sgm_uniform" | |
denoise | float | 1.0 (txt2img), 0.5-0.8 (img2img), 0.75-0.9 (inpaint) |
Mermaid Visualization Conventions
The visualize_workflow tool produces mermaid flowcharts with:
- Subgraphs grouping nodes by category:
loading,conditioning,sampling,image,output - Edge labels showing data types:
-->|MODEL|,-->|CLIP|,-->|LATENT|, etc. - Node labels showing class_type and optionally widget values
- Direction:
LR(left-to-right) by default,TB(top-to-bottom) for large workflows
The mermaid_to_workflow tool parses mermaid back into workflow JSON, using connection type labels to resolve the correct input/output slots via /object_info schemas.
Common Mistakes to Avoid
- Wrong connection format: Use
["1", 0]not[1, 0]— node IDs are strings - Web UI format: Don't pass
{ nodes: [], links: [] }— use API format - Missing VAE: CheckpointLoaderSimple has 3 outputs — MODEL(0), CLIP(1), VAE(2)
- Wrong output index: Check the node's output list order via
get_node_info - Seed handling:
enqueue_workflowrandomizes seeds by default unlessdisable_random_seed: true