Comfy UI Complete Toolkit

Portable ComfyUI workflow and API guidance for any install. Use when building, validating, or troubleshooting ComfyUI image/video workflows, discovering avai...

Security Scan

The skill's requests and instructions align with its ComfyUI troubleshooting/authoring purpose — it is an instruction-only, discovery-first toolkit that does not ask for unrelated credentials or install artifacts.

Purpose & Capability

The name/description match the runtime instructions: the SKILL.md consistently focuses on discovering a target ComfyUI install (via /object_info, /queue, /history, /prompt, /ws) and building/validating workflows. There are no unrelated requirements (no cloud creds, no system paths) and the manifest explicitly avoids machine-specific inventories.

Instruction Scope

Runtime instructions confine activity to querying the ComfyUI API, validating discovered node/model dropdown values, and building/submitting workflow JSON. The skill explicitly disallows embedding absolute filesystem paths or storing secrets in docs and instructs to ask the user for base URLs when unknown. It does not instruct reading arbitrary system files or environment variables outside the declared (none) set.

Install Mechanism

This is instruction-only with no install spec and no code files to write or execute. That is the lowest-risk install profile and matches the described portable guidance role.

Credentials

The skill declares no required environment variables, credentials, or config paths. It asks the user (or discovers) only for target ComfyUI base/websocket URLs and model names — which are appropriate and proportionate for the stated functionality.

Persistence & Privilege

always is false and the skill does not request persistent or cross-skill privileges. disable-model-invocation is the default (false) which is expected; nothing in the files suggests it would modify other skills or system settings.

Assessment

This skill appears coherent and portable. Before installing or using it, be sure you intentionally grant the agent access to the ComfyUI target you want it to manage: verify the base_url/websocket URL you provide (don’t hand over credentials or URLs for systems you don’t control), limit network exposure if possible (e.g., avoid giving access to internal-only services unless you trust the agent), and review any workflow submissions before approving large or expensive runs. If you need the agent to persist configuration, confirm that it will store that config in a user-owned location rather than a shared/global store.

ComfyUI Portable Skill

Use this skill when the task is to work with ComfyUI in a reusable, installation-agnostic way.

Minimum trigger scope

Trigger on requests like:

• "Build a ComfyUI workflow"
• "Fix this ComfyUI workflow"
• "Use the ComfyUI API"
• "Why is this ComfyUI graph failing?"
• "Add a LoRA / model / node to this ComfyUI setup"

Do not assume any particular machine, model inventory, file layout, GPU, or custom node pack.

First move: assume zero install knowledge

Before writing or editing any workflow:

1. Read references/setup.md.
2. If the install is unknown, collect the missing setup fields from the user or discover them from the running ComfyUI instance.
3. Prefer discovery over assumptions:
   • use /object_info to detect node classes and model dropdown values
   • confirm checkpoints, VAEs, encoders, and LoRAs from the target install
   • stop and report missing requirements clearly

Read path by task

• Setup / first run / portability questions -> references/setup.md
• API submission / queue / history / WebSocket -> references/api.md
• Programmatic graph building -> references/workflow-patterns.md
• Model-family requirements -> references/models.md
• Cross-family validation / node availability -> references/compatibility.md
• LoRA loading and compatibility -> references/lora.md
• Prompt construction -> references/prompting.md
• Graph hygiene / debugging -> references/graph-conventions.md
• Release history -> references/changelog.md
• User-fill config template -> references/config-template.md

Global operating rules

• Treat node classes as discoverable, not guaranteed constants.
• Treat model filenames as examples until confirmed on the target install.
• Use filename-only model references in workflow JSON unless the install explicitly requires a subdirectory path.
• Use defensive parsing for /history and /object_info; schema details can vary by ComfyUI version and custom nodes.
• Fail fast when a required node class, model, or custom node is missing.
• Keep setup-specific notes out of this file; put them in a per-user config or setup reference.

Cold-read test

Before publishing or packaging changes, check that a fresh reader could answer:

• What does this skill do?
• When should it trigger?
• What must be discovered first?
• Where do install-specific values go?
• Which reference file should be opened for the current task?