Abyssale

View saved version →

---
name: "abyssale-design"
description: "Create, reproduce, adapt or fix editable designs in Abyssale through the Abyssale MCP connector — static, animated, print or multipage — from a brief, a brand URL, a reference or an existing design, including AI images and cut-outs. Works in Claude, ChatGPT and Codex. Use whenever the user wants to create or change an Abyssale design, template, banner, ad set or format variations; not for simply finding a design or rendering one unchanged."
---

# Design and produce in Abyssale

Preserve artistic intent and intended use through an **editable, native structure** that survives new copy, new formats and later corrections. No style, industry, number of formats, subject type or advertising composition is prescribed; the product and the channel set the technical limits.

## Scopes

The Abyssale MCP server must be connected with the scopes for the tools you use: `read:design`, `read:project`, `read:font`, `import:design` and `generate:banner`; `read:credits` to report credits; `write:project` to create a project; `write:design` to rename or move a design; `delete:design` to delete drafts. If a call fails with an insufficient-scope error, tell the user to reconnect the connector and grant that scope.

## 0. Identify the runtime first

This skill is shared by several agents. The Abyssale contract is the same for all of them; what differs is how images are produced, how files move and how renders are inspected.

| You are running in… | Read first |
|---|---|
| **Codex** (native ImageGen, local shell and image viewer) | [runtime-codex.md](references/runtime-codex.md) |
| **Claude** with a shell — Cowork, Claude Code, claude.ai with code execution (no native raster generation) | [runtime-claude.md](references/runtime-claude.md) |
| **No shell** — ChatGPT web/app, claude.ai without code execution, other chat clients | [runtime-no-shell.md](references/runtime-no-shell.md) |
| Anything else | Check the tools actually present (shell, web access, image viewing, image generation), then use the closest runtime file |

Rule of thumb: **Codex makes images with ImageGen; Claude makes images with Abyssale's own AI through a scratch design** (text to image, remove background, expand); without a shell, images come from URLs, Abyssale's AI or native illustrations. Steps that need a shell (downloading, scripts, local previews) apply only when one is available — the no-shell file gives the alternative for each. Everything else below is common.

## Read only the relevant references

| Need | Reference |
|---|---|
| Runtime-specific tools, image generation, uploads, render inspection | runtime-codex.md / runtime-claude.md / runtime-no-shell.md |
| Verified native catalog: shapes, patterns, masks, filters, gradients, illustrations, text/button props, image AI, format presets, auto-layout | [Capabilities](references/capabilities.md) |
| Creative direction, fidelity, depth, assets, adaptation by format | [Design and decomposition](references/visual-workflow.md) |
| Layer types, typography, rotation, Button, markup, SVG lettering | [Layers and text](references/native-layers.md) |
| JSON, tools, fonts, uploads, tracking, troubleshooting | [Import and MCP](references/import-and-mcp.md) |
| Rating, Illustration, Video, Audio, animation | [Specialized layers](references/specialized-layers.md) |
| Settings not available through the MCP | [MCP limits](references/mcp-limits.md) |
| Small working payloads | [Examples](references/examples.md) |

Where a behavior isn't proven, the references say so ("check the render", "check after importing"). The import contract is Alpha: read tool schemas before first use, read `version` from `get_design_as_import` instead of assuming one, and re-check what the result depends on.

## 1. Choose the workflow

Identify objective, exact content, references, assets, formats, medium and expected editability. Decide ordinary choices yourself; ask only what materially changes the result. Never invent

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 16 — file references are metadata, not package contents.

View saved version →

---
name: abyssale-import
description: Import a design into Abyssale from a JSON payload in Abyssale's import format (hand-built, adapted from an official example, or round-tripped from an existing Abyssale design), with its images passed as URLs. Use when the user wants to create an Abyssale template/design programmatically instead of building it by hand in the editor, or asks to "import a design into Abyssale", "turn this JSON into an Abyssale template", "duplicate this design into another project", or "recreate this design in Abyssale".
---

# Import a design into Abyssale

Abyssale designs can be created programmatically from a JSON payload — no designer has to build the template by hand. This skill drives that flow end to end, with images passed as URLs.

## Prerequisites

The Abyssale MCP server must be connected and authorized with the `import:design` scope, plus `read:design` (examples and existing designs), `read:project` (to pick the target project) and `read:font` (`list_fonts`) — `write:project` only if you create a new project. Importing requires an Admin, Manager or Designer role; creating a project requires Admin or Manager. If a tool call fails with an insufficient-scope error, tell the user to reconnect the Abyssale MCP client and grant that scope.

## Steps

1. **Build the payload.**
   - **Start from a valid shape — never invent the JSON structure.** If the user already has a payload in Abyssale's import format, use it. A raw export from another tool is not in this format and can't be imported as is. Otherwise call `get_design_import_example` for an official example (`static`, `static-multi-format`, `animated`, `animated-video`, `printer`, `printer-multipage`), or `get_design_as_import` on an existing Abyssale design to get its JSON (round-tripping — e.g. to duplicate a design: change its `name` and target, then import).
   - **Choose where it lands.** Set `target.project_uuid` to one of the user's projects: call `list_projects` and ask which one to use, or `create_project` if they want a new one. Never leave the `YOUR_PROJECT_UUID` placeholder from the examples.
   - **Multi-format designs:** every layer's `layout` and `properties` must be keyed by format name (a flat shape is only valid with a single format) — start from the `static-multi-format` example.
   - **Images as URLs.** Every image should be a public HTTPS URL — this works in every client. If the user has no URL for an image, ask for one. Only if that isn't possible and you can read the file's bytes with a tool (code sandbox, shell), inline it as a `data:image/...;base64,` URI of at most 100 KB — never type base64 yourself — and tell the user if you recompressed it and how much quality was lost (e.g. "320 KB → 17 KB").
   - **Fonts** for text layers: use the `id` returned by `list_fonts`.

2. **Submit the import.** Call `import_design_from_json` with the payload.
   - For a large or hand-built payload, first call it with `validate_only: true`: it checks the payload without creating anything. It answers `status: DONE` with an empty `import_id` and no `result` — nothing was created, so run the real import afterwards and never report a design ID from a validation call. It doesn't check fonts, image URLs or the project.
   - `strict: true` makes the import fail when a text doesn't fit its box. By default the design is still created with a `text_fit_failed` warning.
   - The call waits up to ~60 seconds and usually returns the final status directly. Pass `wait_for_result: false` to get the `import_id` back immediately.

3. **Handle the response** (from the import call, or later from `check_design_import_status` with the returned `import_id`):
   - **The call itself returns an error** (no `import_id`; e.g. `invalid_payload`, `unknown_font`, `unreachable_src`, `unsupported_for_type`, `out_of_range`) → nothing was created. Fix the payload at the returned path and submit again.
   - `DONE` (`is_finalized: true`) → the design is created. Report `result.uui

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: abyssale-personalize
description: Generate many personalized creatives from one Abyssale design and a dataset (a CSV, a table, a list of rows) — e.g. one banner per product, per store, per customer name. Use when the user gives or describes a list of rows and wants a creative generated per row from the same base design, such as "generate a banner for each product in this CSV" or "make one variant per city with its own name and price".
---

# Bulk-personalize an Abyssale design from a dataset

This is "mail merge" for creatives: one existing Abyssale design, one row of data per output, many finished creatives without touching the editor. Each row becomes one `generate_banners_async` call with its own element overrides. Every generation spends Abyssale credits; the amount varies by output, so never estimate it.

## Prerequisites

The Abyssale MCP server must be connected with the `generate:banner` and `read:design` scopes, plus `read:font` to look up fonts with `list_fonts`.

Not for `printer_multipage` designs — those use `abyssale-print-catalog` instead, with a different addressing scheme (pages, not per-row elements).

## Steps

1. **Identify the design.** Use `search_designs`/`list_designs` to find it, `get_design` to confirm it and — critically — to see its formats, the real layer names and which attributes are overridable. **Never guess layer names or property names**: a wrong layer or property name has no effect, and an override must be an object (e.g. `{"payload": "…"}`, not a bare string).

2. **Get a concrete reference.** Call `get_design_format` for the format you'll generate, to see one format's current values — useful for knowing what a valid value looks like for each attribute you're about to override (e.g. is a color a hex string). Image values must be public HTTPS URLs; if the dataset has local files instead, ask the user for links. For a font, use the `id` returned by `list_fonts` in `elements.<layer>.font`.

3. **Map the dataset to layers.** Get the user's rows (they may paste a CSV, describe a table, or reference a file) and map each column to a layer name + attribute from step 1. Confirm the mapping with the user before generating anything if any column name doesn't obviously match a layer — a wrong mapping produces N wrong creatives, which is expensive to redo.

4. **Submit one `generate_banners_async` call per row**, with `elements` built from that row's values (layer name → override properties). Always pass `template_format_names` with exactly the formats wanted — omitting it renders every format of the design for every row. Before a large batch, tell the user how many rows × formats will be generated and wait for their go-ahead. Then set `wait_for_result: false`, submit sequentially or a few at a time, and keep the mapping from each row to its `generation_request_id`. If a response already came back finalized, use its `banners` and `errors` directly.

5. **Poll each pending `generation_request_id`** with `check_generation_status` until every row is finalized. Treat `is_finalized: false` as normal and re-poll later, not as a failure. A finalized result has both `banners` and `errors` — account for both. A request can only be looked up for 7 days (`generation_request_gone` after that).

6. **Report as one batch**, once everything is done: which rows succeeded, which (if any) failed and why, and the asset URLs (prefer `cdn_url`) — matched back to the row/identifier the user will recognize (product name, city, etc.), not just the raw generation id.

## Notes

- Build a fresh `elements` object for each row instead of reusing and mutating one across the loop, so a value from one row (e.g. when the next row's cell is blank) never carries over into the next.
- For a large dataset, offer to run a small batch first (e.g. 3-5 rows) so the user can confirm the mapping looks right before committing to the full run.

View saved version →

---
name: abyssale-print-catalog
description: Generate a multi-page PDF (catalog, brochure, lookbook, multi-page menu) from an Abyssale multi-page print design (type printer_multipage). Use when the user asks to "generate the PDF catalog", "export this brochure as a PDF", "make a multi-page print piece", or "generate one catalog per store". Not for single-page flyers or posters, single banners, social formats, or video — see abyssale-variations for those.
---

# Generate a multi-page PDF catalog from Abyssale

`printer_multipage` is a distinct Abyssale design type: a fixed sequence of print pages, not the `formats[]` a regular banner design has. Generation fills the existing pages — it never adds pages. If the content needs more pages than the design has (e.g. 40 products for 10 pages), tell the user: pages are added in the Abyssale editor. It needs its own generation call and its own way of addressing content: `generate_static_banner` and `generate_banners_async` both reject this design type outright. Every generation spends Abyssale credits; the amount varies, so never estimate it.

## Prerequisites

The Abyssale MCP server must be connected with the `generate:banner` and `read:design` scopes.

## Steps

1. **Confirm the design is `printer_multipage`.** Use `search_designs`/`list_designs` to find it, then check its type before proceeding — if it isn't `printer_multipage` (e.g. a single-page `printer` flyer), this is the wrong skill; use `abyssale-variations` instead.

2. **Get the page structure before writing any overrides.** Call `get_design_as_import` on the design (`get_design` doesn't show the layers of each page). It returns every page's `payload.pages[]` entry, in order, with each page's `layers[]`. **Never guess page, layer or property names**:
   - Pages have no id/name field of their own; you address the Nth page positionally as `page_1`, `page_2`, … (1-indexed, matching array order).
   - Layer names come from each page's `layers[].name`.
   - Property names are the keys under each layer's `properties` (e.g. `payload` for a text). Copy the format of the existing values — print colors may be `cmyk(…)`.

3. **Build the overrides.** For each page you want to change, pass an object keyed by that page's layer names (from step 2), each mapping to the override properties for that layer — `{ "page_N": { "<layer name>": { …overrides } } }`. `pages` is required: pass `{}` to export the catalog with its saved content unchanged. Images must be HTTPS URLs.

4. **Call `generate_multipage_pdf`** with `design_id` and the `pages` object from step 3. Two important behaviors:
   - **An unknown page, layer or property name has no effect.** If a page didn't change as expected, re-check the names against `get_design_as_import`'s output.
   - It waits internally for up to ~60 seconds and returns the finished PDF directly if ready in time. Pass `wait_for_result: false` up front if the catalog has many pages (likely slow) or the user said not to wait — you'll get a `generation_request_id` back immediately instead.

5. **If you got back a `generation_request_id`** (either because `wait_for_result: false` was set, or the 60s window ran out), poll it with `check_generation_status` — the same status tool used for async banner/video generation. Once finalized, give the user the PDF URL from `banners` and surface any `errors`. A request can only be looked up for 7 days (`generation_request_gone` after that).

6. **Print options**: pass `print.display_crop_marks: true` if the user wants crop marks. Don't set `print.color_profile` unless the user gives you a color profile UUID (a name like "CMYK" or "FOGRA39" can't be passed). Otherwise leave `print` unset.

7. **One PDF per row** (e.g. one catalog per store from a dataset): one `generate_multipage_pdf` call per row with a fresh `pages` object each time. Before the batch, tell the user how many PDFs will be generated and wait for their go-ahead; offer a test on 1–2 rows first; submit with `wait_f

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: abyssale-variations
description: Generate outputs from an existing Abyssale design in several of its existing formats, in several languages or text variations, or as a video/GIF/HTML5 banner from an animated design, in one go. Use when the user asks to "generate N variations of this banner", "render this in all its formats", "resize/adapt this banner for LinkedIn", "export this animated design as a video", "make it in French and German", or wants several creative outputs derived from one Abyssale design. For one creative per row of a dataset, see abyssale-personalize. Not for multi-page PDFs from a printer_multipage design — see the abyssale-print-catalog skill for that.
---

# Generate variations from an Abyssale design

Abyssale can turn one design into many rendered outputs without recreating the design each time. What a design can produce depends on its `type`:

| Design type | Outputs (`image_file_type`) |
|---|---|
| `static` | images: `png`, `jpeg`, `webp`, `avif`, `pdf` |
| `animated` | `mp4`, `gif`, `html5` |
| `printer` | `pdf` |

A design's **formats** (sizes) are defined in the design itself — created in the Abyssale editor or by an import. Generation renders those formats; it never creates a new size. Every generation spends Abyssale credits; the amount varies by output, so never estimate it.

Note: `printer_multipage` designs are a different design type and are out of scope here — `generate_static_banner`/`generate_banners_async` both reject them. Use the `abyssale-print-catalog` skill for those.

## Prerequisites

The Abyssale MCP server must be connected with the `generate:banner` and `read:design` scopes, plus `read:font` to look up fonts with `list_fonts`.

## Steps

1. **Identify the design.** Use `search_designs` or `list_designs` to find its identifier, then `get_design` to confirm it's the right one and read its `type`, its available formats and its layers.
   - If the user asks for a size the design doesn't have, say so — new formats are added in the Abyssale editor. Don't invent a `template_format_names` value.
   - For a text, language or image change, map it to the real layer names and attributes from `get_design` (call `get_design_format` to see what a valid value looks like). **Never guess layer or property names**: a wrong name has no effect. Images must be HTTPS URLs. For a font change, use the `id` from `list_fonts` in `elements.<layer>.font`.

2. **Choose the tool:**
   - **One image, in one format, from a static design, with no AI properties** → `generate_static_banner`. It returns the file directly.
   - **Everything else** → `generate_banners_async`: several formats, animated designs (`mp4`/`gif`/`html5` always go through it), printer designs, and AI image properties (`remove_bg` to remove an image's background, `text_to_image` to generate an image from a prompt — they also spend AI credits). Set `image_file_type` to match the design's type (table above); for a printer design, pass `print.display_crop_marks: true` if the user wants crop marks.

3. **Submit the generation(s).**
   - **One call per content variant** — the design as it is, each language, each text swap — with that variant's `elements` overrides (build a fresh object per call). In each call, list every format wanted for that variant in `template_format_names`; omitting it renders every format of the design. Don't split formats into separate calls.
   - A default call waits up to ~60 seconds and usually returns finished banners directly. For more than a few calls, tell the user how many outputs will be generated, wait for their go-ahead, then submit with `wait_for_result: false`, sequentially or a few at a time, and keep track of which request ID is which variant.
   - **Update a visual in place** only when the user explicitly wants to replace a visual already generated (e.g. "keep the same link"): pass its `id` as `original_visual_id`. The visual is overwritten and keeps its share URL; with `generate_banners_async` the 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: html-to-abyssale
description: Recreate an HTML/CSS banner (absolute-positioned elements over a fixed-size canvas — the shape of HTML5 ad banners, email banners, or design-tool HTML exports) as a native, editable Abyssale design, including basic CSS/GSAP animation mapped to Abyssale's tween system. Use when the user gives HTML/CSS for a banner and wants it rebuilt in Abyssale via import_design_from_json, not just referenced. Does not handle canvas-rendered banners; animation support is best-effort, not a full reproduction of every CSS/GSAP effect.
---

# HTML → Abyssale conversion

Goal: read an HTML/CSS banner's structure and rebuild it as native Abyssale layers
(text/button/shape/image), one element per visible node — not flattened into a
screenshot. Animation is carried over on a best-effort basis: reach for the closest
native Abyssale tween, don't try to reproduce every CSS/GSAP effect exactly.

## Scope

**Handles**: absolute-positioned banners over a fixed-size canvas — the structure
HTML5 ad banners, email banners, and design-tool exports actually use (a container
with a fixed `width`/`height`, children `position: absolute` with `left`/`top`).

**Does not handle: canvas-rendered banners.** Some real HTML5 ad banners render
everything by drawing onto one or more `<canvas>` elements from JavaScript, with no
DOM structure to inspect — no `left`/`top`, no text nodes, just imperative draw calls
inside `.js` files. Detect this by checking whether the visible content lives inside
`<canvas>` tags with empty bodies (as opposed to `<img>`/`<div>` children). If so, say
so and stop — don't attempt a conversion, and don't fall back to a screenshot import
without the user explicitly asking for that specific (much lower-fidelity) outcome.

**No single fixed canvas (flexbox-centered `body`, no explicit `width`/`height` on the
container)**: don't hand-estimate pixel positions from reading the CSS — guessed
coordinates have been wrong enough to cause visible overlaps. Measure real positions
instead (see "Measuring real positions" below).

**A source with a `<video>` element** maps to a native `video` layer — just a plain
hosted `src` (its only required property; `muted` and `opacity` are the only other
ones — map a source `muted` attribute to `muted: true`), positioned/sized like any
other layer, confirmed via a real conversion (a hero `<video autoplay muted loop>` →
one `video` layer with `properties.default.src` set to the same hosted `.mp4` URL).
Like any layer, it spans the whole timeline unless you give it an `animation` window
(see the animation rules below). Get the exact shape fresh with
`get_design_import_example(type: "animated-video")` rather than reconstructing it.

**One HTML source becoming a multi-format Abyssale design** — several formats
sharing one layer set — is confirmed working: build `formats` as a list of `{name,
width, height, background_color}` entries, and key **every** layer's `layout` **and**
`properties` by format name (a `default` key can hold the values shared by all
formats; a flat `properties` is rejected once there are two formats). If
the format's box materially changes proportions, redesign that layer's numbers for the
new box rather than naively scaling — a 320×480 hero video area doesn't have to stay
the same height in a 300×600 half-page, and the official `static-multi-format`/
`animated-video` examples both hand-tune per-format numbers rather than scale. See
"Multi-format and `slide` tweens don't mix safely" below before animating layers whose
`layout` differs by format.

## Steps

0. **Before writing any payload by hand, fetch a fresh official example** —
   `get_design_import_example(type: "animated")` (or `"static"`, `"animated-video"`,
   `"static-multi-format"` as fits) — rather than reconstructing the shape from memory
   or an earlier conversation summary — common mistakes otherwise: `formats` built as
   an object instead of a list, a top-level `animations` map instead of a per-lay

Preview of the first 4,000 characters. Read full instructions →