Screenshot Diff Baselines
Give approved screenshots an owner, a review step, and a rule for updating them.
What it adds
A stored set of approved reference images with recorded context, a review flow, and rules for updating and retiring them.
What your agent is told to do
5
What your agent is told to do
5-
1
Store each approved image alongside the exact conditions it was captured under — theme, viewport, pointer type, locale, and the component state — so a reviewer can tell what they are looking at without opening the test.
-
2
Require a diff to be reviewed image by image. A reviewer who accepts a change must have seen that specific image, and the record must say who approved it and when.
-
3
Version baselines by platform or browser only where the rendering genuinely differs, because a per-platform copy of every image multiplies the review burden without catching anything new.
-
4
Delete a baseline when the surface it covers is removed, and report images that no test has requested in recent runs so dead references do not accumulate.
-
5
Capture, stabilisation, and comparison belong to Visual Regression Testing; this brief owns where approved images live, who signs them off, and when they expire. Do not add capture logic here.
Edge cases it handles
7
Edge cases it handles
7- A single approve-all control lets an unrelated regression ride in behind an intentional redesign, which is precisely how a suite stops finding real bugs — accept per image, or require an explicit reason for a bulk accept.
- An image with no recorded theme, viewport, or state is unreviewable, because the reviewer cannot tell whether the difference is a bug or a different configuration entirely.
- Copying every baseline for every operating system triples storage and review time for surfaces that render identically, so per-platform variants must be justified case by case.
- Baselines for deleted components linger and quietly rot, so removal has to be part of the same change that removes the component rather than a periodic cleanup that never happens.
- Approved images stored in the repository inflate its size over time; decide early whether they live in version control or an external store, and make the retrieval work for a fresh checkout.
- Two branches approving different baselines for the same surface will conflict on merge, and the resolution must be a fresh review rather than picking whichever side is newer.
- An approval made against a stale baseline must be invalidated if the underlying test conditions change, or the record claims a sign-off that never happened.
Definition of done
8
Definition of done
8- Every stored baseline records its theme, viewport, and component state.
- Diffs are approved individually, and each approval records an author and a timestamp.
- Platform-specific baseline variants exist only where rendering genuinely differs, and each is justified.
- Baselines for removed surfaces are deleted, and unreferenced images are reported.
- A fresh checkout can retrieve all current baselines without manual steps.
- Conflicting approvals across branches require a new review rather than resolving automatically.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
UX Edge-Case Checklist
UX Edge-Case Checklist
Make every UI feature state what it does when things go wrong before it counts as done.
What it does
A required list of non-happy-path behaviours — failure, empty, loading, offline, permission, mobile, and accessibility — answered per feature.
How it works
- 1 Attach the checklist to the point where work is proposed and to the point where it is reviewed, so the answers exist before the feature is built rather than being reconstructed afterwards.
- 2 Require a concrete answer for each category: what the empty state says and what it offers, what appears while data is loading, what the user sees when the request fails, and what a user without permission gets instead.
- 3 Make each answer an outcome someone else could verify. A feature that says errors are handled has not answered; one that says a failed save keeps the form open with the values intact and a retry has.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ux-edge-case-checklist
Interaction Test Harness
Interaction Test Harness
Test the app the way a person uses it, through real clicks, keys, and focus.
What it does
A test setup that drives menus, dialogs, forms, and navigation through genuine user interactions and asserts on what the user can see.
How it works
- 1 Find elements the way a user finds them — by their visible label, their role, and their accessible name — rather than by class names or internal test hooks, so a test breaks when the interface becomes unusable and not when a wrapper is renamed.
- 2 Drive each interaction through both pointer and keyboard where both are supported, and assert on where focus ends up as well as on what the screen shows.
- 3 Assert on the visible outcome and wait for it to appear, rather than sleeping for a fixed interval and hoping. A timer-based wait is either slow on every run or flaky on a loaded machine.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/interaction-test-harness
Theme Acceptance Criteria
Theme Acceptance Criteria
Set the bar every theme has to clear before it ships to anyone.
What it does
A release gate for light, dark, branded, and customer-supplied themes, covering contrast, first paint, tokens, and print.
How it works
- 1 Write the criteria against the theme layer, not against individual screens. The question is whether a set of token values is fit to ship, and the answer should not require walking every page by hand.
- 2 Require measured contrast for text, icons, borders, focus rings, and disabled content in every interactive state — resting, hover, focus, active, and selected — because a palette that passes at rest often fails on hover.
- 3 Cover the surfaces that sit outside the component library: chart series and their gridlines, map and image overlays, embedded documents, illustrations, and any asset shipped as a fixed-colour file that will not follow the theme.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/theme-acceptance-criteria
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.