Chusky media generation

Read the media tool boundary first. The
runtime tool surface is deliberately small and provider-neutral.

Tool	Role
CHUCK_GENERATE_IMAGE	New image from a text prompt; delivered through the normal channel.
CHUCK_GENERATE_VIDEO	New video from a text prompt; queued asynchronously for delivery.
Daytona + CHUCK_ARTIFACT	Deterministic processing or validated artifact packaging for a real file.

Important boundary. The native image/video tools are provider-neutral. They
can deliver through Telegram and can save generated bytes into Daytona when the
call uses destination: "daytona" or "both". Image saving is available in
the current turn; video saving is asynchronous and the returned path is usable
only after workflow completion. They remain prompt-only: source-aware edits,
multi-reference generation, and generative animation of a particular still are
not exposed. Use Daytona for deterministic work on a real saved/uploaded file.

Apply this whenever media generation or processing is considered.

Handle flow (mandatory mental model)

generate → choose destination → verified Daytona path when requested → inspect/process → deliver or register

• Use only paths that actually came from a user upload or verified Daytona result.
• Do not claim a generated media path or artifact unless the host returned one.

Workspace-first creative workflow

When the user asks for an app, website, game, interface, brand asset, or a
multi-file design, treat Daytona as the working computer:

1. Create or inspect the user's Daytona workspace with
   CHUCK_DAYTONA_WORKSPACE.
2. Generate visual source material with CHUCK_GENERATE_IMAGE using
   destination: "daytona" or "both". Choose a deliberate path such as
   assets/generated/hero.png, and use the returned path rather than guessing.
3. Use Daytona commands and files to compose the generated material with the
   real UI, code, typography, responsive layout, and project assets. Keep exact
   copy, data, icons, and geometry code-authored.
4. Run the app in a durable Daytona PTY, verify it with a Daytona preview URL,
   browser inspection, and screenshots, then iterate on the actual files.
5. For a finished image/video or project bundle, register the verified file with
   CHUCK_ARTIFACT; for a running site, return the verified
   CHUCK_DAYTONA_PREVIEW URL. A local filesystem path alone is not a user link.

For an ordinary “make me an image” request with no workspace work, use
destination: "telegram". For a design task where the user needs to see both
the source and the resulting app, use destination: "both".

Build accurate visuals with code, not the image tools

1. Image models are unreliable at exact text, numbers, and structure. They can handle short text or a simple layout, but they often garble words, invent numbers, draw chart bars that match no data, or point diagram arrows nowhere, and the more that has to be exact, the worse they do. A detailed prompt doesn't make it dependable, and another Daytona deterministic image processing edit usually won't fix it. So when a result needs specific text, data, or structure to be correct (charts from real numbers, labeled or technical diagrams, math explainers, tables, screens with real copy), construct the asset with code, where you control the exact content. Prefer HTML and CSS, which give much better layout, typography, and polish than Python plotting. When only the look matters (photos, illustrations, characters, scenes, decorative art), the image tools are the right choice. Which one fits depends on what the output needs to get right, not on how the request is worded.

Verifying discrete accuracy (loop)

When the output must get specific text, numbers, data, or structure right, don't trust the first result - verify it in a loop:

1. Produce the result (generate, or per Build accurate visuals with code, construct it in code).
2. Inspect the actual output - use read_file (image understanding) on the result path - and confirm every word, number, label, and structural detail matches the requirement, and that nothing overlaps, clips, or runs off-canvas.
3. If anything is wrong, fix and re-verify:
   • Garbled text, invented numbers, or broken layout from an image model? Don't just re-prompt - it will likely garble it again. Rebuild it with code.
   • Overlapping or clipped elements in code-built output? Re-lay-out with auto-layout (HTML/CSS) rather than nudging coordinates by hand.
   • Otherwise make one targeted edit via Daytona deterministic image processing with the prior path.
4. Only finish when the discrete content is exactly correct. If it can't be made accurate, tell the user instead of shipping something wrong.

Core Principles

1. You own the prompt. If the user gives a detailed prompt or asks you to use theirs, use it verbatim. Otherwise craft the final prompt: front-load the subject, give strong high-level direction for mood, composition, lighting, and style without over-specifying every detail, write natural prose rather than keyword tags, and describe positively instead of using negative prompts. For edits, describe only what changes. Target 2-5 sentences.
2. Reference-first for real people. Never use pure text-to-image for a named real person or group, including face swaps, posters, cartoons, and cinematic or editorial depictions. Use Daytona deterministic image processing with a real reference path instead, and never produce non-consensual, sexualized, or minor-involving likenesses. See Real People and References for the procedure.
3. Ground facts with search first. If any part of the request depends on a real-world fact, identity, brand or product, place, event, or top/latest/current result, search the web before generating and put the actual verified details into the prompt. Don't rely on memory, and don't write vague placeholders like "the current president"; write the verified name.
4. Reuse a base for consistency when a real file exists. Keep a verified
   user-uploaded or Daytona-generated base for deterministic variations. The
   current CHUCK_GENERATE_IMAGE tool is prompt-only and does not return a
   source path for generative editing; do not invent one.
5. Handle failures gracefully. On a moderation or safety block, stop; don't retry and don't paraphrase the prompt to evade the filter. Tell the user it was blocked and offer a different direction. If a reference is weak or a result looks off-target, say so and ask for an upload or redirect rather than silently iterating.
6. Plan multi-step workflows. Sequence the steps; only parallelize generations that belong to the same step.
7. Review at the end. Confirm the generations you intended actually
   executed and match what was asked. Use the normal channel delivery result.
8. Don't assume tool behavior. Don't invent tool parameters, return values, or environment capabilities that aren't actually provided; verify rather than guess.

Choosing the tool

Situation	Call
New image for chat	CHUCK_GENERATE_IMAGE with { prompt, destination: "telegram" }
New image for workspace/design	CHUCK_GENERATE_IMAGE with { prompt, destination: "daytona" } or "both"
New video for chat	CHUCK_GENERATE_VIDEO with { prompt, destination: "telegram" }
New video for workspace/design	CHUCK_GENERATE_VIDEO with { prompt, destination: "daytona" } or "both"
Resize, crop, compose, convert, or inspect a real file	Daytona tools
Deliver a validated binary or project bundle	CHUCK_ARTIFACT

The current native generation tools are prompt-only. Source-aware editing,
multi-reference generation, and image-to-video are not available in this
runtime. Do not substitute a text-only generation when the source is essential.

CHUCK_GENERATE_IMAGE

Generate a new image from a text prompt.

Inputs:

• prompt (required) - full description of the desired image.
• The live tool accepts prompt, optional destination, and optional
  workspacePath; it does not accept aspect-ratio or source arguments. If exact
  dimensions matter, save to Daytona and build or normalize the asset there.

To produce multiple variations, make multiple calls with distinct prompts.

Source-aware generation

The current Chusky surface has no native source-aware image editor, multi-
reference image operation, or local image-to-video operation. For deterministic
changes to a real image, use Daytona. For a generative source-aware request,
state the limitation and ask for a supported alternative; never invent a tool
call or a returned path.

CHUCK_GENERATE_VIDEO

Generate a new video from a text prompt only (no source frame).

Inputs:

• prompt (required) - short present-tense shot description. The tool is
  asynchronous and the completed video is delivered through the normal channel.

Use destination: "daytona" or "both" when the clip is part of a workspace
pipeline. A video destination path is reserved when the job is queued and is
reported again after the workflow writes the completed bytes. Do not start
ffmpeg, sprite extraction, or artifact registration until completion is
confirmed.

For multi-shot work, make separate short generation requests, keep each prompt
to one clear beat, and assemble only verified local clips in Daytona. Do not
pretend that multiple shots are one completed video until the assembled file
has been inspected.

Do not invent a local video path or consume it before the asynchronous workflow
reports completion. If the user needs a video processed in Daytona, request the
Daytona destination, then continue from the reported verified path.

Writing Strong Prompts

Describe, roughly in this order: subject -> action/pose -> setting -> style -> composition -> lighting/mood -> key details.

• Be specific and concrete; lead with the most important elements.
• State what to include rather than what to exclude.
• Use one coherent scene per prompt.
• Match aspect_ratio to the use case: 9:16 for phone/story, 16:9 for banner/video frame or OG share cards, 1:1 for avatar/icon.

Real People and References

1. Search the web first to confirm identity, role, relationship, or event, even when it seems obvious.
2. Obtain a strong reference image on disk (user upload or verified Daytona
   path). Use it for deterministic Daytona work; the native generator cannot
   currently consume it as a generative source.
3. If no suitable reference exists, ask the user to upload one rather than
   silently generating a weak substitute.

Showing results

• Let the native tool's normal channel delivery show the generated image/video.
• For QC or scripts, use only a real user-uploaded or verified Daytona path.

Game sprites and maps have their own pipelines — follow generate2dsprite,
video2dsprite, and generate2dmap for those.

Failure modes to avoid

• Calling undocumented or provider-specific media helpers.
• Inventing a filesystem path that the native tool never returned.
• Running chroma/ffmpeg on a made-up path.
• Claiming that an asynchronous video job is already available locally.