Approval Requests
Ask a specific person to approve or reject something, and record what they decided.
What it adds
A reusable request-and-decide flow attached to any record, with an auditable decision history.
What your agent is told to do
5
What your agent is told to do
5-
1
Model a request as its own record linked to the item under review, with a requester, one or more reviewers, a state, and a decision history.
-
2
Define and enforce who may request, approve, reject, cancel, and reassign. Approving your own request should be blocked unless an admin has deliberately allowed it.
-
3
Write decisions as append-only entries with an author, a timestamp, and an optional comment. Never edit or delete a recorded decision.
-
4
Decide up front whether editing the underlying item invalidates an in-flight approval, then enforce it — silently approving content that has since changed is the failure this feature exists to prevent.
-
5
Do NOT build a general workflow engine with configurable stages and branching. One request, one decision, reassignable. Anything more is a different product.
Edge cases it handles
6
Edge cases it handles
6- Two reviewers deciding at the same moment must not produce two contradictory outcomes — the first decision wins and the second is told so.
- A reviewer who loses access to the item must be removed from the request rather than left holding a decision they cannot make.
- Cancelling a request must be distinguishable from rejecting it in the history.
- Requests with no activity need an expiry or a nudge; a queue full of forever-pending items is worse than no queue.
- If the item is deleted or archived, resolve open requests instead of leaving orphans pointing at nothing.
- Reassignment must keep the original requester and the prior comments visible, not reset the trail.
Definition of done
8
Definition of done
8- A request can be raised on an item and routed to a named reviewer.
- Approve, reject, cancel, and reassign are permission-checked server-side.
- Decisions are immutable and carry author, timestamp, and comment.
- Concurrent decisions cannot both land.
- Changing the item applies the documented invalidation rule.
- Stale requests expire or escalate on a defined schedule.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
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
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
Internal Notes
Internal Notes
Give staff a place to write things the customer must never see.
What it does
Notes attached to a record that are readable only by internal roles, and that never appear in any export, feed, or API response.
How it works
- 1 Model an internal note as a distinct visibility state on the server, not a flag the client filters on. Every read path — record view, search, digest emails, exports, webhooks, API serializers — must exclude internal notes for anyone without the internal role.
- 2 Give internal notes a visual treatment that cannot be confused with a public comment: different surface, a persistent label, and a warning that survives collapse or truncation. If a user has to remember which box is which, this feature has failed.
- 3 Decide explicitly what an impersonating admin or a support session sees, and state the rule in the UI. Support staff reading internal notes is usually fine; a support session rendering them inside a screen the customer is watching is not.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/internal-notes
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.