Turn Zendesk bug tickets into clean GitLab issues

By General Input

Every hour, an agent reads new bug-tagged Zendesk tickets, writes structured GitLab issues for the real defects, and pings engineering in Slack when something is severe.

Integrations

  • Zendesk
  • GitLab
  • Slack Bot

Type

Agentic Task

Categories

  • Engineering
  • Customer Support

Build me an agent that turns customer bug reports in Zendesk into well-written GitLab issues so engineering stops missing real bugs buried in our support queue.

Trigger: cron, every hour during business hours (let me configure the exact hours and timezone).

Each run, the agent should:

1) Use Zendesk Search Tickets to pull tickets created or updated since the last successful run that match a configurable set of tags or views (defaults to tags like bug, engineering, or escalation). Let me set the exact tags, views, or search query, plus the target GitLab project and labels, as inputs to the workflow.

2) For each candidate ticket, call Zendesk Show Ticket and List Ticket Comments to read the full thread, including the customer messages and any internal notes.

3) Decide whether it is a reproducible defect or a how-to / account / billing question. Skip the non-bugs and record a one-line reason in the run summary. Do not file issues for non-defects.

4) For real bugs, dedupe before filing: call GitLab List Project Issues on the configured project (state=opened, recent first) and compare titles and key symptoms to avoid creating duplicates of issues opened in the last few weeks. If a clear duplicate exists, skip the create and note the existing issue in the run log instead.

5) For new bugs, use GitLab Create an Issue with a clean, specific title and a structured body containing: Summary, Steps to reproduce, Expected vs Actual, Environment (browser/OS/version if known), Customer impact (who and how many), and a link back to the Zendesk ticket. Apply severity and area labels inferred from the ticket content from a label allowlist I provide (for example sev1/sev2/sev3 and area:billing, area:auth, area:api).

6) After the GitLab issue is created, call Zendesk Update Ticket to add an internal note (not a public reply) containing the GitLab issue URL and a one-line summary, so the support agent can see the engineering handoff happened.

7) For high-severity bugs (configurable threshold, default sev1 and sev2), also use Slack Send a Message to post in a configured engineering Slack channel with the customer impact in one line, the GitLab issue link, and the Zendesk ticket link.

Hard rules: never auto-reply to the customer on the Zendesk ticket. Never change ticket status, priority, assignee, or public-facing fields. Only add internal notes. Skip tickets that already have an internal note containing a GitLab issue URL so a re-run does not double-file.

At the end of each run, output a short summary listing tickets filed (with GitLab links), tickets skipped as not-a-bug (with reason), and tickets skipped as duplicates (with the existing GitLab link), so a human owner can spot-check.

Related prompts

Explore more prompts
A brand asset library your marketing team actually searchesTurn Mailjet email clicks into ranked HubSpot follow-upsClean out the Looker dashboards and Looks nobody opensLiveKit live operations console for room moderationWake up dormant Keap leads with a researched reasonLiveChat coverage board for planning next week's shiftsPhone routing control panel for LiveKit voice agentsLinkedIn Ads budget pacing dashboard for every client accountGive your team Looker numbers without buying more seatsPause marketing emails to escalated customers, then restore them