How to Give UI Feedback to Claude Code Without Leaving Your Browser

You opened Claude Code, typed "make the signup button on the left a bit bigger and move it up — no, the other one — and the spacing under the email field is off," and watched it edit the wrong component. Again. Two minutes of typing. Five minutes of clarifying. Ten minutes of undoing changes to a file you never meant to touch.

The bottleneck isn't Claude Code. It's the fact that you're describing pixels with prose.

Why text-only feedback breaks

A UI tweak has three pieces of context that matter: which element, what visual state, and where in the codebase. When you type a description, you're guessing your way through all three and hoping the agent's guesses match yours.

Most of the time they don't. "The button on the left" matches three buttons. "Move it up a bit" maps to a hundred CSS values. The screenshot you finally drag in shows the symptom but not which React component owns it. Claude Code does its best — and that best is sometimes editing <MarketingHeader> when you meant <DashboardHeader>.

The fix isn't a better prompt. The fix is removing the guesswork.

What Claude Code actually wants

Read between the lines of any good Claude Code session and you'll see the agent reaching for the same pieces of context:

• A stable selector so it can locate the element across renders
• The React component name and, in dev mode, the source file path
• A screenshot of the actual state, ideally cropped to the element
• The DOM context around the element (siblings, parent layout)
• The page URL and viewport size so it can reproduce the conditions

When you type "the button on the left," you're handing over zero of those. When you paste a full screenshot, you're handing over one — and asking Claude Code to infer the rest from pixels.

The browser annotation approach

There's a faster path: capture all of that context at the moment you point at the element, in the browser, with one click. That's what markagent does, and it's the workflow this post is about.

You install the extension. You open the page you want to give feedback on — your own dev server, a staging build, anything that opens in Chrome. You hold Cmd (Mac) or Ctrl (Windows/Linux) and click. A numbered marker drops on the element. You type your note. You hit Export. You paste into Claude Code.

The pasted prompt already contains: the React component name, the source file (in dev mode), a CSS selector, a cropped screenshot, the page URL, the viewport, and your note. Claude Code reads it as a structured bug ticket. The next message back is the actual fix.

Install to first agent-ready prompt: under sixty seconds.

A real walkthrough

Say your dashboard has a stats card that's misaligned on mobile. The fix sequence used to look like this:

1. Open DevTools, screenshot the card
2. Inspect element, copy the class name
3. Switch to your editor, find the file
4. Switch back to Claude Code
5. Type a description that hopefully matches
6. Paste the screenshot
7. Mention the class name
8. Cross your fingers

With markagent, it looks like this:

1. Press Cmd+Shift+. to open the toolbar
2. Cmd+click the stats card
3. Type: "Off-center on mobile, should be centered with 12px top margin"
4. Capture the screenshot (element-cropped, automatic)
5. Hit Export
6. Paste into Claude Code

The export Claude Code sees includes the selector (.dashboard-stats-card), the component (<StatsCard>), the source path (src/components/StatsCard.tsx), the screenshot, your note, and the viewport (375x812). The agent goes straight to the right file, makes the right change, and shows you the diff. No clarifying round-trip.

What the export actually looks like

The export is markdown. That matters because Claude Code reads it natively — no parser, no plugin, no special integration. Here's a compressed shape:

## UI Feedback — Stats Card

**Page:** http://localhost:3000/dashboard
**Viewport:** 375 × 812
**Component:** <StatsCard>
**Source:** src/components/StatsCard.tsx
**Selector:** .dashboard-stats-card

### Note
Off-center on mobile, should be centered with 12px top margin

### Screenshot
[attached: stats-card-misaligned.png]

Claude Code parses this without prompting tricks. The same markdown reads cleanly as a Linear ticket. The same markdown reads cleanly as a Slack message to a human teammate. One file, two audiences.

Multi-step bugs and journey mode

Single-element feedback is the common case. The harder case is a flow bug — three clicks deep, only reproduces after you do steps in a specific order, and there's a state-management subtlety in the middle. Describing that in prose is where the agent definitely loses you.

For those, flip on journey mode. Click through the bug. Markagent silently records each click as a numbered step with its own screenshot. When you stop recording, you have a step-by-step reproduction Claude Code can follow without guessing.

The structured prompt that comes out includes every step, every screenshot, every selector — in order. Claude Code's debugging loop becomes deterministic instead of guess-and-check.

When this matters most

The workflow pays off the hardest in three places. Refactors of unfamiliar code, where you don't know which component owns what — markagent tells the agent the answer. Design QA on staging builds, where the designer or PM needs to file tickets engineers (or agents) can fix without follow-up. Multi-step bugs, where the reproduction is half the work.

If you're a solo developer iterating on your own UI, every saved clarifying round trip is a minute of focus reclaimed. If you're a team, the markdown export doubles as a human-readable bug report — which means the QA tester, the PM, and Claude Code are all looking at the same artifact.

A quick note on Claude Code design feedback hygiene

A few patterns that keep coming up across teams using this workflow:

Annotate the smallest element that's actually wrong. If a card looks off, mark the card — not the whole section. The narrower the selector, the less Claude Code has to guess about scope. The result is smaller, safer diffs.

When you're giving Claude Code visual context across multiple states (hover, focus, error, mobile breakpoint), do one annotation per state rather than one long paragraph. Each annotated webpage screenshot is a discrete data point the agent can reason about.

If a tweak depends on something off-screen — a parent flex container, a global CSS variable, a media query — say so in the note. The export captures the element, not its context lineage. One sentence about "this is inside a flex container with gap: 16" saves the agent a round trip.

Stop typing "the button on the left, no, the other one." Mark the spot. Ship the prompt to Agent.