Reactions
Let people acknowledge something without writing another comment.
What it adds
Lightweight reactions on content, with accurate counts, who-reacted detail, and text labels.
What your agent is told to do
7
What your agent is told to do
7-
1
Store one row per user, per reaction type, per item, with a uniqueness constraint. That constraint is what makes a double-tap harmless.
-
2
Make the toggle idempotent: reacting twice leaves one reaction, un-reacting twice leaves none. Never derive state from a count you incremented.
-
3
Update the count optimistically for the person who clicked, then reconcile with the server response and roll back visibly on failure.
-
4
Give every reaction a text label and expose who reacted. Meaning carried only by an emoji glyph is unreadable to screen readers and ambiguous across cultures.
-
5
Check permission on the item before recording a reaction — visibility of a count is not the same as the right to add to it.
-
6
Do NOT let the reaction set be arbitrary user input. A fixed, curated set keeps moderation, rendering, and analytics tractable.
-
7
Do NOT send a notification for every single reaction; batch them, or the feature becomes a reason to mute the product.
Edge cases it handles
7
Edge cases it handles
7- Concurrent reactions from many users must not lose counts — aggregate from the rows or use an atomic counter, never a read-then-write.
- When a user loses access to an item, or is deleted or suspended, their reactions must stop being attributed to them and the counts must reflect it.
- Deleting the item must remove its reactions rather than leaving orphans that skew totals.
- An item with many reactors needs a truncated list with a real total, not a wall of avatars.
- Emoji render differently per platform and some render as boxes — the label, not the glyph, must carry the meaning.
- Reacting to your own content is allowed or not, but the rule must be the same everywhere it appears.
- Rapid toggling must be rate-limited, and the UI must never show a count below zero.
Definition of done
9
Definition of done
9- A user can hold at most one reaction of each type on an item, enforced by a database constraint.
- Toggling is idempotent and counts stay correct under concurrent use.
- Every reaction has a text label and the reactor list is available.
- Reactions require permission on the underlying item.
- Losing access, deletion, and suspension all correct the counts.
- Optimistic updates roll back visibly when the request fails.
- Notifications for reactions are batched rather than sent one by one.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Direct Messages
Direct Messages
Let two users hold a private conversation inside the app instead of leaving to email.
What it does
One-to-one private threads with message history, per-conversation unread counts, and blocking.
How it works
- 1 Build the conversation list, the thread view, and the unread badge. Keep the first version to one-to-one threads only and defer group conversations, reactions, threading, and file attachments rather than shipping all of them half-finished.
- 2 Reuse the app's existing Read and Unread State and Notification Center rather than inventing a second unread mechanism and a second alert path. A message notification should sit alongside every other notification the user gets.
- 3 Reuse the composer, mention handling, and rendering rules from Comments and Mentions instead of writing a second message editor with subtly different escaping.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/direct-messages
Voice Notes
Voice Notes
Say it instead of typing it, and attach the recording where the conversation is.
What it does
In-app recording of short audio notes attached to a record, comment, or message.
How it works
- 1 Add recording to the places where people already leave text, most likely alongside Comments and Mentions, so a voice note is another kind of comment rather than a separate feed nobody checks.
- 2 Store the recording through the app's existing file upload path so a voice note inherits the same retention and access rules as any other attachment on the record, and disappears with the record when it is deleted.
- 3 Show a live duration and a simple level meter while recording, and let the user review and discard before it is sent. Nobody should be committed to a recording the instant they stop.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/voice-notes
Assign Ownership
Assign Ownership
Make it obvious who is responsible for each record.
What it does
An assignee on records, with a picker, notifications on change, and a history of who owned what.
How it works
- 1 Add a nullable assignee to the relevant records. Unassigned is a real, valid state — do not force a default owner just to avoid the null.
- 2 Restrict the picker to users who can actually access the item, and validate that server-side as well as filtering the list.
- 3 Notify the new assignee when they are assigned by someone else, and record every change with the actor and timestamp.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/assign-ownership
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.