# Fix a precise visual bug

Describe the element, the measurement and the viewport, and Claude Code finds the cause of a layout bug, fixes it and checks other widths.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
The {{element}} extends {{amount}} beyond the {{container}} on {{viewport}}. Fix it.
{{#page}}
Where: {{page}}
{{/page}}
{{#expected}}
Expected: {{expected}}
{{/expected}}

1. Find the markup and styles that size the {{element}} and the {{container}} at that width. Explain the cause in one or two sentences before changing anything, for example a fixed width, padding added to a full width, or a media query that does not apply.
2. Fix the cause with the smallest change. Do not hide the problem with overflow: hidden, a negative margin or a one-off pixel offset unless you explain why that is the right fix.
3. Keep other screen sizes as they were. Check at least one narrower and one wider width too.
4. If you can open the page in a browser and take screenshots, compare before and after at each width and keep going until the {{element}} sits inside the {{container}}. If you cannot, say so and tell me exactly what to check by hand.
5. Run the project's lint, build or visual tests if it has them. Do not commit.

If you cannot reproduce the problem, or the code does not match my description, say what you found instead of guessing a fix.

Finish with the cause, the change with file and line, and the screenshots or checks you used.
```

## Fields

- `{{element}}` (required): Element that is wrong.
- `{{amount}}` (required): By how much.
- `{{container}}` (required): What it extends beyond.
- `{{viewport}}` (required): Where it happens. A screen width, device or browser. A number in pixels is the most precise.
- `{{page}}`: Page or component. Optional. Saves Claude a search.
- `{{expected}}`: What it should look like. Optional.

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

## When to use this template

- You can see exactly what is wrong: which element, by how much and at which screen size, and you want a targeted fix rather than a general restyle.
- Claude Code can render the page and take screenshots, so it can check the fix itself. Use the preview built into the Desktop app, or, for terminal sessions, set up browser access first through Claude in Chrome or a Playwright server added over MCP.
- You have a screenshot of the bug. Paste or drag it into Claude Code together with the prompt; images cannot be attached on this page.

## When not to use it

- The page needs a redesign rather than a fix. Give Claude the design or a mockup and ask it to build to that instead of patching one element at a time.
- You cannot say what is wrong beyond "it looks off". Take a screenshot, mark the problem, and describe it in measurements before using this template.
- The bug only appears in a browser or device Claude cannot open. Claude can still fix from the code, but you will have to do the visual check yourself.

## Why this structure

- The opening sentence carries four precise facts: the element, the amount, the container and the viewport. Precise input narrows the search to a few rules in the stylesheet instead of the whole layout.
- Step 1 asks for the cause before any change, so you can see whether Claude understood the layout before it edits it.
- Step 2 names the quick patches that hide an overflow without fixing it. Ruling them out by default keeps the fix at the cause.
- Step 3 checks a narrower and a wider width, because a change aimed at one viewport often moves something at another.
- Step 4 gives Claude a visual check it can run when a browser tool is available, and an honest fallback when it is not, instead of a claim that the bug is fixed.
- The rule about not reproducing the problem tells Claude to report what it found instead of inventing a fix for a bug it cannot see.

## Example input (fictional)

Element that is wrong:

```
login button
```

By how much:

```
20px
```

What it extends beyond:

```
card border
```

Where it happens:

```
mobile, 375px wide
```

Page or component:

```
/login, src/components/LoginCard.tsx
```

What it should look like:

```
the button stays inside the card with 16px padding on each side
```

## Follow-ups to send Claude

- Take screenshots of the same page at 320, 768 and 1280 pixels wide and list anything else that overflows or overlaps.
- Is the same cause present in other components that use this card? List them, but do not change them yet.
- Add a visual or layout test that would fail if the button moved outside the card again.

## Common mistakes

- Describing the problem in general words. "The button looks wrong on mobile" leaves Claude to guess; an element, a measurement and a width do not.
- Accepting a fix you have not seen at other widths. A rule that fixes the phone layout can break the tablet one.
- Letting overflow: hidden through without a reason. It removes the symptom, and can also cut off focus outlines or content.

## Related templates

- [Debug an error](https://awesomeclaudeprompts.com/prompts/debug-error/): Turn an error message and the code around it into a ranked list of likely causes, a check for each, and a fix you can try.
- [Build something new from an existing pattern](https://awesomeclaudeprompts.com/prompts/follow-code-pattern/): Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.
- [Review your changes before you commit](https://awesomeclaudeprompts.com/prompts/review-before-commit/): Have Claude Code review uncommitted changes against their intent and flag risks by severity, asking before any check that could change files.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Give Claude a way to verify its work](https://code.claude.com/docs/en/best-practices#give-claude-a-way-to-verify-its-work) (Anthropic documentation)
- [Claude Code docs: Desktop app, preview your app](https://code.claude.com/docs/en/desktop#preview-your-app) (Anthropic documentation)
- [Claude Code docs: Use Claude Code with Chrome](https://code.claude.com/docs/en/chrome) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.