arndvs Visual Feedback
If running interactively (human present), output "Read Visual Feedback skill." to acknowledge. If running with --dangerously-skip-permissions (AFK/unattended), skip acknowledgement and proceed directly.
Pipeline position: sits inside /do-work → replaces the "look at the UI" step that LLMs otherwise skip.
Why this exists
Backend feedback loops are fully textual — tests, types, lint. Frontend feedback loops are not. Without a browser, the LLM is flying blind: it can write code that passes typecheck and still produce a broken layout, a broken dark mode, or an animation that feels wrong. This skill closes that gap.
Setup assumptions
- VS Code browser is available (Simple Browser or a browser preview panel pointed at the dev server)
- Tavily MCP is connected for web search when you hit something unfamiliar
Workflow
1. Start the dev server
Before taking any screenshots, confirm the dev server is running and note the local URL (e.g. localhost:5173). If it isn't running, start it.
2. Open the VS Code browser
Open the Simple Browser pointed at the local URL. This is your visual ground truth for the session.
3. Implement a slice
Write the minimum code for one visual change — a component, a layout adjustment, a theme switch. Keep slices small so screenshots stay meaningful.
4. Screenshot and evaluate
Take a screenshot of the current state. Ask:
- Does the layout match the intent?
- Are there overflow, clipping, or alignment issues?
- Does it work at different viewport widths?
- If dark mode is relevant — does it render correctly under
prefers-color-scheme: dark?
To emulate dark mode without a toggle, inject via devtools:
// Force dark mode for screenshot
document.documentElement.classList.add('dark')
// or emulate media query via CDP if available
5. Iterate
If something looks wrong, fix it and screenshot again. Do not move on until the visual matches the intent. One slice, fully resolved, before the next.
6. Research with Tavily when stuck
If a CSS behaviour, browser quirk, or animation issue is unfamiliar, use Tavily to search before guessing:
tavily_search("css scroll snap momentum iOS Safari")
tavily_search("framer motion exit animation not triggering")
Prefer MDN, CSS-Tricks, and the relevant library's own docs. Do not iterate blindly on broken CSS — understand the mechanism first.
7. Validate the full page
Once a feature is complete, do a final sweep:
- Light mode
- Dark mode (if applicable)
- Mobile viewport (375px)
- Desktop viewport
- Any interactive states (hover, focus, active, disabled)
- Any loading/empty/error states
8. Hand back to do-work
Once the visual sweep is clean, return to the standard /do-work validate step (typecheck, tests) and commit.
Notes
- Screenshots are context-heavy. Take targeted screenshots — specific components or states — rather than full-page dumps unless you need the full layout.
- If the browser MCP starts consuming too much context, switch to taking screenshots only at decision points rather than after every change.
- The goal is the same ad hoc testing a human dev does — not exhaustive E2E coverage, just confirming the thing you just built actually works.