Linear Issue Creation
Create a Linear issue from feedback or support work in the right team and project.
What it adds
A server-side path from an in-app record to a Linear issue, with team, project, label, and state mapping and a link back to the source.
What your agent is told to do
5
What your agent is told to do
5-
1
Let an administrator map the destination team, project, initial workflow state, labels, and default assignee, choosing from what the connected workspace exposes, and re-resolve those selections at creation time rather than trusting identifiers cached at setup.
-
2
Compose the issue on the server from the originating record and include a durable deep link back into the app, so anyone reading the issue can reach the customer, ticket, or error it came from.
-
3
Key each submission by the originating record and check for an existing issue reference before creating, so a retried job or a request that timed out after succeeding does not produce a duplicate.
-
4
Decide deliberately what customer context leaves the app. Include what a triager needs and exclude anything the workspace's members are not entitled to see; where a report may contain personal data, summarise it in the issue and keep the full detail behind the app link.
-
5
GitHub Issue Creation, GitLab Issue Creation, Jira Ticket Creation, Trello Card Creation, and Asana Task Creation are siblings. The shared half is capturing, redacting, deduplicating, and storing the external reference; this brief owns only Linear's team and workflow mapping and its error translation.
Edge cases it handles
8
Edge cases it handles
8- Teams, projects, cycles, labels, workflow states, and assignees are all workspace-specific and can be renamed or removed. Resolve each at creation time, drop an attribute that no longer exists, still create the issue, and record what was dropped.
- A retry must never produce a second issue. Persist the created reference before acknowledging the job, and check it on every attempt, because a timeout usually means the issue was created and the response was lost.
- A removed team or a workflow state that no longer exists must not silently route issues into the wrong place. Fall back to the team's default state and raise a configuration warning to an administrator.
- The link back to the originating app record must remain valid after the record is renamed or moved, so link by stable identifier rather than by a slug or a title.
- Everyone in the destination workspace can read the issue. Private customer context, support transcripts, and personal data must not be pasted in wholesale simply because it was convenient to include.
- The workspace credential will expire or be revoked. Distinguish authentication failures from transient ones, hold the submissions in the queue, and prompt an administrator to reconnect.
- Rate limits and request throttling need exponential backoff with jitter and a bounded retry count, so a burst of reports does not lock the connection out.
- If any status synchronisation back into the app is added, treat incoming events as at-least-once and possibly out of order: dedupe by event identifier and ignore anything older than the state already stored.
Definition of done
9
Definition of done
9- An in-app record can be sent to Linear as an issue in the configured team and project.
- Team, project, labels, state, and assignee are resolved at creation time and missing values degrade instead of failing.
- Retries and duplicate submissions reuse the existing issue.
- Every created issue links back to the originating record by a stable identifier.
- Private customer detail stays in the app and is referenced by link rather than copied into the issue.
- Authentication failures queue submissions and alert an administrator instead of discarding them.
- Rate limiting is handled with bounded backoff and no lost reports.
- 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.