# Verbs that make things

> Use sound to decide which moments earn a sound and build one family, svg to create or animate vectors, film to plan or measure a launch video, and stage to build faux product UI for a landing page.

Module: The /design-engineering toolkit · Level: intermediate · 9 min · https://school.agents.org.in/design/toolkit/verbs-that-make

The last four verbs make new things: sounds, vectors, films and product demos. Each still starts with a decision, and each comes back in a shape you can check.

## sound

**Reach for it** when you're wondering if your product should make a sound, or when the sounds it makes feel stock, late or annoying.

*[Interactive demo: sound: a sound map where most moments get 'none', and the one that survives says why.]*

```bash
/design-engineering sound
```

Its posture is **decide, then build**. If you only asked *whether* something should make a sound, you get one line and it stops.

For product UI, it classifies every proposed moment and **rejects most of them**. The test is the hundredth use, not the first: a click sound is charming once and maddening by lunch. The survivors become one family made of one material, generated (with ElevenLabs if you have a key, or an offline synthesiser if not), and wired so that sound is off by default, unlocks on your first tap or click, and lands its sharp start on the exact frame the animation makes contact.

**What comes back:** a sound map (A table of every proposed moment with the sound it gets (often none), its material, length, trigger and the reason. What the sound verb returns) (Moment, Sound, Material and contour, Length, Trigger, Why), then the files and the wiring.

For a video, the defaults flip: sound is the medium and silence is placed on purpose. It picks the film's sound register first.

## svg

**Reach for it** when you need an icon, a logo mark or an illustration made or cleaned up, or when you want one to move.

*[Interactive demo: svg animate: the engine for where the file lives, the values, the reduced-motion path, and the size.]*

The second word picks the job:

| Invocation | Does |
|---|---|
| `svg create` | draws on a whole-number grid with named groups and `currentColor`, optimises it, returns the file and its size before → after |
| `svg animate` | decides whether it should move, picks the engine for where the file lives, adds the reduced-motion path, returns the motion plan and the file |
| `svg sticker` | an animated isometric sticker for an empty state or onboarding |

```bash
/design-engineering svg create icons/export.svg
```

The engine follows the file's home. Inline in the page: CSS or the Web Animations API. Used as an `<img>`: keyframes embedded in the file itself, because page CSS can't reach inside. A messy file with no `viewBox` or unnamed groups gets `create` first.

## film

**Reach for it** to plan a launch video before anyone opens an editor, or to measure one that's rendered.

*[Interactive demo: film review: measured numbers beside the targets for the film's register, never a vibe.]*

| Invocation | Posture | Does |
|---|---|---|
| `film plan` | decide, then build | names the register (The kind of launch film you are making, such as UI motion graphics, product camera or kinetic type. It sets the cut rate, stillness and loudness) first, then the beats, the type, the product demo, the motion, the cuts and the sound |
| `film review launch.mp4` | judge | measures at the native frame rate, builds contact sheets, reads the loudness, recounts every cut by eye |
| `film formats` | build | a loop, a logo sting, or a vertical cut |

```bash
/design-engineering film plan "60s launch for the export feature"
```

With no second word, a video file means `review` and anything else means `plan`. A URL is never downloaded without your yes: it tells you the filename, source and size first.

*(film review never edits the composition. It measures and reports.)*

## stage

**Reach for it** when a landing page, feature card, docs page or bento grid needs a picture of your product: a still, or a short demo with a cursor.

*[Interactive demo: stage demo: the plan before any code, then the component, contact sheets and a rehearsal note.]*

```bash
/design-engineering stage demo "the export flow, cursor clicks Export"
```

| Invocation | Returns |
|---|---|
| `stage still` | a framed product shot, at its real size plus a 358px phone design |
| `stage demo` | the still as its opening frame, a 3–5 beat story of 10–16 seconds, a poster frame, a pause control |
| `stage bento` | a planned grid of feature tiles, checked at its widest and narrowest |
| `stage review` | judge only: frames it films itself, ranked framing → hierarchy → motion → polish |

Every job starts the same way: your contract's colours, type and radii become the demo's look, and the plan is written before code (where it sits, the one thing that happens, the 3–7 real strings, what's left out). With Benji Taylor's Stageshow installed, the build goes to it. The demos in this course are built that way.

**A demo that passes review (paste into your agent):**

```text
/design-engineering stage demo "AI answer with sources" for the hero beside our headline.
Write the plan first. Real strings only where the story is.
Film it at 720 and 390, step through every beat, and hand me REHEARSAL.md with what you didn't check.
```

## The whole toolkit, one table

| Verb | Posture | Returns |
|---|---|---|
| `review` | judge | verdict + Before / After / Why |
| `tells` | judge | deletion list |
| `a11y` | judge | table with a WCAG criterion per row |
| `polish` | build | edits + up to five rows |
| `motion` | decide, then judge or build | values in ms, curve, properties |
| `mobile` | fix | wrong / changed / needs a phone |
| `tokens` | build | token map + edits |
| `break` | adversary, then judge | Broken / Ugly / Fragile, then stop |
| `ship` | fix | verdict, lanes, device and human lists, build output |
| `sound` | decide, then build | sound map + files |
| `svg` | build | file + size, or a motion plan |
| `film` | decide or judge | a plan, or measured rows |
| `stage` | build (review judges) | component + contact sheets |

**Check yourself:** You ask /design-engineering sound to add sounds to a to-do app. It proposes sounds for 'task added', 'task completed', 'button press' and 'list reorder'. Which is it most likely to keep?

- [ ] Button press, because it's the most frequent
- [ ] All four, to make the product feel alive
- [x] Possibly task completed, a meaningful moment; the frequent ones get rejected
- [ ] List reorder, because drags need feedback

*Why:* sound judges each moment by its hundredth use. Things that happen hundreds of times a day (presses, reorders) get rejected; a meaningful, less frequent moment may earn one.

## In the skill

- https://school.agents.org.in/skill/commands/cmd-sound.md
- https://school.agents.org.in/skill/commands/cmd-svg.md
- https://school.agents.org.in/skill/commands/cmd-film.md
- https://school.agents.org.in/skill/commands/cmd-stage.md