Follow-up prompts that fix a build

Why one giant correction fails

A long list has no definition of done. The agent can't tell which items matter most, the fixes interfere with each other, and the diff that comes back is too large to review. When item nine is wrong you can't tell whether the cause is the fix for nine or a side effect of the fix for three.

Small tasks are reviewable. Each has one diff, one check and one answer: fixed or not.

The four parts of a follow-up

• Where: the file or component, the page, and the width or state in which it happens.
• Observed: what is there now, in measurable terms. "The headline wraps to four lines at 390px."
• Expected: what should be there. "Two lines; reduce the size to 36px below 420px."
• Check: how the agent confirms it, and what must not change as a side effect.

Describe what you see, not what to feel

"The hero feels off" gives the agent nothing to act on. Look until you can name it: the gap under the header is 96px and the section rhythm is 160px; the button is 40px tall and the input beside it is 48px; the fade takes about a second and the brief said 0.6s. If you can't name it, ask the agent to report the current values first, as a task with no edits, and decide from the numbers.

Order the fixes

1. Structure first: wrong sections, missing states, broken layout at a width.
2. System second: values that should be tokens, one-off sizes, a second button style.
3. Detail last: timing, easing, optical alignment, copy fit.

When to stop fixing and rebrief

If the first build is far from what you meant, follow-ups won't rescue it. The brief was missing decisions. Go back, add the design values or the section order that was left open, and run the task again from a clean branch. Three precise follow-ups are normal. Fifteen mean the brief needs the work.

When the same correction comes up in two tasks, add it to AGENTS.md so it stops coming up.

A follow-up task to copy

Task: fix one issue. Change nothing else.

Where: [src/components/Hero/Hero.css], on [the home page], at [390px wide].

Observed: [the headline is 44px and wraps to four lines; the last word sits alone on its own line and pushes the button below the first screen].

Expected: [the headline is 36px below 420px wide and wraps to at most three lines; the button is visible without scrolling on a 390 by 844 screen].

Constraints:
- Use an existing size from src/styles/tokens.css. If none fits, stop and tell me which value you would add.
- Do not change the headline text, the desktop size ([76px] above 720px) or any other component.
- Keep the fade-up on load at 0.6s, and keep it off with prefers-reduced-motion.
- Stack stays as it is: Vite + React + TypeScript, plain CSS.

Check:
1. npm run build and npm run typecheck pass.
2. At 390px the headline's computed font size is 36px.
3. At 1440px nothing has changed: the headline is still [76px].
4. git diff --stat shows only [Hero.css].

Run it and check at 390px and 1440px. Report the diff summary, the result of each check, and anything related you noticed but did not change.

Written for this page as a starting point; swap the parts in [brackets] for your own. The full prompt of each uberdesigner template is longer and specific to one finished design, and it is tested by rebuilding the template from the prompt alone.

Keep reading

• How to brief Codex for designThe five parts of a front-end task brief for Codex: goal, constraints, design values, files it may touch and a definition of done. With a skeleton to copy.
• Design rules in AGENTS.mdAn AGENTS.md example for front-end work: where design rules go, what to include, and a rules block to copy so every Codex task follows the same system.
• Using the uberdesigner MCP server in CodexHow to connect the uberdesigner template library to Codex over MCP with two terminal commands, and what to ask the agent once it's connected.

• Landing pages
• UI components
• Restyles