Jira / Linear ticket from messy input

Last tested 2026-04-26 Part of AI Prompts for Product Managers

Add to PromptPaste Download PromptPaste for MacDownload PromptPaste for iPhoneDownload PromptPaste for iPadDownload PromptPaste for Mac & iPhone

the prompt

Convert the messy input below (Slack thread, bug report, feature ask, customer email) into a clean ticket for {{tool}}. Use this format:

Title: action-oriented, specific enough to find later by search. No 'improve' or 'fix' as the only verb.

Summary: one paragraph. What's happening, who's affected, why it matters.

Acceptance criteria: in Given / When / Then format. Maximum 3 criteria - if you need more, the ticket is too big and should be split.

Severity: P0 / P1 / P2 / P3 with one-line rationale.

Edge cases: 2-4 specific cases the engineer should handle explicitly.

Instrumentation: what metrics or events should be added so we can verify the fix worked. This section is mandatory.

The messy input:
{{messy_input}}

Why it works

PMs spend a surprising amount of time converting messy Slack threads into clean Jira/Linear tickets. The mistake is asking for 'a Jira ticket' and getting prose that doesn't match Jira's actual format. This prompt produces tool-shaped output: title (specific, action-oriented), summary (one paragraph, not five), acceptance criteria (Given/When/Then format), severity with rationale, edge cases the engineer should explicitly handle, and instrumentation needs (what metrics to add so we can measure if the fix worked). The Given/When/Then format is the PM-engineer handoff standard - using it makes the ticket immediately reviewable by an engineer instead of triggering a clarification round. Specify your tool in the variable; the prompt produces output that pastes cleanly into Jira, Linear, GitHub Issues, or Notion without manual reformatting.

Example output

Title: Filter state lost when iPad app backgrounds for 30+ minutes

Summary: Power users on iPad lose their applied filters when the app is backgrounded for ~30 minutes (matches iOS suspended-app threshold). Affects ~12% of iPad sessions per Crashlytics analytics. User has to re-apply 3-7 filters on resume.

Acceptance criteria:
- Given a user has applied filters in the app
- When the app is backgrounded for any duration up to 24 hours
- Then the filters are restored when the app returns to foreground

Given the app was force-quit
When the user re-launches
Then the most recent filter set is restored from local storage

Severity: P2 - affects retention metric for power-user cohort, not a hard crash.

Edge cases:
- Filter references a deleted item: degrade gracefully, show 'filter no longer available'.
- App update changes filter schema: migrate or clear with explicit user notice.
- iCloud sync conflict between two devices' filter state: latest-wins, with timestamp shown.

Instrumentation:
- Log filter_restore_success / filter_restore_fail events with reason codes.
- Track 'filters_reapplied_after_resume' count - should approach zero post-fix.

Common mistakes

Don't skip the instrumentation section. The most common reason a fix ships and nobody knows if it worked is that nobody added the metric that would tell you. The whole point of the section is to make the engineer think about measurement before they write code. Also: do not let the model write more than 3 acceptance criteria. If you need 5, the ticket is too big - split it before you create it. The third common mistake is letting the title contain words like 'improve' or 'fix' - titles should name the bug or behavior specifically enough that you can find the ticket six months later by searching.

Jira / Linear ticket from messy input

Why it works

Example output

Common mistakes

More from AI Prompts for Product Managers

PRD draft from a one-line problem

Customer interview synthesis

Stakeholder weekly update