Theme Acceptance Criteria
Set the bar every theme has to clear before it ships to anyone.
What it adds
A release gate for light, dark, branded, and customer-supplied themes, covering contrast, first paint, tokens, and print.
What your agent is told to do
5
What your agent is told to do
5-
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.
-
4
State what the first paint must look like. The stored theme has to be resolved before anything renders, and a flash of the wrong theme is a failure of the gate, not a cosmetic quibble.
-
5
Do not duplicate the per-component bar set by Component Acceptance Criteria. That document owns whether a component behaves correctly; this one owns whether a set of theme values is safe to apply across every component at once.
Edge cases it handles
7
Edge cases it handles
7- Contrast must be checked in each interactive state and against each surface a component can sit on — a token that passes on the page background can fail on a card, a modal, or a coloured banner.
- Charts, overlays, and shipped image assets are the usual escapees: a chart series palette tuned for a light background turns unreadable on dark, and a logo baked as a dark PNG disappears entirely.
- First paint has to be tested with an empty cache and a slow connection, since a theme flash is invisible on a warm local reload and glaring for a real user.
- A customer-supplied or branded theme can arrive with missing tokens, malformed values, or a brand colour that fails contrast — validate it on entry, refuse or correct what is unusable, and never let a partial token set render as a half-applied theme.
- Print and forced-colours mode both override the theme in ways the app does not control, so each needs its own line: print on white regardless of the active theme, and forced colours without relying on colour alone to convey state.
- A theme change while the app is open must repaint everything, including portals, toasts, and any component holding a colour it resolved once at mount.
- The theme that follows the operating system preference must still honour an explicit user override, and the gate should check that the override wins.
Definition of done
9
Definition of done
9- Every theme is checked against the gate before release, including customer-supplied ones.
- Contrast is measured for text, icons, borders, and focus rings in every interactive state and on every surface.
- Charts, overlays, and fixed-colour assets are covered by explicit criteria rather than assumed to follow the theme.
- First paint on a cold cache shows the correct theme with no flash.
- Custom token sets are validated on entry and a partial set is refused rather than half-applied.
- Print output and forced-colours mode each have their own stated pass conditions.
- Per-component behaviour is left to Component Acceptance Criteria and not restated here.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Component Acceptance Criteria
Component Acceptance Criteria
Give every shared component a written bar it must clear before anyone uses it.
What it does
A per-component specification of required behaviour, keyboard handling, responsive limits, and theming, written so each line can be checked.
How it works
- 1 Inventory the components other parts of the app depend on — buttons, inputs, selects, dialogs, tables, menus, toasts — and write criteria for those first rather than for every file in the tree.
- 2 Write each criterion as a statement of an observable end state, not a task. A line that says the component supports keyboard use is untestable; a line that says Escape closes it and returns focus to the trigger is not.
- 3 Cover both the controlled and the uncontrolled shape of every component that has one, including what happens when a parent changes the value underneath an interaction already in progress.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/component-acceptance-criteria
Visual Regression Testing
Visual Regression Testing
Catch unintended visual changes before they reach users, not after.
What it does
An automated comparison of rendered screenshots against approved baselines, run on every change.
How it works
- 1 Identify the surfaces where a silent visual change would actually hurt — the shared components, the pricing table, the checkout, the dashboard — and capture those rather than screenshotting every route in the app.
- 2 Freeze everything that varies between runs before capturing: load fonts and wait for them, fix the clock to a known instant, disable animations and transitions, and render from seeded fixtures rather than live data.
- 3 Capture each surface in every theme and at every viewport the app claims to support, and label each capture with that combination so a diff says exactly which one moved.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/visual-regression-testing
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
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.