ImagineArt
ImagineArt v2.0.0
Publisher description
From the marketplace listing
ImagineArt creates images, videos, music, logos, ads and social artwork from your brief. You can also remove backgrounds, enhance images, apply effects and edit existing assets. Choose an ImagineArt workspace, browse earlier creations, and save reusable products, presenters, fashion models, outfits and shot settings. The ad studio brings product, presenter, format and output settings into one interface. Includes 17 guided skills for creative workflows, from product imagery and fashion to social content, sound and editing. Canva, Photoshop, After Effects, Premiere and Blender workflows require access to the corresponding application or a supported integration; those applications are not included with ImagineArt. Requires an ImagineArt account with access to the selected workspace. Generations use your plan's credits. Only supply reference photos of yourself or adults who have given you permission; reference media is processed by third-party AI providers.
Language: English · Automatically detected from descriptions.
Files & skills
File archives
Skill instructions
after-effects5.23 KB
--- name: after-effects description: Generate assets with ImagineArt and build them into an editable After Effects composition — layers, keyframes, animated text and precomps, then render. Use for motion graphics, logo reveals, animated titles and layered comps. Requires desktop access to After Effects. --- # After Effects Finishing Requires access to After Effects through an available integration or desktop controls. Check those capabilities before promising a project; verify save, reopen and render before reporting completion. The deliverable is an **editable composition** — layers, keyframes and live text a motion designer can keep working in. A rendered MP4 alone is what Motion already gives you. Read `references/after-effects-ui.md` before touching the app and `references/models.md` before generating. ## Tokens `/after-effects` `/ae` `/comp` `/animate-text` `/animate-logo` `/lower-third` `/render` `/logo-reveal` belongs to **Brand Studio**, which generates the reveal. Use `/animate-logo` here when the logo must be animated *inside an existing composition* instead. ## Step 0 — check what you have 1. **Is an integration available that explicitly supports After Effects?** Inspect its exposed tools before using it; an Adobe integration may cover a different application. 2. **Is computer use available**, with After Effects open or installed? 3. **Is there an open project and composition**, and what are its frame rate, duration and frame size? Everything downstream depends on these three numbers. If app access is unavailable, state that limitation. Offer an asset-and-timing handoff; generate assets only if the user wants that fallback. **Never imply a comp was created when it wasn't.** ## Before anything else — is this an edit or a build? **Inspect first. Generate only what the requested change actually needs.** "Change the headline", "trim this clip", "export this", "move that" are **edits**. They must not generate new artwork, footage or music. Open what exists, find the specific element, and change it. Only generate when something genuinely required is missing. A six-second clip asked to be five seconds gets **trimmed**, not regenerated. ## The preservation rule One rule, applied consistently: > **Preserve unrelated work. Modify exactly the element the user asked about. Verify the > change landed and that nothing else moved.** This is not "never replace anything" — the user may well want an element replaced. It means never touch what they didn't ask about. And note that *adding* is not automatically safe: a layer placed on top can hide what's beneath it, and a clip on a new track can duplicate audio. Check what your addition covers. ## Why this skill exists Diffusion models cannot render legible text or precise vector motion. After Effects can. So the division of labour is fixed: | ImagineArt generates | After Effects does | |---|---| | Backgrounds, footage, textures, 3D logo reveals | Text, titles, lower thirds, shape animation, precise timing | **Never ask a generation model for animated text.** Generate the plate; animate the type in AE. ## The workflow 1. **Read the comp's frame rate, duration and frame size.** Match everything to them. 2. **Generate a missing plate only if needed** with ImagineArt — background, footage, or a 3D logo reveal via `generate_3d_logo_animation` (which blocks up to a minute; say so before calling it). 3. **Import** File > Import > File, then drag into the open comp. 4. **Place assets at the intended layer position.** Keep backgrounds below titles; replace an existing layer only when the requested edit calls for it. 5. **Add text as live text layers**, then keyframe them. 6. **Precomp groups** that belong together, so the timeline stays readable. 7. **Verify by screenshot after each meaningful change** — read the timeline. 8. **Save the project, then render**, and confirm the output exists. 9. **Report** what you verified and what you couldn't. ## Hard rules - **Check footage timing against the comp's frame rate.** Preview mixed-rate footage; conform or retime only when needed and disclose timing changes. - **Never use fixed screen coordinates.** - **Text stays live.** Never a generated image of text, never converted to shapes unless asked — the point is that it stays editable. - **Never report a render you didn't confirm.** Renders queue and fail silently. - **If a step fails twice, stop** and describe what you see. ## Done means reopened, not queued "The render started" is not done. Before reporting: - The **project reopens with footage online**. - **Text layers are still live text**, keyframes intact. - The render output exists **and** its dimensions, frame rate and duration match the comp. - No pre-existing layer was hidden behind what you added. State explicitly what you verified and what you could not. ## The follow-up edit test "Change only the headline" must edit the text layer's source text and leave every keyframe, every other layer and the render settings untouched. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed.
Referenced files: 6
blender5.92 KB
--- name: blender description: Build or edit Blender scenes using ImagineArt reference images and textures — objects, materials, lighting, cameras, keyframes and verified renders. Use for editable .blend projects, product turntables, 3D scenes and material work. Requires Blender app access, a supported integration, or a local Blender executable. --- # Blender Studio Deliver an editable `.blend` project and the requested render or export. ImagineArt can supply reference images, texture artwork and backgrounds; build geometry and animation in Blender. An image or video that looks three-dimensional is not an editable 3D asset. Read `references/blender-workflow.md` before operating Blender, and `references/qa.md` before delivery. ## Tokens `/blender` `/blend` `/turntable` `/material` `/3d-scene` Use this skill when the user wants to work in Blender or receive an editable 3D scene. For only a generated product image, use Product Studio; for a rendered logo video without an editable scene, Brand Studio already covers the task. ## Check access and inspect the project 1. Inspect available integrations for actual Blender operations. Do not assume a Blender MCP server, extension, or add-on is installed because this skill is present. 2. Otherwise use an available local Blender executable with Python scripting, or desktop controls. Follow the host's access and execution permissions. Check the installed version. 3. Inspect the existing file, active scene, object names, collections, materials, cameras, render engine, frame range, frame rate and output dimensions before editing. 4. If Blender access is unavailable, state that limitation. Offer a scene-building script or asset handoff, clearly marked unexecuted. Do not claim a `.blend` exists or spend generation credits on an alternative deliverable without the user's agreement. ## Establish the deliverable Use the user's existing scene and settings for edits. For a new scene, establish subject, scale, still versus animation, output dimensions and duration. Choose reasonable defaults for unspecified visual details and state them. Ask about real-world dimensions when they affect the task; do not infer accurate product geometry from a single photo. Separate the editable project from any interchange export. If GLB, FBX or another format is requested, inspect the installed exporter's support and verify that output separately; modifiers, procedural materials and rigs may need format-specific preparation. ## Generate only missing assets - Use existing user assets first. A change to camera, material color, text or keyframe timing normally needs no new ImagineArt call. - Use `generate_image` for reference boards, background plates or texture artwork. Consult the current tool schema for valid model, resolution and aspect-ratio values. - Use `request_image_upload` when ImagineArt needs a user-supplied image and the host requires its upload widget. Local Blender-only edits do not require uploading the scene. - Resolve the ImagineArt organization as directed by the tool; use returned IDs rather than inventing them. For pending generations, follow the widget's polling flow or the current `fetch_status` tool contract on a host without widgets. - Download completed outputs through available authorized file tools to stable project paths before using them in Blender. Never treat a remote URL as an imported local image. - Request flat, evenly lit texture artwork where appropriate. Check tiling seams; a prompt asking for seamless output is not proof that it tiles. Do not represent an ordinary RGB image as a calibrated normal, roughness, displacement map, or HDR lighting environment. ## Build or edit 1. Save a working copy when modifying an existing project. Keep the source recoverable. 2. Build named objects in a task collection; retain editable text, modifiers and material nodes unless the requested output requires conversion. Never clear the whole scene as a routine setup step in an existing project. 3. Assign materials and image textures deliberately. Check UV placement, texture scale, image color-space role and missing-file indicators. 4. Place a camera, set its framing and focus, and light the subject. Use real lights or an appropriate environment for illumination; a generated background plate need not light the scene accurately. 5. For animation, keyframe only the requested objects or camera. Preserve existing actions. For a turntable, keep lighting stable unless the brief calls for moving lights, and check the loop boundary for a duplicate hold frame or a jump. 6. Render a small preview and inspect it before committing to the full render. Check framing, clipping, materials, readable text, shadows and animation at representative frames. 7. Save the `.blend`, bundle required resources, render/export, and reopen the saved project to verify the requested result. A successful script exit or a queued render is insufficient. ## Follow-up edits Locate the existing object, material or action by name. Change only the requested property. For "make the bottle blue," edit that material; preserve geometry, camera, lighting, animation and other materials. Check whether the material is shared before altering it. Do not rebuild the scene to make a local edit. ## Failure handling Distinguish unsupported capabilities, missing files, render failures and ImagineArt refusals. Stop on safety/content refusals; never switch models to bypass them. If the reason is unclear, stop and clarify. Disclose model or output-setting changes used for a confirmed capability limitation. Retry technical failures at most twice; do not duplicate pending generation jobs or restart a full animation render blindly. ## Delivery Provide paths to the `.blend`, bundled resources and final outputs. State what was actually reopened, rendered and inspected, plus any missing dependencies or unverified outputs. Never describe a script, viewport screenshot or reference image as a completed 3D project.
Referenced files: 5
brand4.06 KB
--- name: brand description: Logos, animated logo reveals, and full visual identity — palette, typography pairing, and brand applications. Use when the user is establishing or refreshing a brand, or wants a logo. Not for a single social graphic (use Social Studio). --- # Brand Studio Read `references/identity.md` for the identity method. > **Partly implemented.** `generate_logo` and `generate_3d_logo_animation` are real tools. > Palette generation, typography pairing and brandbook export are **not built server-side**. > Produce those as structured text plus generated sample imagery, and say plainly which > parts aren't exportable as files yet. Never imply a downloadable brandbook exists. ## Tokens | Token | What it does | |---|---| | `/logo` | Static mark — three directions | | `/logo-reveal` `/logo-3d` | Cinematic 3D animated reveal | | `/palette` | Colour system with roles | | `/typography` | Display + body pairing | | `/brandbook` | The full identity, assembled | ## Truth gate — claims - **The claims the user supplies are the complete allowlist.** Preserve each as written. Never strengthen, combine, or infer a new claim from them. - **With no claims supplied**, write only about what is directly observable — materials, controls, how it is used, what is included. - **No superlatives you cannot support** — "best", "revolutionary", "#1". They read as advertising and fail on review. - **No comparison to a named competitor.** ## Logos `generate_logo`. Ask for exactly three things: the **name**, what the **business does**, and any **style direction**. If they gave the first two, infer the third and say what you assumed. Don't run a questionnaire. **Generate three distinct directions, not one.** Logo choice is comparative — name what distinguishes each in a line. ## Logo reveals `generate_3d_logo_animation` takes `logo_image_url` and runs the whole recipe in one call: it converts the flat 2D logo to 3D (nano-banana-2), waits, then animates the reveal (veo-3.1-fast). **It blocks for up to a minute before returning.** Say so before calling it, or the wait reads as a hang. ### When the reveal fails — observed recovery `generate_3d_logo_animation` is a two-stage pipeline: 3D still first, then animation. **Stage two can fail after stage one succeeded.** Observed in testing, along with what actually worked: | Attempt | Result | |---|---| | Full pipeline | 3D still succeeded, animation failed | | Retrying the full pipeline | Timed out | | Animating the **original** logo directly with `ltx-2.3` | Completed | So the recovery, in order: 1. **Do not blindly re-run the whole tool.** Stage one already cost time and credits, and re-running it is what caused the timeout. 2. **Retry the full pipeline at most once.** If it fails again, stop retrying it. 3. **Fall back to direct animation:** `generate_video` with the logo as `image_url` (exactly one URL), `ltx-2.3`, duration `6`, resolution `1080p`. This produced a usable reveal when the dedicated tool could not. 4. **Say what you did** — the fallback is a different look from the 3D pipeline, and that is a material change the user needs to know about. If the intermediate 3D still is recoverable from the assets list, animate *that* rather than the flat original — it is closer to the intended result. ## Identity Method in `references/identity.md`. The rule that matters: **Every asset generated after the palette is set must use it.** A brand kit whose own sample images ignore its palette is worthless. Carry the hex values into every subsequent prompt, explicitly. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
canva5.41 KB
--- name: canva description: Generate artwork with ImagineArt and build it into an editable Canva design — add real text layers, a logo and a CTA, then resize for each destination and export. Use when the user wants a finished, editable design rather than a flat generated image. Requires browser access to Canva. --- # Canva Finishing The deliverable is an **editable Canva design**, not a picture. If the result is a flat image with text burned in, this skill failed — that is what Social Studio already does. Read `references/canva-ui.md` for the interface playbook and `references/models.md` before generating anything. ## Tokens | Token | What it does | |---|---| | `/canva` | Generate artwork, build a design, add editable text | | `/resize` | Adapt an existing design to another size | | `/headline` | Change only the text on an existing design | | `/export-design` | Render and download the current Canva design | ## Step 0 — check what you actually have Before promising anything, establish three things: 1. **Is the official `@Canva` connector available?** If it is, **prefer it** for anything it exposes — creating, editing, resizing, Brand Kit. It is faster and more reliable than driving the UI. 2. **Is computer use available?** It needs the ChatGPT desktop app, macOS or Windows, a Work or Codex plan, and granted permissions. You cannot switch it on yourself. 3. **Is the user signed in to Canva?** Never attempt to authenticate on their behalf. If none of the above is available, say so in one line, generate the assets anyway, and hand them off with the sizes and text spelled out. **Never imply a Canva design was created when it wasn't.** ## Before anything else — is this an edit or a build? **Inspect first. Generate only what the requested change actually needs.** "Change the headline", "trim this clip", "export this", "move that" are **edits**. They must not generate new artwork, footage or music. Open what exists, find the specific element, and change it. Only generate when something genuinely required is missing. A six-second clip asked to be five seconds gets **trimmed**, not regenerated. ## The preservation rule One rule, applied consistently: > **Preserve unrelated work. Modify exactly the element the user asked about. Verify the > change landed and that nothing else moved.** This is not "never replace anything" — the user may well want an element replaced. It means never touch what they didn't ask about. And note that *adding* is not automatically safe: a layer placed on top can hide what's beneath it, and a clip on a new track can duplicate audio. Check what your addition covers. ## The workflow 1. **Establish the brief.** What it advertises, the headline, the CTA, and the destinations (feed, story, both). Ask once, together. 2. **Generate the artwork — with room for text.** This is the step that decides whether the design works. Prompt for deliberate negative space where the headline and CTA will sit; do not let the model render any text. See `references/canva-ui.md`. 3. **Import.** Upload the generated asset through Canva's Uploads panel, then place it on the page as a **new element**. Never replace an existing frame in a Brand Kit template. 4. **Add text as real Canva text elements.** Headline, CTA, logo — each its own editable element. This is the entire point of the skill. 5. **Verify after every meaningful change.** Screenshot and read what is actually on the canvas. Do not assume a click landed. 6. **Resize per destination**, then export. Confirm the export finished before reporting. 7. **Report what you verified and what you didn't**, explicitly. ## Hard rules - **Never use fixed screen coordinates.** Find elements by what they look like, every time. Canva's layout shifts by window size, account and release. - **Never bake text into the generated image.** Diffusion models cannot render reliable letterforms, and baked text isn't editable — failing the whole purpose. - **If a step fails twice, stop.** Describe what you see rather than clicking blindly. - **Never claim an export exists without confirming it.** ## Done means reopened, not saved "The export downloaded" is too weak. Before reporting success, confirm: - The **saved design** contains the headline, CTA and logo as **separate selectable elements** — not flattened into the artwork. - The exported file exists **and** is the size that was asked for. - Every pre-existing element is still present. State explicitly what you verified and what you could not. ## The follow-up edit test "Change only the headline" is the request that proves this skill works. It must change the headline text and **nothing else** — not the image, not the CTA, not the layout, not the other sizes. Locate the existing text element, edit it in place, and verify by screenshot that everything else is untouched. If you cannot locate the element, say so. Do not rebuild the design. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
effects5.8 KB
---
name: effects
description: Turn a single uploaded photo into a short viral video using a named preset look — /effects to browse, or a named token like /zoom-punch or /main-character. Use when someone uploads an image and wants motion, a trending effect, or "make this go viral". Not for text-to-video with no source image (use Studio), and not for fashion looks (use Runway Motion).
---
# Effects
One photo in, one short video out. The user should never have to write a prompt.
## When this fires
- An image is attached and the user asks for motion, an effect, or a trending look
- The user types `/effects` or any named preset token
- "make this move", "make this go viral", "add an effect to this"
**Not this skill:** text-to-video with no source image (Studio), animating a fashion
shot from a shoot (Runway Motion), colour grading a still without motion (Retoucher).
## Workflow
1. **Establish the organization.** Every call needs one. It usually resolves silently —
pass `org_id` when you have it, and when you don't, call the tool anyway and retry with
the id it returns. If the tool responds that no organization could be resolved (a
first-time user with more than one), call `select_organization`, then continue. That is
a normal step, not an error.
2. **Get the source image.** Call `request_image_upload` — this renders the upload widget
and places the resulting URLs into your context automatically. **Attached files are not
handed to this server**, so there is no way to read an attachment directly, and
`user_upload` is internal to that widget. If the user pasted an ImagineArt URL, use it
as-is. No image means no video; ask for one.
3. **Resolve the preset.**
- `/effects` with no name: show a short list of looks from `references/effects.md`,
grouped by feel, and let them pick.
- A named token (`/zoom-punch`): look it up in `references/effects.md`.
- **Unknown token:** do not stop and ask what they meant. Infer the intent from the
token and the conversation, pick sensible defaults, and generate. Never claim a
preset exists that doesn't, and never pass an unknown name as a model id.
4. **Generate.** Call `generate_video` with:
- `prompt` — the preset's prompt, with the user's subject woven in
- `image_url` — an array containing **exactly one** URL (this is what makes it
image-to-video rather than text-to-video)
- `model`, `duration` and `resolution` — from the preset. Use its values unless a
refusal sends you to the preset's `fallback` (see below); that is the one case where
you change them, and you change all three together.
- **Never omit `resolution`.** An omitted resolution renders at the model's *lowest*
tier (`seedance-2.5` defaults to 480p), and low-resolution output is the fastest way
to make this skill look broken. Durations behave the same way: a value outside the
model's list silently falls back.
5. **Finish.** Where a widget renders, it polls on its own — don't call `fetch_status`.
On a text-only host with no widget, poll `fetch_status` with `id=<uuid>` and
`sync: true` until status is `complete` or `error`, then use the returned URL.
6. **Offer one more.** Suggest a second look from the same family. Repeat generation is
the whole point of this skill.
## Model refusals
**Confirmed in testing:** `seedance-2.5` declines sources it reads as containing a real
person — including illustrated and cartoon characters. This is a **model restriction**, not
a safety judgement about the content: other models accept the same image.
So:
1. **If the source shows a person, don't open on `seedance-2.5` at all.** Use the preset's
`fallback` from the start. Person-centric presets already default to `seedance-2.0`.
2. **If a restriction refusal happens anyway**, switch to the preset's `fallback` with that
fallback's stated duration and resolution — and **tell the user which model you used
instead**, in one short line. A different model is a different look; silent substitution
leaves them confused about why two runs differ.
3. **If the refusal is a safety refusal** — the content itself was declined, not the input
class — **do not try other models.** Say what was declined and offer a different subject.
When you can't tell the two apart, treat it as a safety refusal.
4. **Two attempts maximum**, then stop and report.
See `references/errors.md` for the full taxonomy.
## Framing
Ask for `9:16` where the preset specifies it, but know that **`seedance-2.5` image-to-video
adopts the source image's ratio and ignores `aspect_ratio` entirely**. Don't promise
vertical output on that path. If the user needs true vertical, tell them the clip follows
their photo's shape.
## Other defaults
- **Short.** Use the preset's duration; don't lengthen it unprompted.
- **One generation per request.** Never fan out across presets unless asked.
- Video generation requires a paid organization. Relay subscription refusals verbatim —
they carry the upgrade link.
## Conventions
- Never print `org_id`, `folder_id`, or raw asset uuids.
## Where the presets should live
`references/effects.md` is the starter library. The target architecture moves it
server-side behind `get_token_instructions(token)` so new looks ship without a plugin
resubmission. When that endpoint exists, this skill resolves tokens through it and the
reference file is deleted.
## When something fails
Read `references/errors.md`. Identify the kind of failure before responding: pending jobs
are waited on, technical errors retried at most twice, unsupported capabilities stated
plainly, safety refusals never routed around, and every material change disclosed.
## QA before delivery
Run `references/qa.md` before calling this finished. Inspect the actual output — never
claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
fashion3.82 KB
--- name: fashion description: Fashion photoshoots and fashion motion — lookbooks, editorials, catalogue shoots, runway clips, and animating a look. Use for any request about clothing on models, collections, or campaign imagery. Not for putting a customer's own garment photo onto a person (use Try-On) and not for generic photo effects (use Effects). --- # Fashion Stills and motion, one pipeline. Read `references/flow.md` for the picker sequence and `references/models.md` before any video call. ## Tokens | Token | What it does | |---|---| | `/lookbook`, `/editorial` | Styled, atmospheric campaign stills — `shoot_type: editorial` | | `/catalogue` | Clean, consistent e-commerce stills — `shoot_type: catalogue` | | `/runway`, `/animate` | Motion from an existing shoot | | `/model`, `/wardrobe`, `/pose` | Jump to one picker on an existing project | ## The one rule that breaks this skill **Advance exactly one `select_*` call per turn and wait for the answer.** Each picker renders UI and the user's choice comes back as the next message. Chaining two pickers in a turn is the most common failure here — it produces a dead widget and a stalled flow. ## Truth and safety gate — clear this before generating If any item fails, do not generate and do not route around it. - **Subject authorization.** Use a generated adult, or a real person the user is authorized to depict. A supplied photo is not permission to impersonate its subject. Decline public figures, minors, and deceptive identity use. If third-party consent is unclear, ask once. - **No synthetic testimonials.** A generated person is a model or demonstrator, never a real customer. Do not invent ownership, results, or lived experience. - **Transparent framing.** Output is a brand concept or demo, not organic customer content. ## Decide the shoot type first, without asking `shoot_type` is `catalogue` or `editorial` and carries through every later step. - "lookbook", "campaign", "editorial", "moody" → **editorial** - "catalogue", "product pages", "e-commerce", "consistent" → **catalogue** Infer it, state which you picked in one short line, and move on. Don't open with a question — the pickers already ask plenty. ## Stills Follow the sequence in `references/flow.md`. The pickers collect their own photos, URLs and descriptions and call the underlying upload and create tools themselves — never call `request_image_upload` or `create_fashion_model` to feed a picker. ## Motion Three paths, cheapest first: | Request | Tool | |---|---| | One still, simple movement | `animate_fashion_image` | | A named template or a specific runway style | `list_fashion_video_templates`, then generate | | A whole look or collection in motion | `fashion_video_shoot` | Take the cheapest path that answers the request, then offer the richer one. **Fashion motion is people.** Never open on `seedance-2.5` — it refuses human subjects, including illustrated ones. Default to `seedance-2.0` at 1080p; fall back to `ltx-2.3` at 6s/1080p. See `references/models.md`. ## Second shoots Once a project exists, do not rewalk the flow. Ask which single thing changes — pose, background, wardrobe — re-run that one picker, and generate. This is the most common real request and it should feel short. ## Conventions Ids returned by pickers are internal. Never print `org_id`, `folder_id`, `fashion_project_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
interior2.04 KB
--- name: interior description: Interior redesigns and virtual staging — re-decorate a room from a photo, stage an empty space, or restyle it. Use when the subject is a room or property interior. Not for architectural exteriors and not for product placement (use Product Studio). --- # Spaces ## Tokens `/interior` `/redesign` `/restyle` — redesign an existing room `/staging` `/stage` — furnish an empty space for sale or rent ## Workflow 1. `request_image_upload` for the room photo — this skill works from a real space. 2. `generate_interior_design`. ## The rule that makes results usable **Keep the architecture.** Walls, windows, doors, ceiling height and proportions are **fixed**. Change furniture, finishes, colour, textiles and styling. A redesign that moves a window is not usable by an agent, a homeowner or a contractor — it is a picture of a different house. If the user explicitly asks for a structural change, produce it but say once that the result is illustrative rather than a buildable plan. ## For staging Empty rooms need furniture at believable scale. A sofa that doesn't fit the wall it's against reads as fake immediately and undermines the listing. ## Defaults `16:9` — rooms read wide. Magazine-quality and photoreal regardless of the input photo's quality; a phone snapshot should still produce a polished result. ## Finishing a generation Where a widget renders, it polls itself. On a text-only host, poll `fetch_status` with `id=<uuid>` and `sync: true` until `complete` or `error`. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 6
motion3.2 KB
--- name: motion description: Camera-driven and cinematic video — dolly, orbit, crane, FPV, drone and aerial shots, plus food and recipe video. Use when the user describes how the camera moves or wants a cinematic clip of a subject. Not for preset viral looks on an uploaded photo (use Effects) and not for fashion motion (use Fashion). --- # Motion Read `references/recipes.md` for the move library and `references/models.md` before any call — model choice here is a quality choice. ## Tokens | Token | What it does | |---|---| | `/dolly` `/crane` `/push` `/track` | Camera moves | | `/fpv` `/drone` `/aerial` | Drone and FPV footage | | `/recipe` `/cooking` `/food` | Food and recipe video | | `/cinematic` | General cinematic treatment | ## Overlap with Effects **`/orbit` belongs to Effects**, which owns preset looks applied to an uploaded photo. Use Motion when the user describes a camera move for a scene being generated, or supplies a still to move *through* rather than a subject to orbit. When both could apply and the user uploaded a photo, Effects wins. ## Resolving the move `list_camera_movements` and `list_camera_angles` hold the valid values. **Never invent one** — match the user's words to a real entry. **Do not use `list_durations` or `list_resolutions` here** — those describe ad generation. Video durations and resolutions are per-model allow-lists in `references/models.md`. | Request | Tool | |---|---| | Aerial / drone footage | `generate_drone_video` | | Food and recipe | `generate_cooking_video` | | Everything else | `generate_video` with the movement written into the prompt | If the user supplied a still to move through, pass it as `image_url` with **exactly one** URL — that switches the call to image-to-video. ## Model choice is the quality decision Camera control and resolution ceiling vary sharply. From `references/models.md`: - **Controlled, specific moves** → `seedance-2.5` has the strongest adherence, but caps at **720p** and **refuses people**. - **Quality first** → `ltx-2.3` at 1080p+ (durations 6/8/10 only) or `seedance-2.0` at 1080p. - **People in frame** → never `seedance-2.5`. Open on `seedance-2.0` at 1080p. Say which model you picked in one line so the user can ask for something else. **Never omit `resolution`** — it defaults to the model's lowest tier. ## Food `generate_cooking_video`. This category reads through **steam, texture and motion** — a pour, a cut, rising steam. Warm directional light; flat light makes food look dead. Don't inflate portions beyond what the recipe produces. ## Defaults `16:9` — these are cinematic shots, not feed content, unless the user says otherwise. `9:16` for food headed to social. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
music1.66 KB
--- name: music description: Music, jingles and soundtracks. Use when the user wants audio generated — a track, a background bed, a jingle for an ad. Not for adding captions or subtitles to a video (use Social Studio). --- # Sound ## Tokens `/music` `/soundtrack` `/jingle` `/bed` ## Workflow `generate_music`. The audio widget polls itself — don't call `fetch_music_status`. On a text-only host, poll it with `sync: true` until `complete` or `error`. ## Ask for the three things that matter **Genre, mood, and length.** Length matters most — a bed for a 15-second ad and a track for a three-minute video are different requests. If they're scoring something they already generated, **match its duration** rather than asking. Look it up rather than making them tell you. ## Useful defaults - Scoring an ad → instrumental, no vocals, a clear build in the last third - Background bed → low-dynamic, nothing that competes with a voiceover - Jingle → short, hook-forward, memorable in under 10 seconds ## Paywall Music generation requires a paid organization. Relay subscription refusals verbatim — they carry the upgrade link. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 6
photoshop4.43 KB
--- name: photoshop description: Generate or retouch assets with ImagineArt and build them into a layered Photoshop document — separate layers, masks, and editable type. Use when the user wants a working PSD rather than a flat image. Requires desktop access to Photoshop. --- # Photoshop Finishing The deliverable is a **layered, reopenable PSD**. A flattened JPEG is a failure — Social Studio and Product Studio already make flat images. Read `references/photoshop-ui.md` before touching the app and `references/models.md` before generating. ## Tokens `/photoshop` `/psd` `/layers` `/composite` `/mask` `/retype` ## Step 0 — check what you have 1. **Is the official `@Adobe` connector available?** If it covers the task, **prefer it** — it runs server-side with no desktop dependency. Driving the UI is the fallback. 2. **Is computer use available**, with Photoshop actually open or installed? You cannot switch computer use on yourself. 3. **Is there an open document**, and does the user want to work in it or start fresh? If none of this is available, generate the assets, state the layer structure you'd have built, and hand off. **Never imply a PSD was created when it wasn't.** ## Before anything else — is this an edit or a build? **Inspect first. Generate only what the requested change actually needs.** "Change the headline", "trim this clip", "export this", "move that" are **edits**. They must not generate new artwork, footage or music. Open what exists, find the specific element, and change it. Only generate when something genuinely required is missing. A six-second clip asked to be five seconds gets **trimmed**, not regenerated. ## The preservation rule One rule, applied consistently: > **Preserve unrelated work. Modify exactly the element the user asked about. Verify the > change landed and that nothing else moved.** This is not "never replace anything" — the user may well want an element replaced. It means never touch what they didn't ask about. And note that *adding* is not automatically safe: a layer placed on top can hide what's beneath it, and a clip on a new track can duplicate audio. Check what your addition covers. ## The workflow 1. **Establish the composition.** What is the background, what is the subject, what type goes on it, and what is the final output size. 2. **Generate only what's missing** with ImagineArt. Use `remove_background` for a subject that needs to sit on its own layer. 3. **Place each asset on its own named layer** — File > Place Embedded, never Place Linked, so the document travels. 4. **Mask rather than erase.** A layer mask is reversible; erased pixels are not. 5. **Add type as real editable type layers.** Never rasterize, never use generated text. 6. **Verify by screenshot after each meaningful change** — read the Layers panel, don't assume the click landed. 7. **Save the PSD, then export** the flat file separately. 8. **Report what you verified** and what you couldn't. ## Hard rules - **Never flatten**, and never Save over the user's original — Save As a new file. - **Never use fixed screen coordinates.** Find panels and controls by what they look like. - **Never bake text into a generated image.** Diffusion can't render reliable letterforms, and baked text isn't editable. - **Name every layer.** An unnamed stack of "Layer 1, Layer 2" is not a deliverable. - **If a step fails twice, stop** and describe what you see. ## Done means reopened, not saved "The file exists" is too weak. Before reporting success, confirm: - The **PSD reopens**. - **Type layers are still editable type**, not rasterized. - **Masks are intact** and nothing was erased destructively. - Placed assets are still Smart Objects. - The user's original file is untouched. State explicitly what you verified and what you could not. ## The follow-up edit test "Change only the headline" must edit the type layer and leave the image, the masks and every other layer untouched. Find the existing type layer; don't rebuild the document. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
premiere5.14 KB
--- name: premiere description: Generate clips and music with ImagineArt and assemble them into a Premiere Pro sequence — import, lay out the timeline, trim, title, mix audio and export. Use when the user wants a cut sequence and a saved project rather than isolated clips. Requires desktop access to Premiere Pro. --- # Premiere Finishing Requires access to Premiere Pro through an available integration or desktop controls. Check those capabilities before promising a project; verify save, reopen and export before reporting completion. The deliverable is a **saved project plus a verified export**. Loose clips in a folder are what Motion already produces. Read `references/premiere-ui.md` before touching the app and `references/models.md` before generating — durations and resolutions are per-model and matter more here than anywhere else, because mismatched footage breaks a sequence. ## Tokens `/premiere` `/assemble` `/timeline` `/cut` `/titles` `/mix` `/export` ## Step 0 — check what you have 1. **Is an integration available that explicitly supports Premiere Pro?** Inspect its exposed tools before using it; an Adobe integration may cover a different application. 2. **Is computer use available**, with Premiere open or installed? 3. **Is there an open project and sequence**, or does one need creating? If app access is unavailable, state that limitation. Offer a clip-and-edit-plan handoff; generate assets only if the user wants that fallback. **Never imply a project was created when it wasn't.** ## Before anything else — is this an edit or a build? **Inspect first. Generate only what the requested change actually needs.** "Change the headline", "trim this clip", "export this", "move that" are **edits**. They must not generate new artwork, footage or music. Open what exists, find the specific element, and change it. Only generate when something genuinely required is missing. A six-second clip asked to be five seconds gets **trimmed**, not regenerated. ## The preservation rule One rule, applied consistently: > **Preserve unrelated work. Modify exactly the element the user asked about. Verify the > change landed and that nothing else moved.** This is not "never replace anything" — the user may well want an element replaced. It means never touch what they didn't ask about. And note that *adding* is not automatically safe: a layer placed on top can hide what's beneath it, and a clip on a new track can duplicate audio. Check what your addition covers. ## Plan the cut before generating anything This is where this skill is won or lost. Decide first: - **Total duration** and how it divides across shots - **Aspect ratio and resolution** — every clip must match, or the sequence letterboxes - **Shot list** — what each clip shows and how long it holds Then generate to that plan. Generating first and cutting later wastes credits on clips that don't fit. Choose source aspect ratios and resolutions for the target sequence. Generate a supported duration long enough for each shot, then trim locally. For example, a six-second source can supply a five-second shot without regeneration. See `references/models.md`. ## The workflow 1. **Plan** the cut as above. 2. **Generate only missing assets** with `generate_video` or `generate_music`, to plan. 3. **Import** into the Project panel, then drag to the timeline. 4. **Place clips at the planned times and tracks.** For an existing edit, change only the requested clips and check overlays and linked audio; a higher track can hide prior work. 5. **Trim** to the planned durations. 6. **Titles** — text layers in **Properties** (Premiere 25.0+) or **Essential Graphics** (earlier). **Captions** are a choice: editable Premiere captions, or burned-in via `generate_video_captions`. Say which one you're delivering. 7. **Mix** — duck the music under any voice; don't leave it at full level. 8. **Save the project, then export**, and confirm the file exists. 9. **Report** what you verified and what you couldn't. ## Hard rules - **Never use fixed screen coordinates.** - **Never report an export you didn't confirm.** Exports queue and fail silently. - **Sequence settings must match the footage** — check before laying anything down. - **If a step fails twice, stop** and describe what you see. ## Done means reopened, not queued "The export started" is the most common false success in this skill. Before reporting: - The **project reopens with media online** — no red offline clips. - The export file exists **and** its dimensions and duration match the sequence. - The exported video actually **has picture and audio**, not black or silence. - No pre-existing clip was hidden, replaced, or duplicated in audio. State explicitly what you verified and what you could not. ## The follow-up edit test "Change only the second clip" must replace that one clip and leave the rest of the timeline, the titles and the audio mix untouched. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed.
Referenced files: 6
product4.41 KB
--- name: product description: Product imagery without a presenter — clean cutouts, white-background shots, lifestyle scenes, oversized hero showcases, jewelry video, and full marketplace listing sets for Amazon or Shopify. Use for any still or video of a physical product on its own. Not for a person presenting it (use UGC Ads) and not for retouching an existing photo (use Retoucher). --- # Product Studio Read `references/recipes.md` for the prompt library and `references/models.md` before any video call. ## Tokens | Token | What it does | |---|---| | `/product-shot` | A generated scene around the product | | `/white-bg` | Product cut out and placed on white | | `/lifestyle` | Product in a real-world scene | | `/giant` | Oversized, monumental hero | | `/jewelry` `/watch` | Macro jewelry video | | `/amazon-main` `/a-plus` `/listing` | Marketplace listing set | ## Truth gate — claims - **The claims the user supplies are the complete allowlist.** Preserve each as written. Never strengthen, combine, or infer a new claim from them. - **With no claims supplied**, write only about what is directly observable — materials, controls, how it is used, what is included. - **No superlatives you cannot support** — "best", "revolutionary", "#1". They read as advertising and fail on review. - **No comparison to a named competitor.** ## Getting the source `request_image_upload` renders the upload widget and places URLs into context. Attached files are never handed to this server — never call `user_upload` directly. ## Stills | Request | Tool | |---|---| | Transparent cutout | `remove_background` | | **White-background main image** | `remove_background`, **then** `generate_image` with that cutout as `image_url` and an explicit pure-white prompt — see `references/recipes.md`. `remove_background` alone returns **transparency, not white**. | | One product into a described scene | `generate_image` with the product as `image_url` (image-to-image) | | **Two or more** images reconciled into one frame | `composite_shoot` — `image_urls` requires **2+**, and a paid organization. Never for a single product. | | Oversized hero | `generate_giant_product_showcase` | ## Jewelry `generate_jewelry_video`. This category lives on **macro detail and controlled reflection** — metal and stone read by how light moves across them, so motion matters more than composition. Close beats wide. Gold tone, metal type and stone colour must match the real piece; buyers return items that don't match the video. ## Marketplace listings A listing is a **set**, not one image. Produce the whole set without checking in between. 1. **Main image** — product on pure white, filling most of the frame, **no props, no text, no badges**. Two steps: `remove_background` for the cutout, then `generate_image` with that cutout as `image_url` and the white-background prompt from `references/recipes.md`. The cutout alone is transparent, which is not a compliant main image. 2. **Secondaries** — 3–5 shots: angles, scale, detail, in-use. `generate_image` with the product as `image_url`. Use `composite_shoot` only when genuinely merging 2+ images. 3. **A+ modules** — `generate_carousel` for multi-panel story blocks. Ask which marketplace only if unstated; main-image rules differ. If the user wants text on the main image, say it risks rejection and put it on a secondary instead. **Carousels bill per requested slide up front and a partial failure is not refunded.** If fewer slides come back than asked, say so plainly rather than presenting a short deck. ## The rule that matters most **Never alter the product.** Colour, shape, finish and included accessories must match what actually ships. Restyle the scene, never the product. A shot that flatters but misrepresents gets sellers suspended — it is a failure, not a success. ## Defaults `1:1` for catalogue and marketplace, `4:5` for social, `16:9` for banners. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
retouch2.62 KB
--- name: retouch description: Change an image that already exists — edit, enhance, upscale, cut out the background, or apply film grain and colour grading. Use when there is already an image and the user wants it altered. Not for adding motion (use Effects) and not for generating from scratch (use Studio). --- # Retoucher The signal: **there is already an image**, and the user wants it changed. ## Tokens | Token | Tool | |---|---| | `/cutout` `/remove-bg` | `remove_background` | | `/enhance` `/upscale` | `enhance_image` | | `/retouch` `/edit` | `edit_photo` | | `/grain` `/grade` | `list_image_effects` → `apply_image_effect` | `request_image_upload` for attachments — it renders the widget and places URLs into context. Never call `user_upload` directly. ## Image effects are a finishing pass `list_image_effects` returns **grain / film-stock and colour-grade presets**. They re-render the image while preserving subject, wardrobe, pose, framing and background — they do not add motion and do not change content. Narrow the catalogue with `kind`: `grain` or `colorGrade`. Omit for both. `apply_image_effect` takes `effect_id` and `asset_id` and runs a two-step workflow — analyse the source with the preset, then image-to-image re-render. **It requires a paid organization.** It also recovers the source's framing, resolution and (for fashion assets) project and composition, and preserves them. ## The rule that matters **Do only what was asked.** If the user says "remove the background", don't also brighten, sharpen and recompose. Unrequested changes read as the tool malfunctioning, not as extra value. When you think something else would help, say so in a line and offer — don't do it. ## Finishing a generation Where a widget renders, it polls itself — don't call `fetch_status`. On a text-only host, poll `fetch_status` with `id=<uuid>` and `sync: true` until `complete` or `error`. ## Conventions Never print `org_id`, `folder_id`, or raw asset uuids. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## Inspect before generating A request to change something that already exists is an **edit**, not a build. Find the existing asset and modify it. Generate only what the requested change actually requires. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 6
social4.76 KB
---
name: social
description: Content for feeds and channels — Instagram posts, multi-slide carousels, stories, YouTube thumbnails, video covers, and burned-in captions or subtitles. Use when the destination is a social platform or a video needs captions. Not for marketplace listing images (use Product Studio).
---
# Social Studio
Read `references/recipes.md` for the prompt library and destination sizing.
## Tokens
| Token | What it does |
|---|---|
| `/instagram` `/post` | Single feed post |
| `/carousel` | Multi-slide deck |
| `/story` | Vertical story graphic |
| `/thumbnail` `/cover` | YouTube thumbnail (16:9 only) |
| `/captions` `/subtitles` | Burn captions into an existing video |
## Truth gate — claims
- **The claims the user supplies are the complete allowlist.** Preserve each as written.
Never strengthen, combine, or infer a new claim from them.
- **With no claims supplied**, write only about what is directly observable — materials,
controls, how it is used, what is included.
- **No superlatives you cannot support** — "best", "revolutionary", "#1". They read as
advertising and fail on review.
- **No comparison to a named competitor.**
## Posts and carousels
- Single post → `generate_instagram_post`
- Multi-slide → `generate_carousel`. The `prompt` is the **topic**, not a per-slide prompt
— upstream plans each slide with an LLM. Pass `slides` for the count.
- A carousel about a specific product → pass `product_id`; it resolves the product photo
itself. Don't hunt for a URL.
**Carousels bill per requested slide up front, and a partial failure is not refunded.** If
fewer slides come back than requested, say so plainly.
## Thumbnails
`generate_youtube_thumbnail` takes `title`, plus optional `channel_style` and
`subject_description`. **Know its real shape before promising anything:**
- **It is 16:9 only.** There is no aspect-ratio argument. **It cannot produce a vertical
Shorts cover.** If the user asks for one, say so and offer a 16:9 thumbnail or a
`generate_image` route at `9:16`.
- **It takes no reference image.** You cannot feed it the user's face. `subject_description`
is *text*. If the user needs their own face preserved, this tool is the wrong route —
use `generate_image` with their photo as `image_url`.
- **It deliberately renders no text**, because image models render letterforms poorly. It
returns a striking image *plus text-overlay guidance*: 2–3 overlay options of 3–5 bold
words, where to place them, and font suggestions.
**So a thumbnail from this tool is not finished.** Deliver the image and the overlay
guidance together, and say plainly that the text still needs adding. For a finished
thumbnail with exact text, hand off to the **Canva** skill, which adds it as editable
elements — that is the completion path this tool was designed for.
What makes a thumbnail work, for the prompt you write:
- **Readable at 120px wide.** Big subject, few elements, hard contrast.
- **Faces beat objects**, and a clear expression beats a neutral one.
- Keep suggested overlay copy to 3–4 words.
## Captions
1. **Identify the video.** `asset_id` must be a finished video **this server hosts** — from
`list_assets`, or the last path segment of an `asset.imagine.art/processed/<uuid>` URL
already in the conversation. **A link from anywhere else cannot be captioned.** Say so
plainly rather than trying.
2. **Style.** Named one ("whisper captions") → straight to `generate_video_captions`.
Named none → `select_caption_preset`, which also collects language, position and shadow.
3. Pass `preset` **verbatim** — the upstream match is exact, so recapitalising fails.
**Cost, said while they choose, not after:** animated ("dynamic") presets cost twice static
ones; cost scales per started minute and doubles again for 2K/4K sources.
Use region-qualified locales — `en-US`, not `en`. `translation_language` adds a surcharge.
## Defaults
`4:5` feed, `9:16` stories, `1:1` if they say square. Thumbnails are `16:9` only —
the tool has no other option.
5 slides for a carousel.
## Conventions
Never print `org_id`, `folder_id`, or raw asset uuids.
## When something fails
Read `references/errors.md`. Identify the kind of failure before responding: pending jobs
are waited on, technical errors retried at most twice, unsupported capabilities stated
plainly, safety refusals never routed around, and every material change disclosed.
## Inspect before generating
A request to change something that already exists is an **edit**, not a build. Find the
existing asset and modify it. Generate only what the requested change actually requires.
## QA before delivery
Run `references/qa.md` before calling this finished. Inspect the actual output — never
claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 7
studio3.73 KB
--- name: studio description: Direct image, video and music generation, plus your asset library and credit balance, for requests no other ImagineArt skill covers. Use only as a last resort — fashion, products, ads, effects, social, motion, retouching, branding and interiors all have dedicated skills that handle those requests better. --- # Studio **This is the fallback.** It does not participate in automatic routing (`allow_implicit_invocation: false`). Before using it, check whether a specific skill owns the request — it almost always does. | If the request is about | Use instead | |---|---| | A photo that should move | Effects | | Clothing, models, lookbooks, runway | Fashion | | A customer's own garment on a person | Try-On | | A product with a presenter | UGC Ads | | Product stills, listings, jewelry | Product Studio | | Instagram, carousels, thumbnails, captions | Social Studio | | Camera moves, drone, food video | Motion | | Editing an existing image | Retoucher | | Logos and identity | Brand Studio | | Rooms and staging | Spaces | | Music | Sound | | Editable After Effects compositions or motion titles | After Effects | | Premiere Pro timelines and exports | Premiere | | Editable Blender scenes, materials, lighting or 3D animation | Blender | ## Tokens | Token | What it does | |---|---| | `/assets` `/creations` | Browse past work | | `/credits` `/balance` | Credit balance | | *(none)* | Raw generation | ## Generation - `generate_image` — text-to-image, or image-to-image when `image_url` is set - `generate_video` — text-to-video, or image-to-video when `image_url` holds exactly one URL - `generate_music` — audio **Never guess a valid value** — but use the right source. - **`generate_video` / `generate_image` durations and resolutions are per-model allow-lists**, documented on the tool itself and summarised in `references/models.md`. - **`list_durations` and `list_resolutions` describe ad generation only.** They are inputs for `generate_ad`, not universal validators — do not use them to check a video model. - `list_aspect_ratios`, `list_camera_angles`, `list_camera_movements` are general. Model names must be passed exactly as written; a near-miss fails. **Never omit `resolution`** — it defaults to the model's lowest tier. ## Library | Request | Tool | |---|---| | Visual grid | `show_assets` with `org_id` | | Rows to reason over | `list_assets` | | Past generations | `list_user_creations` | | Credit balance | `get_balance` | `list_assets` takes `service`: `user` for uploads, `image,video` for generations, omitted for everything including music and project assets. When a full page comes back there is a next-page cursor — use it rather than saying that's all there is. **The most common real reason to be here:** another skill needs an `asset_id`. Find it, hand it over, continue. Never make the user copy a uuid. ## Finishing a generation Where a widget renders, it polls itself. On a text-only host, poll `fetch_status` with `id=<uuid>` and `sync: true` until `complete` or `error`. ## Paywall Free organizations can only run `generate_image` on the default model. Relay refusals verbatim; they carry the upgrade link. ## Conventions Never print `org_id`, `folder_id`, or raw uuids — refer to assets by what they are and when they were made. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 6
try-on4.16 KB
--- name: try-on description: Put a real garment from the user's own photo onto a model or person — virtual try-on, outfit swap, UGC try-on video. Use when the user supplies a photo of an actual garment or product they own. Not for generated wardrobe inside a styled shoot (use Fashion Shoot). --- # Try-On Read `references/models.md` before any video call. ## Tokens `/try-on` `/outfit-swap` `/garment` `/wear-this` The distinguishing signal: **the user has a photo of a real garment.** If the garment is being invented rather than supplied, this is Fashion Shoot instead. ## When this fires - "put this jacket on her", "how would this look on a model" - "try-on video", "outfit swap" - A garment photo is attached and a person is mentioned ## Truth and safety gate — clear this before generating If any item fails, do not generate and do not route around it. - **Subject authorization.** Use a generated adult, or a real person the user is authorized to depict. A supplied photo is not permission to impersonate its subject. Decline public figures, minors, and deceptive identity use. If third-party consent is unclear, ask once. - **No synthetic testimonials.** A generated person is a model or demonstrator, never a real customer. Do not invent ownership, results, or lived experience. - **Transparent framing.** Output is a brand concept or demo, not organic customer content. ## Workflow 1. **Upload the garment.** `request_image_upload` to render the upload widget. If the garment is shot on a hanger, flat, or worn by someone else, call `extract_garment` first to isolate it. 2. **Establish the person.** Either a model the user picks, or a photo of a person they supply (collected the same way). 3. **Compose.** `composite_shoot` with `image_urls` = **[garment, person]**. It requires **two or more** images and runs a reference-aware reconciler so the person, the garment and the setting stay consistent. Optional `camera_angle_id` from `list_camera_angles` frames the shot; optional `background_select_id` from `select_fashion_background` sets the scene. For motion, generate the still first, then animate it with `generate_video` (`image_url` = that one asset). 4. Let the widget poll. ## Get this right - **Never invent the garment.** The whole value is that it's *their* product. If the uploaded photo is unusable, say so and ask for a cleaner one rather than generating an approximation. - **Preserve garment detail** — print, logo, texture, colour. If the result drifts from the source garment, regenerate rather than presenting it. - Default to `9:16` for try-on video; it is going to a social feed. - **Try-on is people.** Never open on `seedance-2.5` — it refuses human subjects, including illustrated ones. Use `seedance-2.0` at 1080p, falling back to `ltx-2.3` at 6s/1080p. - **Never omit `resolution`** — it defaults to the model's lowest tier. ## Conventions - `org_id` resolves itself; call the tool and retry with the id it returns if you don't have one. Only call `select_organization` if resolution fails. - Never print ids. ## Model refusals On a safety or content refusal, stop and offer an alternative subject. Do not retry on another model to bypass it. If the refusal reason is unclear, stop and clarify it. Only switch models for a clearly established unsupported input capability, and tell the user which model changed and why, including any duration or resolution change. Summarize the issue plainly instead of exposing the raw upstream error. ## Tool availability `composite_shoot` requires **two or more** `image_urls` and a **paid organization**. There is no single-image try-on path — if you only have the garment, you must also establish the person before compositing. ## When something fails Read `references/errors.md`. Identify the kind of failure before responding: pending jobs are waited on, technical errors retried at most twice, unsupported capabilities stated plainly, safety refusals never routed around, and every material change disclosed. ## QA before delivery Run `references/qa.md` before calling this finished. Inspect the actual output — never claim quality you have not observed, and say plainly what you could not verify.
Referenced files: 6
ugc6.85 KB
--- name: ugc description: Creator-style product video ads — unboxing, review, tutorial, testimonial, demo and hyper-motion — plus reusable on-camera presenters and ad variations for split testing. Use when the user wants an ad with a person presenting their product. Not for garment try-on (use Try-On) and not for product stills with no presenter (use Product Studio). --- # UGC Ads Produce one finished creator-style ad: a presenter, a product, a hook, a setting, and a format — assembled through the server's guided picker flow. Read `references/flow.md` for the exact call sequence, `references/hooks.md` for hook and setting selection, `references/creator.md` for presenter consistency, `references/script.md` for the spoken beats, `references/qa.md` before you deliver, `references/models.md` for model limits, and `references/errors.md` when something fails. ## Runtime contract - **One `select_*` call per turn.** Each picker renders UI and the user's choice returns as the next message. Two pickers in one turn produces a dead widget and a stalled flow. - **The pickers do their own intake.** They collect photos, URLs and descriptions and call the underlying upload and create tools themselves. Never call `request_image_upload`, `create_product` or `create_avatar` to feed a picker. - **`duration` and `resolution` are required on `generate_ad`**, not optional. Resolve them with `list_durations` and `list_resolutions` — those two tools describe **ad generation specifically** and are the correct source here. - **Ids are internal.** Never print `org_id`, `folder_id`, `format_id`, `product_id`, `avatar_id`, job ids, or phase names. - **Never resubmit a pending job.** A queued generation is billed once; resubmitting bills twice for one result. ## Hard rules - **One presenter per ad.** Never regenerate or swap the avatar mid-run. - **Never alter the product.** Colour, shape, finish and included accessories must match what actually ships. - **Never bake text into generation.** Image and video models render letterforms unreliably. Captions come from `generate_video_captions`; overlay copy is added after. - **Say what you changed.** A substituted model, duration or resolution is a material change — one short line, every time. - **Two attempts per stage, maximum.** Then stop and report what you observed. ## Truth and safety gate — clear this before generating If any item fails, do not generate and do not route around it. - **Presenter authorization.** Use a generated adult presenter, or a real person the user is authorized to depict. A supplied photo is not permission to impersonate its subject. Decline public figures, minors, and deceptive identity use. If third-party consent is unclear, ask once. - **Allowed promotion.** Decline political persuasion and promotion of age-restricted or prohibited goods: adult content, gambling, illegal or prescription drugs, tobacco and nicotine, weapons, counterfeits, deceptive financial services, malware, and covert surveillance. - **Truthful claims.** Treat the claims the user supplies as the complete allowlist. Preserve each one as written. Never strengthen, combine, or infer a new claim from them. With no claims supplied, write claim-free copy about what is directly observable — materials, controls, how it is used, what is in the box. - **No synthetic testimonials.** A generated presenter is a host or demonstrator, never a real customer. Do not invent purchase, ownership, results, before/after outcomes, ratings, or lived experience. First-person experience is allowed only when the user supplies the exact script and confirms it is their own. - **Transparent framing.** Describe the output as a brand demo or creator concept, not an organic customer review. If the user asks for a caption or post package, include an ad/sponsorship disclosure. ## Phase 0 — Intake Establish four things in **one** question, not four: 1. **The product** — what it is and what it visibly does 2. **The ad style** — unboxing, review, tutorial, testimonial, demo, hyper-motion 3. **The claims** they are allowed to make, if any 4. **Where it runs** — feed, story, paid placement Do not ask about models, resolutions or hooks. Those are yours to choose and state. ## Phase 1 — Product `select_product`. If the product does not exist yet, the picker creates it — let it. Note what the product photo actually shows; the script cannot describe features that aren't visible. ## Phase 2 — Presenter `select_avatar`. **This is the identity lock.** The same presenter carries the whole ad and every later variation. See `references/creator.md` before choosing — a presenter mismatched to the product category is the most common reason an ad reads as fake. ## Phase 3 — Format If the user named a format, `list_formats` resolves it to a numeric `format_id`. If they named none, `select_format` renders the picker. ## Phase 4 — Hook `select_hook`. The ad style from Phase 0 is **not a separate step** — it shapes this pick and the next one. Carry their words forward rather than asking them to restate the style. `references/hooks.md` maps style to hook. The hook is the whole ad. Most viewers decide in the first 1.5 seconds. ## Phase 5 — Setting `select_setting`. Match the setting to where the product is actually used, not to what looks most expensive. An unboxing in a showroom reads as an ad; an unboxing at a desk reads as a person. ## Phase 6 — Destination `select_folder`, then `select_market_project` (which takes that folder). ## Phase 7 — Generate `generate_ad` with the resolved `product`, `avatar`, `format_id`, hook, setting, project, plus `duration` and `resolution`. Then let the widget poll — don't call `fetch_status`. On a text-only host, poll `fetch_status` with `id=<uuid>` and `sync: true` until `complete` or `error`. ## Phase 8 — QA before delivery Run the checklist in `references/qa.md`. Do not claim the ad is good without checking the actual output. If you could not inspect it, say so. ## Variations — `/variants` Only when an ad already exists. Multiplying is not regenerating. 1. **Hold the product and presenter constant.** They are the control. 2. **Vary one axis** — hooks, or formats, or settings. A test where three things changed teaches nothing. 3. **3–5 by default.** Quote the credit cost before a larger batch. 4. **Label what differs** in each. "Five hooks, same product and setting" is a test. ## Presenters — `/presenter` A presenter is a reusable asset; the same face across every video is the point. | Request | Tool | |---|---| | Create | `create_avatar` | | Render an image | `generate_avatar` | | Choose an existing one | `select_avatar` | | Edit | `update_avatar` | | Remove | `delete_avatar` — destructive, confirm first | Ask three things only: who they are, what they present, the usual setting. `references/creator.md` has the archetypes that work per category.
Referenced files: 10
Package details
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
- Package author
- ImagineArt
Package observed Oct 2, 2026.
Technical details
- First seen
- Sep 30, 2026 · 22:02 UTC
- Last seen
- Oct 2, 2026 · 00:00 UTC
- Collection status
- Collected
plugin_asdk_app_6a97af93ebc88191961039f177688fa9
Download plugin data (JSON)