Component Acceptance Criteria
Give every shared component a written bar it must clear before anyone uses it.
What it adds
A per-component specification of required behaviour, keyboard handling, responsive limits, and theming, written so each line can be checked.
What your agent is told to do
5
What your agent is told to do
5-
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.
-
4
Enumerate the variants and sizes each component claims to support, and state which combinations are unsupported, so an invalid pairing fails loudly instead of rendering something half-broken.
-
5
Do not write the criteria as a generic checklist copied to every component. A shared list gets ticked without reading; each component's document should name its own states, its own keyboard contract, and its own failure modes.
Edge cases it handles
7
Edge cases it handles
7- A component used both controlled and uncontrolled behaves differently in each mode, and the difference is where the bugs live — the criteria must state what happens when the parent supplies a value, when it does not, and when it starts supplying one mid-life.
- Keyboard behaviour has to be written out key by key: which key moves focus, which commits, which cancels, whether arrow keys wrap at the ends, and where focus lands when the component closes or unmounts.
- Every declared variant and size needs coverage, and so do the combinations nobody intends — a destructive ghost button, a loading disabled input, an icon-only control with no accessible name — each should have a stated outcome rather than being left undefined.
- Stress content belongs in the criteria: a forty-word label, a single unbroken string with no spaces, right-to-left text, and a translated string two or three times longer than the English one all have to be handled without the layout collapsing.
- Criteria written once and never revisited rot quietly. Tie the document to the component so a change to the component's props or states is not considered done until the criteria are updated.
- Reduced motion, forced colours, and a doubled root font size are part of the component's contract, not separate concerns, and each should have at least one line saying what stays usable.
- A component with an asynchronous state needs a criterion for the slow case and one for the failed case, not only for the resolved one.
Definition of done
9
Definition of done
9- Every shared component has its own criteria document rather than a shared generic list.
- Each criterion states an observable end state that can be checked by inspection.
- Controlled and uncontrolled use are both specified, including a parent changing the value mid-interaction.
- The full keyboard contract is written key by key, including where focus lands on close.
- Supported variant and size combinations are enumerated and unsupported ones are named.
- Long, unbroken, translated, and right-to-left content is covered by explicit criteria.
- Changing a component's props or states without updating its criteria is treated as incomplete work.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
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
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
Design QA Checklist
Design QA Checklist
Give interface work a consistent review before it merges.
What it does
A short review pass over hierarchy, spacing, states, copy, responsiveness, and accessibility, applied to every change that touches the interface.
How it works
- 1 Write the checklist as a small number of concrete questions a reviewer can answer by looking at the running change, not as a list of principles nobody can verify.
- 2 Require every state to be shown, not described: loading, empty, error, partial, permission-denied, and the state with far more content than expected. A review that only sees the populated happy path approves half a feature.
- 3 Require a keyboard pass and a zoom pass on every change: tab through the new interface without touching the pointer, and view it at 200 per cent zoom with increased text size.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/design-qa-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.