Feedback Widget
Let anyone report a bug or send a comment from the page they are looking at.
What it adds
An always-available launcher that opens a short feedback form and submits it with page context attached.
What your agent is told to do
5
What your agent is told to do
5-
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.
-
4
Route submissions into the app's existing support, ticketing, or moderation destination rather than creating a second inbox nobody watches.
-
5
Do not require a category, a severity, or a rating before someone can type. Every required field ahead of the message box loses reports.
Edge cases it handles
8
Edge cases it handles
8- Capture the current page and session context automatically at the moment the widget opens, not at submit, or a redirect during typing will file the report against the wrong screen.
- If submission fails, keep the typed draft in place with the error shown above it and let the user retry. Losing a bug report to a network blip is the one failure that guarantees it is never re-filed.
- Strip sensitive values out of the captured context before it leaves the browser: password fields, card numbers, tokens, and any field the app marks as private.
- The launcher must not sit on top of a chat bubble, a cookie banner, or a scroll-to-top control. Detect other fixed corner elements and offset, or place it where nothing else lives.
- Confirm receipt with a visible reference the user can quote, so the same issue is not sent four times while they wait.
- Anonymous feedback from public pages needs rate limiting and spam handling, or the inbox fills with automated submissions.
- The form must be reachable and dismissable by keyboard, with focus trapped while open and returned to the launcher on close.
- Very long pasted logs need a size limit that truncates with a note rather than rejecting the whole submission.
Definition of done
9
Definition of done
9- The widget is reachable from every page of the app without navigating away.
- Page URL, app version, account, and recent client errors are attached automatically and shown to the user before sending.
- Sensitive field values are excluded from the captured context.
- A failed submission preserves the draft and offers a retry.
- Successful submissions return a visible reference and land in the app's existing support destination.
- Anonymous submissions are rate limited.
- The launcher does not overlap other fixed corner elements at any viewport width.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Booking Page
Booking Page
A shareable page where someone picks an open time and confirms it in a few clicks.
What it does
A public scheduling page listing open slots, taking a booking, and confirming it to both sides.
How it works
- 1 Build the visitor path first: pick a date, see open times in their own zone, fill a short form, confirm, and receive an email with the details and a cancellation link. That is the minimum coherent version.
- 2 Derive open slots from the owner's availability rules and existing bookings on the server at request time. Do not trust a slot list the browser has been holding since page load.
- 3 Reuse the app's existing Time Zone-Aware Scheduling for conversion and storage, store every time as an absolute instant, and display it converted to the visitor's detected zone with the zone named on screen.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/booking-page
Date and Time Display Component
Date and Time Display Component
Render every date and time through one component so none of them are ambiguous.
What it does
A single shared way of displaying dates and times, covering absolute format, time zone, and optional relative phrasing.
How it works
- 1 Find every place the app renders a date or a time — tables, activity feeds, audit logs, exports, emails, tooltips — and route them all through one display path rather than formatting at each call site.
- 2 Never render an all-numeric date whose day and month could be swapped. Spell or abbreviate the month, or use an unambiguous ordering consistently, because a reader has no way to tell 04/07 from 07/04.
- 3 State the time zone whenever the value is a specific moment rather than a calendar day, and be explicit about whose zone it is — the viewer's, the record's, or the account's — rather than leaving it implied.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/date-and-time-display-component
Audio Chapter Markers
Audio Chapter Markers
Break a long recording into named chapters listeners can see and jump between.
What it does
Named, timestamped chapters on long audio or video, shown in a list and on the scrubber, each addressable by its own link.
How it works
- 1 Store chapters as an ordered list of start times and titles attached to the existing media record, and render them both as a list beside the player and as markers on the scrubber.
- 2 Let an author add, rename, reorder by moving start times, and delete chapters in the player itself, with the current playback position offered as the default start time for a new chapter.
- 3 If chapters are generated automatically, treat the generated set as a first draft. The author's edits must win and must survive the next generation run.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/audio-chapter-markers
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.