A reusable UI review prompt for coding agents
Use this after you have collected visual feedback. It keeps the agent focused on the reviewer’s intent, the repository’s rules, and a result a person can inspect.
This template is tool-agnostic. Paste it above a Markdown or JSON feedback export, or use it after a compatible coding agent has fetched the same feedback through MCP. It deliberately leaves the final visual decision with you.
Copy-paste template
Implement the attached UI review feedback in this repository.
Before changing code:
1. Read the repository instructions and relevant tests.
2. Start or inspect the existing local app safely.
3. Read every feedback item and its captured context: route,
viewport, selected element, screenshot, annotations, browser
details, and nearby errors when present.
4. Treat selectors and DOM metadata as evidence, not permission
to guess where the source lives. Find the owning component.
5. Separate the reviewer’s requested outcome from your proposed
implementation. Ask only if the intent is materially ambiguous.
While implementing:
6. Make the smallest coherent change that satisfies the feedback.
7. Preserve behavior, accessibility, responsive layouts, design
tokens, and unrelated copy unless the feedback says otherwise.
8. Do not silently “improve” areas outside the reviewed scope.
Before reporting completion:
9. Run the repository’s required checks and relevant focused tests.
10. Inspect the changed UI at the reported route and viewport,
plus nearby breakpoints and interaction states.
11. Report what changed, what you tested, any feedback you could
not satisfy, and the review link or local route I should inspect.
12. Do not mark the visual feedback resolved on my behalf. I will
review the running UI and decide.What to attach
- The deterministic Shiproom Markdown or JSON export, or the feedback references the agent should fetch through MCP
- The route and application state where the feedback was recorded
- Any non-obvious product or brand constraint the repository does not already document
- The command or workflow the repository requires for tests and visual inspection
Why this prompt does not say “make it pixel perfect”
Pixel-perfect is not an acceptance criterion unless you provide a fixed reference, viewport, rendering environment, and objective comparison method. For ordinary product review, describe the hierarchy, spacing relationship, behavior, or state that should change and let the agent prove it without inventing a false precision.
Keep two prompts separate
The template above is for implementing feedback. Shiproom’s setup prompt is different: it asks a coding agent to start the local app, run Shiproom, wait for the private reviewer link, and return that link without changing code while the review is open. Keeping capture and implementation separate makes the human decision point explicit.