You ask for the Subscribe button to be blue. The agent comes back with: "Should I change just this button, or the shared button style used across the app?" It feels like a silly question. It isn't. It's the agent being careful, and you can answer it before it's asked.
Why it happens
Apps built with AI tools usually reuse pieces. One Button component draws every button. One theme file sets the main color, the corner radius and the font sizes. That's good: change it once, it changes everywhere.
But it means a small visual fix has two possible homes:
- Local: change only this button, on this page. Nothing else moves.
- Global: change the shared component or theme. Every button like it changes too.
From one screenshot the agent can't tell which you want. Both are reasonable. If it picks wrong, you either still have the bug on five other pages, or you now have a new bug on pages you didn't look at. So a careful agent asks.
How to answer it up front
- Look at one or two other pages first. Does the same problem show up there? If yes, it's likely global. If the other places look right, it's local.
- Say it in one line. Add a Scope line to your report: "Only on the pricing page" or "Every primary button in the app".
- Point at a good example. "Should match the Start trial button" tells the agent which style is correct, and often answers the question by itself.
- Name the places you checked. "Also wrong on /settings and /checkout" helps the agent find the shared piece.
- Say what must not change. "Don't change the header buttons" protects the places you like as they are.
Phrases you can copy
Scope: only this spot. Don't change shared styles.
Scope: everywhere. Fix the shared component, not just this page.
Scope: all buttons like this one, but not the ones in the header.
Should match: the cards on the home page.After the fix
Open two or three other pages and look. For style changes, a quick look at phone width helps too. The free responsive checker shows a page at phone, tablet and desktop widths side by side. If a color changed, check it's still readable with the color contrast checker.
What we saw when we tested this
We built a test for exactly this question: 8 planted bugs in Excalidraw, a real open source app, where 4 needed a shared fix and 4 needed a local one. With a screenshot and one sentence, Claude Code picked the right scope every time and never asked. Excalidraw is well organized, with one theme file and clear names, which made it easy.
So you won't always get the question. It comes up more in messy codebases, where the same style is copied in several places, or when your note is vague. Writing the scope line costs five seconds and removes the guess either way.
Where Darnly fits
Darnly is a free Chrome extension for capturing bugs. It can't decide the scope for you. What it does is give you one place to say it: press Option+Shift+B (Windows is coming soon), click the broken part, and type something like "should be blue like Start trial, everywhere". Darnly's report also includes the element's selector, classes and styles, which are the clues an agent uses to find a shared component. And the instructions it gives your agent say: if the note is vague, ask one short question first.
Got a picture of how it should look? Paste it into the note box too. It's saved next to the report, which settles "which style is right" without words.