Skip to main content
Glama

skill

Load instruction documents that teach how to work with the design engine: create, edit, resize, localize, brand, and quality-check designs using the CoDesign server.

Instructions

Load a skill — an instruction document that teaches you how to work with this server. Read the relevant skill BEFORE attempting work it covers. Intended sequence: (1) call with just name to get the entry document — it ends with an index of the bundled files; (2) pass query (a regex, like Grep) to search the bundled files for the rules you need, scoping with path when you know the file; (3) full-read a file via path only when it is small (the index shows line counts) or after a search missed twice — slice large files with offset (skip count: offset=10 starts at line 11) and limit. Entry documents are always returned whole (offset/limit are ignored for them).

Triggered for any task using this server's edit or preview tools. Authoritative TypeScript signatures for the CE.SDK CreativeEngine. Use this skill whenever you need the exact signature, parameter types, or return type of an engine.* method — especially before calling a method you haven't used yet. This is THE source of truth for signatures: generated from the .d.ts shipped with the same @cesdk/node package the engine runs, while prose docs (the guide skill) can drift.

Reading this skill with no path returns the WHOLE edit-code API surface inline — the engine.design facade, the props trees, the attachment unions and the capability matrix. That is one call and it is all edit code needs.

The sub-file "signatures.d.ts" is the same surface plus the upstream CE.SDK core — JSDoc-free signatures with every string-vocabulary type (property names, block types, enum values) flattened to its literal union on the declaring line. It is served a page at a time: search it with query (e.g. query: "saveToArchive"), then slice around the hit with path + offset/limit.

Triggered when you need to verify an engine.block.* or engine.scene.* signature, look up a parameter type, or confirm an enum/string-property name. Use when applying a brand kit / brand style to an existing CoDesign / CE.SDK design — a rules-governed restyle (recolor + refont + logo + treatment by role), not a free-form style change; when a restyled design reads off-brand (free-chosen colors, wrong accent, a second colour used as structure, a coloured button the brand forbids, a headline set in a weight the brand bans, a flat bordered card, or the wrong / recoloured / redrawn logo); when loading a brand's fonts, wordmark SVG, or signature device into a scene; or when turning an external brand (a guidelines PDF, a website / URL, a Figma file, or a raw asset dump) into a reusable brand kit. Use when the user asks to create / generate / make a NEW design from a prompt — a deck or slides, poster, flyer, social post, business card, or a custom-size canvas. Runs the guided intake: derive every brief parameter the prompt already answers (class, format, audience, vibe, brand, content), ask ONLY the missing questions — one round, chip-style options, "Decide automatically" defaults — then echo the design brief and hand off to the handbook Loop. A brief given to the /codesign prompt lands here as the stated input. Canvas-format reference for CoDesign designs — one file per screen/print format (ig-post, ig-square, ig-story, widescreen, linkedin-post, x-post, deck, poster, flyer, business-card): exact W×H, aspect, medium, platform safe zones, print bleed/dpi. Use when picking or setting up a canvas size, checking a platform safe zone, or preparing print dimensions. Re-composing an existing design into a format is the resize skill; new-design intake is the create skill. Look up CE.SDK Node.js reference docs, guides, and configuration pages — prose explanations, recipes, and concept docs for everything the engine can do (text, fills, colors, export, video, templates, asset sources, …).

Use when you need to understand HOW a CE.SDK feature works or want a code recipe; also triggered by "IMG.LY", "CreativeEditor", "CE.SDK", or "cesdk" when the user needs an existing Node.js doc page. For exact TypeScript signatures use the api skill instead.

The entry document is an index; every doc page is a sub-file — read one with path (e.g. path: "text/add.md"), or search them all with query. Use to quality-gate a design before reporting it done — the mandatory step 5 of the handbook Loop; when the user asks for a design review, score, audit, or QA; or when a design needs remediation after a failed review. The axes, the gate, the scorecard format, and the remediation loop are defined in this skill's body — read it before scoring; do not judge from memory of this description. Use when creating or fixing translated / localized variants of an existing CoDesign / CE.SDK design (e.g. de/ja/ru/ar editions); when a localized edition's text blocks or decorative elements have drifted, re-centered, or resized away from the source layout; when translated copy is tofu, overflowing, mis-tracked, or the wrong font after a language swap; or when loading a non-Latin script (Cyrillic / CJK / Arabic RTL / Vietnamese) font into a scene. Use when the user is new here or asks what this server is / what it can do ("what is CoDesign", "what can you make", "show me"). A guided, plain-language introduction for a HUMAN: explain what CoDesign is in everyday terms, put the six jobs it does on the table, let the user pick one, then run it either on the bundled demo design or on the user's own idea — closing with the optional (never required) IMG.LY sign-in and the ways to earn more credits. Not a design manual: the handbook remains the required read before any edit. Use when resizing or reformatting a CoDesign / CE.SDK design to a new size or aspect ratio (ig-post ↔ ig-square ↔ ig-story ↔ widescreen, or a custom W×H); when building the size/format editions of a design from an existing design or from a brief; or when a reformatted edition has a dead void / letterboxed empty band, drifted or broken margins, off-canvas or clipped elements, mis-scaled decoration, or a stretched / squished layout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesSkill to load.
pathNoOptional sub-file within the skill. Defaults to the entry document.
limitNoMaximum number of lines to return.
queryNoSearch the skill instead of reading it: a regular expression matched per line (like Grep). Smart-case: all-lowercase pattern → case-insensitive; any uppercase → case-sensitive. An invalid pattern is an error. Output is grep format — `file:N:` match lines, `file-N-` context lines, blocks headed by `--` with the enclosing markdown headings. Combine with `path` to search one file. Mutually exclusive with offset/limit.
offsetNoLines to skip before reading (offset=10 starts at line 11). Use with `limit` to slice large files.
contextNoContext lines around each match, like grep -C (default 2; 0 = bare match lines). Only valid with `query`.
maxResultsNoMaximum search matches to return (default 50, max 200).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it discloses non-obvious behavior: entry documents are always returned whole and ignore offset/limit, query acts like Grep, large files should be sliced, and a search should be attempted twice before a full read. It also states the smart-case and invalid-pattern consequences in the schema-backed text, with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The operational guidance is front-loaded and each section has a role, but the available_skills block is lengthy. It is justified because the enum values and triggers must be documented somewhere, and the prose is tightly written given it covers ten skills.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema and no annotations, the description covers the workflow, how to choose each skill, the search-vs-read strategy, and the entry-document/index hints. An agent can invoke this tool correctly without needing external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns one more point by explaining how the parameters chain together (name → query → path → offset/limit) and by adding behavior the schema does not state, such as entry documents ignoring offset/limit. It does not duplicate every field, relying on the rich schema for details like maxResults/context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and object: 'Load a skill — an instruction document...' and goes on to list ten named skills with one-line definitions, making it unmistakable what is loaded. It also separates the skill mechanism from the skills themselves, so an agent can tell 'skill' from content-bearing tools like list or view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit before/after rule ('Read the relevant skill BEFORE attempting work it covers'), a numbered intended sequence, and per-skill trigger conditions ('Use when...', 'Triggered for any task using...'). It even routes between alternatives within the tool ('For exact TypeScript signatures use the `api` skill instead').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.