Async Boundary Component
Give every asynchronous region the same set of states instead of hand-rolling each one.
What it adds
A shared wrapper that renders pending, error, empty, refreshing, and ready for any region backed by a request.
What your agent is told to do
5
What your agent is told to do
5-
1
Find the regions of the app that depend on a request — lists, detail panels, widgets, charts, dropdown options — and route each one through the shared boundary rather than a local set of flags.
-
2
Model the states explicitly and exhaustively so that pending, error, empty, refreshing, and ready are the only possibilities, and the caller cannot render a sixth thing by accident.
-
3
Distinguish the first load, which has nothing to show, from a refetch, which already has content. The first deserves a skeleton shaped like the eventual result; the second deserves a quiet indicator over what is already on screen.
-
4
Make the empty state a first-class slot the caller fills, because an empty search result, an empty inbox, and a filtered-to-nothing table say different things and need different next actions.
-
5
The mechanics of the state graph itself — legal transitions, cancellation, timeouts — belong to UI State Machine Pattern; this boundary owns what those states look like and where they are placed. Take the machine from there rather than defining a second one here.
Edge cases it handles
7
Edge cases it handles
7- A background refresh must keep the previous content visible. Dropping back to a skeleton because a poll fired makes a stable screen flash for no reason, and it throws away the user's scroll position.
- The initial load and a later refetch are not the same event and must not share one flag. Collapsing them is what produces a full-page spinner on every keystroke of a filter.
- Every error state needs a retry that re-runs only that region's request, and every in-flight request needs to be cancellable when the user navigates away or changes the parameters underneath it.
- Boundaries nest, and a parent skeleton wrapped around three child skeletons reads as a broken page. Decide which level owns the visible pending treatment and have the inner ones render nothing while the outer one is pending.
- A request that resolves in twenty milliseconds should not flash a loader at all — hold the pending treatment behind a short delay, and once it is shown, keep it long enough not to strobe.
- A response that arrives after its parameters have changed must be discarded, or a slow earlier request will overwrite the results of a newer one.
- The transition into the ready state must not shift the page. Reserve the space the content will occupy so the skeleton and the result are the same size.
Definition of done
9
Definition of done
9- Every request-backed region in the app renders through the shared boundary.
- Pending, error, empty, refreshing, and ready are the complete and only set of rendered states.
- A background refresh leaves previous content and scroll position in place.
- Errors offer a retry scoped to that region, and in-flight requests are cancelled on navigation or parameter change.
- Nested boundaries produce a single pending treatment rather than stacked skeletons.
- Fast responses complete without any loader appearing, and no loader flashes for less than its minimum duration.
- The state machine is taken from UI State Machine Pattern rather than reimplemented.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
AI Cost Budgets
AI Cost Budgets
Cap what AI features are allowed to spend before the bill arrives.
What it does
Monetary spending limits on AI work, scoped by workspace, feature, and time period, enforced before a run starts.
How it works
- 1 Find every place the app calls a model and route all of them through one accounting point that records estimated and actual spend against a scope. A budget that only covers the chat feature is not a budget.
- 2 Estimate the cost of a run from the size of its input before dispatching it, and refuse anything that would exceed the remaining budget on its own.
- 3 Reserve the estimate against the budget when the run starts, then reconcile to the real usage figures when it finishes, releasing whatever was over-reserved.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ai-cost-budgets
Multi-Model Routing
Multi-Model Routing
Send each AI request to the right model using rules you can read and test.
What it does
A deterministic routing layer that picks a model per request from task type, context size, latency budget, and data sensitivity.
How it works
- 1 Express routing as explicit, ordered rules over inputs the app can measure: task type, estimated context size, latency budget, and the sensitivity classification of the data involved. A rule set that can be read line by line can be reviewed and tested.
- 2 Make routing deterministic. The same inputs must always produce the same route, so a bad output can be reproduced and a rule change can be evaluated. Randomised or load-based selection turns every incident into guesswork.
- 3 Classify data before routing and refuse to route restricted content to any destination not approved for it. This check is a hard block, not a preference, and it must run before the request is assembled.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/multi-model-routing
SEO Setup
SEO Setup
Make your app findable — titles, meta, Open Graph, sitemap, robots.
What it does
The baseline SEO and social-preview setup every public app should have, and most skip.
How it works
- 1 Give every public page a unique, descriptive title and meta description. Find the app's layout and add a mechanism for each page to set them.
- 2 Add Open Graph and Twitter Card tags so shared links render a preview instead of a bare URL.
- 3 Generate a sitemap.xml covering every public, indexable page, and a robots.txt pointing at it.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/seo-setup
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.