Turn visual edits into precise AI prompts

You want the pricing cards to feel less cramped. You ask your coding agent to "give them more breathing room". It increases the gap between cards. You meant the space inside them. Neither interpretation was unreasonable; the request never made the distinction.

On an existing page, you can settle that decision before asking the agent to write code. Adjust the card in the browser, look at it alongside its neighbours, and hand over the change you actually chose. Design Mode records that visual edit; your coding agent still owns the source-code implementation.

The useful hand-off combines three things: an exact change, a reason for it, and a boundary around what should stay untouched. Numbers remove ambiguity about the result. Context prevents the right numbers being applied in the wrong place.

Open your app on a page that allows extension scripts, ideally a local development build connected to the repository your agent can access. Select the element in Design Mode and adjust its spacing, typography or other visual properties. Work on one coherent change at a time so the resulting specification stays reviewable.

The surrounding page matters. A card that looks balanced alone may be too tall in a row, push its action below the fold, or wrap awkwardly beside a longer heading. Editing the rendered interface lets you judge those relationships while choosing the values.

Review the Changes tab before exporting. Remove experiments you no longer want. A record of every idea you tried is not the same thing as a clear implementation request.

Suppose a pricing card has 16px of internal padding and a 12px gap between its content groups. You try 24px padding and a 16px gap on desktop, while keeping the compact mobile layout. These are illustrative values, not a measured result or a recommendation for every pricing page.

The visual changes answer what should change. Add a short note explaining why: the plan description and price need clearer separation, but the card should keep its current typography, colours and button treatment. Also say whether this is a shared change across all plan cards or an exception for one card.

A hand-written brief accompanying the exported changes could read as follows. This is an example of additional instructions, not a verbatim Design Mode export:

Target: the shared pricing-card component on the pricing page. Apply the desktop spacing change to all three plan cards, not just the selected instance.

Changes: increase internal padding from 16px to 24px and the gap between content groups from 12px to 16px at the existing desktop breakpoint. Keep the current mobile spacing. Preserve the title, price, colours, radius and button styling.

Implementation: inspect the existing component and spacing tokens first. Reuse a token only if its resolved value matches the intended result. If the design system cannot represent the change without a new value, flag that decision rather than silently choosing the nearest size. Do not add page-wide overrides.

Acceptance: check all three cards with their real content at desktop and mobile widths. Confirm that long plan names wrap cleanly, buttons remain usable by keyboard, and unrelated cards elsewhere in the app have not changed.

The pricing-card numbers above are illustrative. The following is a labelled export from an actual Design Mode session on this site's homepage hero, quoted as exported:

- section.py-24: padding-top 96px → 64px; padding-bottom 96px → 64px _(mobile · 404px)_

The same session also recorded a change to the hero container's mobile side padding, from 24px to 16px.

Those preview values map to existing Tailwind breakpoints on the homepage hero: the section uses py-16 sm:py-24, and the inner container uses max-sm:px-4 against the default 24px container sides. At a 404px-wide viewport the rendered result was 64px vertical padding and 16px side padding; at 1440px it was 96px vertical and 24px sides. The exported selector identified the element before implementation; the agent used the existing sm breakpoint to keep desktop spacing unchanged.

This is not a speed benchmark. The browser preview is not the repository change: after implementation, inspect the source diff and re-check the page without Design Mode overrides.

A browser selector helps identify an element. It is not necessarily the selector that belongs in your stylesheet. The rendered node may come from a shared React component, a template loop or a third-party component with its own extension points.

Ask the agent to locate the source and follow its conventions. A padding change might belong in a component variant, an existing utility class or a design token. Copying a computed style into an inline override can reproduce the preview while creating the wrong maintenance burden.

Scope is especially important with tokens. Updating one shared spacing token can affect many screens. If the intent is local to pricing cards, the agent should not turn it into a global design-system change without asking.

A screenshot shows a moment. It does not establish what should happen on keyboard focus, while a button is disabled, or when a user prefers reduced motion. Include those requirements when the edit touches an interactive component; leave unrelated behaviour alone.

For a hover adjustment, describe only the difference from the default state and name what must remain stable. For example: change the background on hover, but preserve the label colour and element dimensions. If you introduce a border, account for its space so the layout does not jump.

Treat accessibility checks as acceptance criteria, not a promise attached to a prompt. Preserve a visible keyboard-focus indicator, check text contrast against the actual background, and test any animation with reduced motion enabled. These instructions are yours to add where relevant; do not assume an export automatically covers them or proves compliance.

Copy as Prompt gives you a portable Markdown specification to paste into your coding tool alongside the intent and acceptance criteria. It does not require an MCP connection.

Send to Agent uses Design Mode's MCP connection so a configured client can read the session. The connection does not grant repository access: your coding agent separately needs permission to inspect and edit the project. Use the current MCP setup guide for your client rather than assuming every client accepts the same configuration.

Before either hand-off, review what you are sharing. Page content, comments and screenshots can contain confidential information. Use representative test data and follow your team's rules for the agent provider and connection mode.

Design Mode changes the rendered page as a preview. That preview is not evidence that the repository now produces the same result. After the agent implements the request, inspect the source diff, run the relevant project checks, and reopen the app without the temporary Design Mode overrides affecting the comparison.

Compare the result at the same viewport size, with the same content and fonts loaded. Check the edited values in browser developer tools where useful, then inspect the overall layout. Matching a padding value does not guarantee matching line wrapping or card height.

Test a neighbouring viewport as well as the one you designed at. Exercise hover, keyboard focus and disabled states when applicable. If the agent changed a shared component, inspect another place that uses it. Report a mismatch with the element, state and expected value instead of restarting with a vague visual request.

There is no guaranteed one-shot result here. Precise changes make the request easier to implement and the outcome easier to check; they do not remove the need to understand the codebase or review the work.

Pick a spacing or typography adjustment on a page you own. Make it visually, clean up the Changes tab, and copy the specification. Add one sentence about intent, one about scope and a short acceptance check. Ask your coding agent to implement it, then review the result without the preview overrides.

That is the distinction worth keeping: Design Mode captures the visual decision, while the agent translates it into maintainable source code. A useful prompt connects those two jobs without pretending they are the same job.