How to Turn a Support Ticket Into a Two-Paragraph Bug Report

Anyone triaging a messy inbox can turn a support ticket into a two-paragraph bug report in 8 minutes: steps to repro, expected vs actual, and one log or screenshot. Run it in ChatGPT, Claude, or Gemini before "user is frustrated" invents a mood instead of a click path.

A two-paragraph bug report is a repro, not a diary. If an engineer still has to guess the click, you never filed a bug. Two short paragraphs plus one attachment beat a 40-line ticket dump.

This is not a three-bullet ask from a long DM. A DM ask is a request. This skill is a defect. It is not a rambling status update into three lines. A status is mid-week work. This is after something broke. It is not a five-line meeting recap email. A recap names decisions. This names a fail. Save the two-paragraph shape as a skill prompt you can rerun.

Turn a support ticket into a two-paragraph bug report

1. Paste the ticket. Do not draft a novel

Instruct ChatGPT, Claude, or Gemini: "Do not draft a bug report yet. Paste back the ticket I give you. If a sentence has no repro fact, write UNKNOWN on that sentence. No empathy paragraph. No we hear you. No priority lecture."

Paste the Zendesk thread, the Intercom dump, the email that said "it just broke," or the in-app form. A model that "upgrades" their nouns into your incident template is lying on your behalf.

Write five facts on paper before the paragraphs: product surface (page or button), what they clicked, whether a time or browser appears, whether expected vs actual is named, and whether a log, screenshot, or order ID exists.

Banned: frustrated user, we hear you, looking into this, as soon as possible, seems broken, doesn't work, ASAP, high priority with no repro, please advise, see screenshot with no steps, works on my machine as the whole report, the app is unusable, circling back, looping in engineering.

If the ticket never names a surface, write UNKNOWN. Do not invent "Checkout, then Pay." Invented clicks are how you ship a ghost bug.

2. Paragraph one is steps. Paragraph two is expected vs actual

Instruct: "Paragraph one: numbered steps the reporter actually took, in their nouns, three to six steps. Paragraph two: Expected: [one line]. Actual: [one line]. If I named no expected, write UNKNOWN on Expected. Do not invent a browser. Do not invent a stack trace."

Good paragraph one: "1. Opened Invoices. 2. Clicked Export CSV. 3. Chose March 2026. 4. Clicked Download. File never appeared." Bad: "User tried to export and it didn't work." Tried is a shrug.

Good paragraph two: "Expected: a CSV named invoices-2026-03.csv in about 10 seconds. Actual: spinner for 40 seconds, then the page reloaded with no file." Bad: "Expected: it works. Actual: broken." Works is a vibe.

If two bugs appear, keep the one with a click path. Put the second on a second ticket. Two defects in one two-paragraph bug report is a short story.

3. Attach one log or ID, then stop padding

Instruct: "After the two paragraphs, one line labeled Evidence: a request ID, screenshot name, HTTP status, or console line from the paste. If none exist, write Evidence: UNKNOWN. Do not invent a Sentry ID. Do not write a novel under Evidence."

Good evidence: "Evidence: request-id 8f2c-19, screenshot export-blank.png." Bad: "Evidence: user sent many screenshots, see thread." Many is a pile.

ChatGPT will add "hope this helps the team prioritize." Claude will hedge Actual into "appears to fail sometimes." Gemini will invent Chrome 124 when you never said a browser. Cut all three.

If Evidence is three paragraphs because the model wanted to be thorough, you failed the job. Thorough is the ticket you already had.

4. Force two paragraphs, then stop the model

Hard cap: two paragraphs plus one Evidence line. No hero summary above. No impact-on-revenue below. No severity sermon.

Tell the model: "Output exactly two paragraphs plus Evidence. No greeting. No severity. No customer journey. If a banned phrase appears, rewrite that line only."

If a third paragraph appears, delete it. If paragraph one is a wall because the model restated the whole ticket, you failed the job. Thorough is the paste.

Do not let the model "helpfully" add Workaround. Workaround is a second document. If a workaround exists in the ticket, put it in Evidence as one clause: "Evidence: they refreshed twice; still no CSV."

A support ticket bug report that still reads like a chat log is a diary with labels. Cut the greetings. Keep the clicks.

5. One human pass as the engineer who never saw the chat

Read the two paragraphs as if you will try the repro in the next 10 minutes.

Check three traps:

• Steps that skip the first click. "Then it failed" is not a step.
• Expected that is a slogan. "A smooth experience" fails.
• An ID the ticket never contained.

Fix those in your own words from the ticket. Then send the edited two back: "Replace only the words I changed. Do not re-expand. Do not add we hear you."

One pass. Paste into Linear, Jira, or GitHub Issues. If a diary still sits above the two paragraphs, you never wrote a bug report. Stop.

Reusable skill card

Trigger: You are about to paste a ticket and type "turn this into a bug report" or "write this up for engineering."

Input: The ticket, the product surface if it exists, one log or ID if it exists, plus the banned-phrase list.

Output: Two paragraphs (steps, then expected vs actual) plus one Evidence line. No greeting. UNKNOWN where a field was not in the paste.

Stop: After one human pass as a cold engineer. No third paragraph. No invented browser. No second bug hiding in Actual.

Takeaways

• Two paragraphs: steps, then expected vs actual. Then one Evidence line. Stop.
• A ticket is source. A two-paragraph bug report is a repro. Do not ship both.
• UNKNOWN on Expected is better than a fake Chrome version. Their nouns beat your incident template.
• Two bugs is two tickets. A hedge is Unknown, not a guess.