Lena Müller

Convert a customer bug report into an agent-ready ticket

Rewrite a vague customer bug report as a ticket an AI coding agent can work: reproduction steps, quoted evidence, hypotheses and a test-first instruction.

At a glance

Best for: Support leads, PMs and developers triaging user bug reports into work for Claude Code, Codex or a teammate.
Tested on: Claude · Opus 5.5
You fill in: reportcode_contextdo_not_touch
You get: Title [Billing] Invoice download returns the previous month's PDF for some users Reproduction Log in as an account with invoices for July and August… (full result below)

Prompt

Convert this bug report into a ticket a coding agent can pick up.

Bug report, as received:
{{report}}

What I know about the code:
{{code_context}}

Output:

1. Title: "[area] symptom when condition". Don't guess at the cause in the title.

1. Reproduction: numbered steps, including the account state and data needed. Mark any step you inferred rather than read in the report with (inferred).

1. Expected vs actual: one line each.

1. Evidence: direct quotes from the report. Don't paraphrase error messages, IDs or timestamps.

1. Suspected area: files or functions to look at first, labeled as hypotheses, with the reasoning.

1. Agent instructions: reproduce with a failing test first, find the root cause, then fix. Do not change {{do_not_touch}}.

1. Missing info: what to ask the reporter before assigning.

Don't invent details the report doesn't contain.

Fill in

{{report}}: The bug report exactly as you received ite.g. Customer email about downloading the wrong month's invoice
{{code_context}}: What you know about the relevant codee.g. Billing page in Next.js; download link built client-side with date-fns
{{do_not_touch}}: Areas the agent must not changee.g. The PDF generation service and the invoices table schema

Example input

report:
"Hi, since yesterday when I try to download my invoice for August from the billing page it downloads the July one instead. It only happens on my laptop, on my phone it's fine. I'm in Vancouver if that matters. The list shows INV-2026-0831 dated Aug 31, 2026 but the PDF says 'Invoice period: July 2026'. Thanks, Priya"
code_context: Billing page is Next.js. The invoice list comes from GET /api/invoices. The download link is built client-side as `/api/invoices/pdf?month=${format(invoice.periodStart, "yyyy-MM")}` using date-fns format(). periodStart is stored as UTC midnight on the 1st of the month.
do_not_touch: the billing-pdf service or the invoices table schema

1.7k0

Generated Outputs (1)

3 hours ago

Claude

Opus 5.5

3 hours ago

Generated Output

1. Title
[Billing] Invoice download returns the previous month's PDF for some users

2. Reproduction

1. Log in as an account with invoices for July and August 2026.

1. Set the laptop's timezone to America/Vancouver (UTC−7) (inferred: the reporter mentions Vancouver; we haven't confirmed their laptop's setting).

1. Open the billing page and click download on INV-2026-0831.

1. Check the invoice period printed in the PDF.

3. Expected vs actual

• Expected: the PDF for INV-2026-0831 shows "Invoice period: August 2026".

• Actual: it shows "Invoice period: July 2026".

4. Evidence

• "since yesterday"

• "It only happens on my laptop, on my phone it's fine"

• "I'm in Vancouver if that matters"

• "The list shows INV-2026-0831 dated Aug 31, 2026 but the PDF says 'Invoice period: July 2026'"

5. Suspected area (hypotheses)

• The download link builder on the billing page. format(invoice.periodStart, "yyyy-MM") formats in the browser's timezone. 2026-08-01T00:00:00Z is 31 July, 17:00 in Vancouver, which gives month=2026-07. That fits "July instead of August" and a device-dependent failure. It doesn't explain why the phone works (a different timezone setting? the app rather than the browser?) or "since yesterday".

• A recent deploy touching the billing page or /api/invoices, given "since yesterday". Check the deploys from the past 48 hours.

6. Agent instructions

1. Reproduce first: write a failing test that renders the billing page's download link with TZ=America/Vancouver and an invoice with periodStart = 2026-08-01T00:00:00Z, and asserts month=2026-08.

1. Find the root cause and confirm it explains the reporter's symptom. If it doesn't explain the phone difference, say so in the report.

1. Fix, keeping the change minimal. Prefer passing the invoice ID, or a month string computed on the server, over formatting dates in the client.

1. Do not change the billing-pdf service or the invoices table schema.

1. Report: root cause, the diff, the test output, and any other client-side date formatting you found with the same risk.

7. Missing info (ask the reporter)

• What timezone is the laptop set to? (Clock settings, or visit a time zone checker site.)

• On the phone, are they using the browser or our mobile app?

• Which browser and version on the laptop?

• Did downloads for other months also come back one month early?

Why it works

"Don't guess at the cause in the title" keeps the ticket honest, so the agent doesn't start by confirming a guess. The (inferred) marker separates what the customer said from what you assumed, which is where most bad tickets go wrong. Quoting evidence verbatim preserves clues ("since yesterday", "phone is fine") that paraphrasing would lose. Labeling suspects as hypotheses and telling the agent to check whether the root cause explains every symptom stops it declaring victory on half an explanation.

When not to use it

It can't reproduce anything. For intermittent or data-specific bugs, collect logs, IDs and timestamps before writing the ticket. Strip personal data (names, emails, account details) from reports before pasting them into any AI tool, following your company's data policy. A wall of stack traces needs grouping first, or the ticket will be noisy.

Comments (0)

No comments yet. Be the first to share your thoughts!