Permission-Aware Action
Decide once how a control behaves when the user is not allowed to use it.
What it adds
A shared wrapper for buttons, menu items, and links that resolves visibility, disabled state, and the reason a user cannot proceed.
What your agent is told to do
5
What your agent is told to do
5-
1
Inventory every action in the app that any role can be denied, and give each one a named capability rather than scattering role comparisons through the components that render it.
-
2
Pick one of three treatments per action and record the choice: hide it, show it disabled with a reason, or show it enabled and let the attempt fail into an upgrade or request-access path. Defaulting everything to hidden makes the product look smaller than it is.
-
3
Whenever an action is disabled, say why in words the user can act on — the role that is required, the prerequisite that is missing, the plan limit that has been reached — and where possible offer the next step.
-
4
Treat prerequisites and permissions through the same wrapper. A save blocked by an incomplete profile and a save blocked by a viewer role should not be two unrelated mechanisms.
-
5
Do not treat the client-side check as enforcement. The server must reject the request independently, and the wrapper exists only to spare the user a pointless attempt.
Edge cases it handles
7
Edge cases it handles
7- Every capability the interface consults must be enforced again on the server for the same request. A hidden button is a courtesy, not a control, and anyone can call the endpoint directly.
- Hiding, disabling, and explaining are three different decisions with three different costs, and each action needs a deliberate one. Hiding teaches the user nothing; disabling without a reason is worse than hiding; explaining an action they will never be granted is noise.
- Some denials must not disclose that the thing exists. Telling a user they lack permission on a specific record confirms the record is real, so for those cases present the same not-found response an unrelated identifier would produce.
- Roles, seats, and workspace membership change while a session is open. The wrapper must re-evaluate on those changes rather than holding whatever was true at first render.
- A disabled control must still be reachable by keyboard and its reason must be announced, because a tooltip that only appears on hover is invisible to a screen reader and to a touch user.
- Actions rendered inside a bulk selection need a defined behaviour when the user may act on some of the chosen records and not others — act on the permitted subset and say so, or refuse the whole batch, but not silently drop rows.
- The reason text must not leak internal policy names, permission strings, or the identity of whoever holds the missing role.
Definition of done
9
Definition of done
9- Every deniable action in the app is declared as a named capability and rendered through the shared wrapper.
- Each action has a recorded, deliberate treatment: hidden, disabled with a reason, or attemptable.
- The server rejects every denied action independently of the interface.
- Denials that would confirm the existence of a private record are indistinguishable from not-found.
- A role or workspace change updates the affected controls within the same session, without a reload.
- Disabled controls are keyboard reachable and their reasons are announced to assistive technology.
- No reason string exposes an internal policy or permission identifier.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Feedback Widget
Feedback Widget
Let anyone report a bug or send a comment from the page they are looking at.
What it does
An always-available launcher that opens a short feedback form and submits it with page context attached.
How it works
- 1 Put a single persistent launcher in one corner of the app and open a compact form in place. Do not route the user to a separate feedback page and lose the context they were about to describe.
- 2 Attach the current URL, the app version, the viewport size, the signed-in account, and a short trail of recent client errors automatically, so the reporter does not have to describe where they were.
- 3 Show the captured context to the user before they send it, in a collapsible section, and let them remove it. Silent collection of screen state is a trust problem.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/feedback-widget
Interactive Transcript
Interactive Transcript
Put the transcript next to the player so clicking any line jumps playback to that moment.
What it does
A time-aligned transcript panel beside the audio or video player, with click-to-seek, a moving highlight, and in-transcript search.
How it works
- 1 Render the transcript from the timestamps the app already stores. If Voice Transcription exists, extend its output and its data model rather than producing a second transcript with its own timings.
- 2 Make every line a real seek target: clicking or pressing enter on a line moves playback to that time and keeps focus where the user left it.
- 3 Highlight the line currently being spoken and keep it in view as playback advances, using the player's own time updates rather than a separate timer.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/interactive-transcript
Relative Time Component
Relative Time Component
Show times as ages people can read, without losing the exact moment underneath.
What it does
One shared timestamp element that renders an age in words and carries the precise local date with it.
How it works
- 1 Find every place the app prints a date or a time — activity feeds, comment headers, audit rows, table cells, tooltips — and route them all through one component so the wording is identical everywhere.
- 2 Render from a machine-readable instant supplied by the server in a single unambiguous format, and do the conversion to the viewer's zone at display time rather than storing a formatted string.
- 3 Refresh the visible text on a schedule that matches its own granularity: something a few seconds old updates often, something two days old does not need to update at all.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/relative-time-component
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.