Triage Jotform bug reports into Linear tickets and Slack alerts

PromptCreate

Build me an agent workflow that triages incoming bug reports and feature requests from my Jotform intake form and files them as Linear issues with a Slack alert. Trigger on a Jotform outgoing webhook so it runs the moment a submission lands.

At the start of each run, use Jotform's Get Form Questions once so the agent knows how to map the form's field IDs to human-meaningful labels like title, description, steps to reproduce, screenshots, console logs, and reporter email. Then use Jotform's Get Single Submission to pull the full submission that was just posted.

Read the submission and decide two things. First, is this a bug or a feature request. Second, if it's a bug, what severity: P0 for a production outage or data loss, P1 for a broken flow with no reasonable workaround, P2 for an annoyance that has a workaround, and P3 for a nice to have. Infer the product area from the description and any attachments: frontend, backend, mobile, or integrations. Feature requests should default to P3 unless the reporter argues for something higher.

Before filing, use Linear's Search Issues to look for an already open issue that matches the same problem. If a close match exists and the new report is P2 or P3, drop it and stop. If it's P0 or P1, still file the new issue but note the possible duplicate at the top of the description.

Otherwise, use Linear's Create Issue in the team that owns the inferred product area (I'll map area to team in the config). Set the priority to match the severity (Urgent for P0, High for P1, Normal for P2, Low for P3). Give it a clean, specific title that summarizes the issue in under 80 characters. In the description, include a short summary paragraph the agent wrote, a blockquote of the reporter's original words, a section for steps to reproduce and expected vs actual behavior if present, and links to any screenshots or console logs. Add labels for the severity, the area, and a 'bug' or 'feature-request' tag.

After the issue is filed, use Slack Bot's Send a Message to post a summary card in the #bugs channel. The card should include the severity, product area, one-sentence summary, reporter name, and a link to the Linear issue. For P0 or P1, @mention the on-call engineer user group so the message can't be missed. For P2 or P3, no mention.

Finally, if the submission captured a reporter email address and the issue is P0 or P1, use Gmail's Send a Message to reply to that email address with a short acknowledgement: thank them for the report, confirm the ticket has been filed, and note that engineering is looking at it. If there's no email captured or the issue is P2 or P3, skip this step.

Keep the agent focused. One run per submission. If Linear or Slack fails, retry once and then post an error message in the #bugs channel with the raw submission so nothing gets lost.

What does this prompt do?

Reads every new bug or feature request from your Jotform intake form the moment it lands, including any screenshots or console logs the reporter attached.
Decides bug vs feature request, sets a severity from P0 outage down to P3 nice-to-have, and tags the right product area like frontend, backend, mobile, or integrations.
Files a Linear issue in the correct team with a clean title, a formatted description that quotes the reporter, a priority level, and the matching labels.
Posts a short summary card to your Slack bugs channel with a link to the ticket, and pings the on-call engineer group for anything scored P0 or P1.
Skips lower priority duplicates of already known issues and sends a short acknowledgement email back to the reporter only when the issue is urgent and they left an email.

What do I need to use this?

A Jotform account with a bug report or feature request form, and permission to add an outgoing webhook to it.
A Linear workspace with the teams, priorities, and labels you want tickets filed under.
A Slack workspace with a triage channel and a user group for your on-call engineers.
A Gmail account for sending short acknowledgement replies to reporters (optional).
A rough sense of what counts as P0 through P3 at your company so the agent can apply your standards.

How can I customize it?

Point it at your own severity ladder. Rename P0 to P3 into Sev1 to Sev4, or use Urgent, High, Normal, Low.
Change which Linear team a bug lands in based on product area, and add extra labels for surfaces like iOS, Android, or a specific integration.
Decide when the reporter gets an email back. Always, only for urgent issues, or never.
Tell it which recent Linear issues to check before filing so obvious duplicates get dropped or added as a comment instead.

FAQs

Do I need to write any code for this?

No. You connect Jotform, Linear, and Slack once, then describe your triage rules in plain English. The agent handles reading the form, deciding severity, filing the ticket, and posting the alert.

How does the agent decide severity?

It reads the report and any attached screenshots or logs, then applies the definitions you give it. A typical setup is P0 for outages, P1 for broken flows, P2 for annoyances, and P3 for nice to haves.

Will it create duplicate tickets if two people report the same bug?

It searches your recent Linear issues before filing and drops lower priority reports that look like an already known bug. You can also have it add a comment on the existing issue instead.

What happens if a reporter forgets to include their email?

The workflow still files the Linear ticket and posts to Slack. It just skips the acknowledgement email since there is no address to reply to.

Can I route different product areas to different Linear teams?

Yes. Tell the agent which team owns frontend, backend, mobile, and integrations, and it will file each issue in the right place with the labels you want.

Related templates

Build a credential rotation checklist when someone leaves

When someone leaves, we check which shared passwords they used in their final months and post a ranked rotation list to your security channel.

+1

Agentic Task

Trace phishing emails to the sending IP and report abuse

Every 15 minutes, forwarded phishing reports get traced back to the server that really sent them, with a verdict in Slack and the worst senders reported.