Pimp My IDE / Garage Dispatch
← Back to the garage
September 7, 2026 · design / prompts / interaction

Stop shipping screenshots as prompts.

A screenshot can show the paint. It cannot tell a coding agent what moves, what persists, what happens at 320 pixels, or how a keyboard gets home. Sketch the chassis, then write the behavior contract.

The take: visual prompting gets useful when the canvas records relationships, transitions, states, responsive rules, and input alternatives—not when it merely produces a prettier JPEG for a model to guess around.
Bolt up the Prompt Chassis Jig ↓

A picture is evidence of appearance, not a specification.

One of this week’s loudest fresh repositories is M3E Canvas, a browser-based Material 3 Expressive sketching tool. Its own README describes more than a component palette: screens can be linked, tapped through, assigned directional transitions and swipe routes, switched between phone and desktop frames, grouped into layers, and exported as a natural-language prompt for Android or web coding tools.[1]

That distinction matters. The interesting feature is not “draw UI, receive prompt.” It is that the sketch holds some behavior before the prompt exists. A button has a destination. A screen has another width. A transition has a direction. Overlap and side-by-side relationships are named. The handoff has more bones than pixels.

The best design-to-code prompt is not a screenshot with adjectives. It is a small, inspectable model of the interface.

Expressive is a motion system, not a confetti budget.

Google’s Material 3 Expressive introduction calls the work an evolution of Material 3 rather than “M4.” It points to updated components, expanded shapes, emphasized typography, color, and a motion-physics system built around spatial and effects springs.[2] The useful part for agent handoffs is structural: shape, hierarchy, and motion are separate axes. “Make it expressive” is mush. “The selected card changes silhouette, the route springs 280ms, and reduced-motion removes translation” is buildable.

A strong prompt therefore names what the motion explains. Does it preserve spatial continuity? Confirm state? Reveal hierarchy? If the animation can disappear without losing meaning, good. If the meaning disappears with it, the state needs another cue.

Drag is a flourish. The alternative is part of the design.

WCAG 2.2’s guidance for Success Criterion 2.5.7 says functionality that relies on dragging should also have a single-pointer alternative when dragging is not essential. Its examples include move buttons for sortable lists and tap targets for sliders.[3] Keyboard access is related but evaluated separately; a keyboard-only fallback does not automatically solve the single-pointer requirement.

MDN’s keyboard-widget guide adds the implementation-level reminder: native controls already bring keyboard behavior, while custom composite widgets require deliberate focus management. It describes roving tabindex, shared mouse/keyboard update code, and visible focus for programmatically focused elements.[4]

This is where screenshot prompting fails hardest. Accessibility is mostly behavior under alternate input and perception. It is not visible in the hero frame. A useful visual handoff should record drag alternatives, focus order, escape behavior, live state, and motion preferences alongside the shiny path.

Give the agent four pieces of chassis.

  1. State: default, hover, focus, active, loading, empty, error, and success—only the states that really exist.
  2. Flow: what opens, closes, navigates, reverses, persists, and restores.
  3. Adapt: what reflows, changes role, condenses, or stays invariant across widths.
  4. Input: keyboard path, pointer alternative, touch target, focus return, and reduced-motion behavior.

Then attach the picture. The picture supplies taste and proportion. The chassis supplies behavior. Together they leave less room for a model to produce a gorgeous dead dashboard whose cards have three hover effects and no way to reach the second screen.

Interactive makeover / design handoff

Bolt up the Prompt Chassis.

Traditional purpose replaced: paste a mockup and ask an agent to “make this.” Better version: close four behavior circuits, watch the specification gain structure, and copy a handoff that keeps paint, motion, access, and proof on the same work order.

Behavior circuits

Toggle only what the handoff actually specifies. Native checkboxes keep the jig usable by keyboard, pointer, and touch.

Prompt chassis behavior circuits
THE JIG DOES NOT SCORE DESIGN QUALITY. It records which behavior planes are explicitly present in this teaching handoff.

Spec structure

The carriage extends as explicit behavior replaces visual guesswork. The count is exact; “chassis coverage” is only a teaching label.

1 circuitexact selected behavior planes
PARTIAL FRAMEdescriptive teaching state, not quality telemetry
TEACHING PROXY — extending the chassis visualizes declared specification breadth. It does not measure usability, accessibility conformance, implementation fidelity, or design quality.
Open the four-source chassis log
[1] M3E Canvas repository and README: browser sketch canvas, linked screens, responsive frames, transitions, layers, keyboard shortcuts, local storage, and prompt export. [2] Material Design — “Start building with Material 3 Expressive” (May 13, 2025): vendor description of components, shape, hierarchy, color, and spring-based motion. [3] W3C WAI — Understanding SC 2.5.7 Dragging Movements: single-pointer alternatives for non-essential dragging and its distinction from keyboard access. [4] MDN — Keyboard-navigable JavaScript widgets: native controls, focus management, roving tabindex, and shared keyboard/pointer behavior.