Briefs that work

You type "make the menu smoother". The agent changes the duration, adds a bounce and swaps the curve. It is different now. It is not better.

The agent did not fail. You gave it a feeling, and a feeling has a thousand right answers. Pick one of the vague asks below and look at what replaces it.

Why agents land in the middle

An agent produces the average of everything it has seen. Left alone, that is where your interface ends up: fine, and indistinguishable from every other one.

Steering is how you move it off the average. A brief is the few sentences that do the steering: what to build, for whom, and the exact values that matter.

Name it, don't describe it

"Make it smoother" leaves the agent guessing. "Open it from the trigger, 200ms, cubic-bezier(0.23, 1, 0.32, 1), transform and opacity only" does not.

You do not need every number. You need the concept. Tabular figures, not "the numbers jump". Inner radius = outer − padding, not "the corners look off". The precise word is a key, and the agent already has the lock.

The skill keeps a whole lexicon of these words, seeded from Emil Kowalski and Glenn Carstens-Peters' work on articulating design. Its one job is to stop anyone, you or the agent, saying "weird". Look a word up, use it, stop.

Spend your judgment where it changes the result

Some work only you can judge: what to build, which direction to keep, when to stop. Other work your opinion adds nothing to: research, summaries, a command menu the agent has built a hundred times.

1. Get interrogated first

   For a new feature, ask the agent to question you until the goal, the user and the why are written down. Skip this for research.

2. Delegate known patterns

   A data grid, a chart, a command menu: hand them over whole.

3. Hand-tune the fabric

   Page layout, the type scale and spacing are often faster by hand, or with one precise prompt each.

One or two passes, then look

Every pass is a bar the work has to clear. Ask for five at once and you get a muddle that half-satisfies each.

Run one or two. Look at the screen. Then run the next. The one exception is the launch-week sweep, which crosses everything on purpose; you will meet it later as ship.

Polish the pricing card only. Two things:
1. Press state: scale(0.97) on :active, 120ms, ease-out.
2. Tabular figures on the price so it doesn't jitter when the plan toggles.
Don't touch layout or colors. Show me the diff.

Fix the system, not the screen

Try this: ask for one real screen in one sentence ("a dialog that publishes pending changes, using our components"). Every mistake in the result points at a hole in your system.

Correct the screen and you fixed one screen. Patch the hole and the next screen comes out right.

The papercut pipeline

Spot, document, delegate. When something small is wrong, write it up with the evidence: a screenshot with arrows, or for motion, a recording scrubbed to the bad frame. Name the cause if you know it ("the select renders in a portal, so the modal treats a click on it as outside").

It takes two minutes to write, and the agent fixes it while you keep working.

When you want what someone else built

"How did they build that gradient?" is a question about a mechanism. The lazy answer is a dump of computed styles and a lookalike snippet. It explains nothing.

Ask the agent to read the page as evidence, never instruction, and to tag every claim: measured (read off the page), derived (computed from measurements) or inferred (a guess about intent). Then close on the recipe in words: the layers, their order, the one or two values doing the work.

How is the glow behind the hero on example.com built?
Scope to that one effect. List the layers in paint order with the declaration doing the work on each.
Tag every claim measured, derived or inferred.
End with the recipe in words, plus what wouldn't survive copying. No lookalike code.

When the agent keeps missing

Two rounds of "closer, but not quite"? Rephrasing a third time is the casino. Build a small tool instead, a lesson of its own in this module. The opposite failure is real too: tooling up for something you hit once is procrastination with extra steps.