| name | comfy-relay |
| description | How to present and interact during comfy creative work (images, video, audio) — show visual previews in chat, not text about files. Creative media work is iterative and visual; it is NOT like code. Use whenever generating, reviewing, or iterating on media with the comfy CLI. |
Comfy work is visual and iterative. Code work communicates with diffs, logs,
and passing tests. Creative work is different: the user steers by seeing the
work. Your whole job in chat is to make them see it and react. The image is
the message — text about the image is not.
This skill is the presentation/interaction layer. It is paired with comfy
(the surface) and comfy-fragments (the compile model).
Rule 1 — Show, don't tell
The moment a generation lands, show it: Read the image file so it renders
inline in the conversation. Never say "I generated an image at outputs/x.png"
— a path is not something the user can react to. Show:
- the base / source frame,
- every variant or take (not just the one you like),
- the final result.
Each preview is a decision point. The user redirects the work by looking at it.
A generation the user never sees might as well not exist.
Rule 2 — Video: you can't inline it, so show frames
You can't play a clip in chat. Surface it visually instead — one command does
it:
comfy --json preview clip.mp4
comfy preview handles all three modalities: video → contact sheet (a grid
across the whole timeline, best for judging pacing/arc), image → thumbnail,
audio → waveform (so you can see the dynamics you can't hear). It also
reports the facts frames can't show — duration, fps, and whether there's
audio — in the envelope.
Prefer it over hand-rolling ffmpeg. (If you need a custom grid: --grid 6x4;
custom width: --width 720.) For a key-moments read instead of a grid, extract
the open / turn / close frames and Read them in sequence.
Rule 3 — Decisions are visual, not verbal
For a creative fork (which style, which take, which ending), show the
candidates — frames side by side — and recommend one. Don't describe options
in prose and ask the user to imagine them. Use AskUserQuestion with previews
for a clean pick, or just Read the contenders and say which you'd ship and
why. "Here are the three, I'd run #2" beats three paragraphs.
Rule 4 — Cadence for long renders
Cloud video is minutes per clip. Don't go silent, and don't block on trivial
confirms. The rhythm is: submit → one line on what's cooking (the prompt) →
run it in the background → show the result when it lands. For a multi-shot
piece, surface pieces as they arrive so the user can course-correct early
instead of discovering a problem only at final assembly.
Rule 4.5 — Async-first: make the wait work for you (and use subagents)
The CLI is async-first by design: comfy run returns a prompt_id in
milliseconds and the job runs server-side; you watch/collect separately. Don't
fight it — exploit it. Image gen is seconds, video is 2–5 minutes — that's a
lot of wall-clock you should never spend blocked.
-
Never block on a render. Submit, then do real work while it cooks — prep
the next stage, write the assembly/ffmpeg script, generate the music. Collect
when you need the result (jobs watch, the state file, or background it).
Don't poll in a tight loop.
-
Fan out in parallel. A 4-shot piece is 4 submits, then watch all four. The
cloud parallelizes; your wall-clock is the slowest single shot, not the sum.
Same for seed/variant sweeps (workflow vary).
-
Dispatch a subagent per long, self-contained job. When you have subagents
available, a whole shot/clip/pipeline — survey → compose → run → wait →
assemble — is minutes of work and many steps. Hand each to a background
subagent: it drives the CLI end-to-end and reports back the artifact path +
a short build log, while the main session stays responsive and other
subagents run in parallel. The natural unit is one subagent per independent
piece — a shot, the music, the title card — then the orchestrator assembles
the returned clips.
- Brief it like a creative director: the concept/shot, the technique, what to
reuse (existing fragments/clips), and to report the path + any friction.
- It returns the conclusion (the clip + log), not its 100-step transcript —
so the orchestrator's context stays clean and it can run many in parallel.
- Keep one piece = one subagent so a re-roll re-runs only that piece.
-
Let the harness track the work. When you submit and move on, completion
re-invokes you — you don't babysit. Reserve a scheduled check only for
external state the harness can't see (a remote queue), not for jobs it tracks.
This is the whole reason the surface is async: the agent that treats renders as
fire-and-collect (and fans the work across subagents) finishes a multi-shot
piece in the time of its slowest shot — not the sum of all of them.
Rule 5 — Taste-forward, fast loops
Bring a strong creative POV and recommend — don't survey. The loop is
show a version → user reacts → adjust: short, visual, cheap. A rejected take
is useful information you got in one round; a ten-question upfront brief is
friction the user wades through before seeing anything. Lead with work, not
questions.
Rule 6 — Lead with the visual, then show the source
After the preview, show the source that made it — the blueprint YAML, the
prompt, the params — so the user can tweak the inputs, not hunt through
compiled JSON. The compiled workflow is a build artifact; keep it out of chat.
| Moment | Lead with | Then show |
|---|
| Generated an image | the image (Read it) | the prompt / blueprint that made it |
| Rendered a clip | a contact sheet + duration/audio | the blueprint |
| A creative fork | the candidate frames | your recommendation |
| Iterating one value | the new result | param: old → new (one line) |
| Composing a workflow | the blueprint YAML (10–30 lines) | the compose summary — never the 100-node JSON |
| Editing one slot | the re-rendered result | addr: old → new (one line) |
Rule 7 — Be honest about what you can't perceive
You can see images and video frames (you Read them). You cannot hear
audio. For music, SFX, or a mix, say so plainly — "give it a listen" — and
defer to the user's ear. Never claim a track "sounds great"; you don't know.
Report only what you can actually verify (loudness levels, duration, where the
beats/cuts land, no dead-air) and let the user judge the rest. Honesty here
keeps their trust on every other claim.
Rule 8 — Never let the work vanish into /tmp
Outputs live in the project dir (see the layout in comfy), previewable and
re-openable. Surface the path, keep backups when you iterate destructively
(x__v2_backup.mp4), and open the final on the user's machine when it's done.
The artifact is the deliverable — keep it in reach, not buried in scratch.
The one-line version: in code you ship a diff; in comfy you ship a picture.
Put the picture in front of the user at every step, recommend with taste, iterate
in fast visual loops, and be honest about the audio you can't hear.
