How to Build a Claude-Powered Jira Ticket Summarizer

A Claude-powered Jira ticket summarizer pulls issue data (description, comments, status history) through the Jira REST API, sends it to Claude with a structured prompt, and writes a concise summary back as a comment, Slack message, or dashboard field. The core pieces are: Jira API access, an HTTPS endpoint that calls Claude, a prompt that extracts the right signal from noisy threads, and a trigger (webhook or cron) that runs the whole thing automatically.

This is a common internal tool because Jira tickets accumulate dozens of comments, status changes, and linked issues over weeks, and nobody reads all of it before a sprint review or handoff. Below is a working architecture you can build in an afternoon, plus the prompt patterns that actually hold up on messy real-world tickets.

What you need before starting

• A Jira Cloud site with API access (email + API token, or OAuth app)
• A Claude API key or a SubToAPI key (sub_live_...) if you want hosted key management, streaming, and usage metadata without running your own Anthropic account infrastructure
• A small backend (serverless function, Lambda, or a lightweight Node/Express service) to orchestrate the Jira fetch → Claude call → Jira write-back
• A trigger: Jira webhook on issue update, or a scheduled job for end-of-sprint batch summaries

Step 1: Pull the ticket data from Jira

Use Jira's REST API to fetch the issue with its full comment history:

curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  "https://yourcompany.atlassian.net/rest/api/3/issue/PROJ-123?expand=renderedFields,comment"

The response includes fields.description, fields.status, fields.comment.comments[], and metadata like assignee and priority. Flatten this into plain text before sending it to Claude — strip Jira's ADF (Atlassian Document Format) markup down to readable text, and order comments chronologically so Claude sees the conversation in sequence rather than as a JSON blob.

Step 2: Design the summarization prompt

The failure mode with ticket summarizers is Claude restating the last comment instead of synthesizing the whole thread. Be explicit about what you want:

You are summarizing a Jira ticket for an engineering lead who has not read it.

Ticket: {key} — {title}
Status: {status} | Priority: {priority} | Assignee: {assignee}

Description:
{description}

Comment history (chronological):
{comments}

Write a summary with exactly these sections:
1. Current state (1-2 sentences)
2. What's blocking progress, if anything
3. Key decisions made in the thread
4. Next action and who owns it

Keep it under 120 words. Do not repeat the raw description verbatim.

Pinning the output format matters more than the model choice here — it's what makes the summary usable in a Slack digest or a sprint report without manual cleanup.

Step 3: Call Claude via the API

If you're using SubToAPI, the request looks like any other Claude call, but you authenticate with your application key and get usage data per request without touching Anthropic console settings:

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-5",
    max_tokens: 400,
    messages: [{ role: "user", content: summaryPrompt }]
  })
});

const data = await res.json();
const summary = data.content[0].text;

See /docs/quickstart for setup and /docs/messages for the full request shape. If tickets are long, consider streaming the response — /docs/streaming covers how to handle partial tokens if you're displaying the summary live in a dashboard instead of just writing it back to Jira.

Step 4: Write the summary back to Jira

Post the summary as a comment, or into a custom field if you want it visible on the board without expanding the ticket:

curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  -X POST "https://yourcompany.atlassian.net/rest/api/3/issue/PROJ-123/comment" \
  -H "Content-Type: application/json" \
  -d '{
    "body": {
      "type": "doc",
      "version": 1,
      "content": [{"type": "paragraph", "content": [{"type": "text", "text": "'"$SUMMARY"'"}]}]
    }
  }'

Tag the comment with a prefix like [AI Summary] so it's visually distinct and your team knows which comments are generated versus human-written.

Step 5: Automate it with webhooks

Set up a Jira webhook on jira:issue_updated filtered to events where comment or description changed, pointing at your backend endpoint. Debounce it — if someone adds five comments in two minutes, you don't want five Claude calls and five summary comments. A simple approach: queue the event, wait 2–3 minutes for quiet, then run the summarizer once on the latest state.

For sprint-level reporting instead of per-ticket updates, skip webhooks entirely and run a nightly batch job that pulls every ticket updated in the last 24 hours and summarizes them into one digest.

Handling long threads and multiple tickets

Some tickets accumulate 50+ comments over months. Two practical options:

• Truncate intelligently: keep the description, the first 2 comments (original context), and the last 10 comments (current state), and tell Claude explicitly that it's working from a partial history.
• Use tool use for structured extraction: if you want Claude to pull specific fields (blocker, owner, ETA) into a JSON object rather than prose, define a tool schema and let Claude call it with structured arguments. See /docs/tools for the request format — this works well if the summary feeds a dashboard rather than a comment.

If you're summarizing dozens of tickets in one batch run, watch your request volume. SubToAPI's dashboard shows per-key usage so you can see exactly how many tokens a sprint-wide summarization job burns, which matters when you're running this daily across an entire backlog. Plans start at €9/month on the Solo tier; check /pricing if you're scaling this to a whole team's Jira instance.

questions

Does this work with Jira Server/Data Center, not just Cloud? Yes, the REST API endpoints differ slightly (v2 vs v3, different auth), but the summarization logic — fetch issue, build prompt, call Claude, write comment — is identical regardless of Jira deployment type.

How do I avoid summarizing the same ticket repeatedly on every minor edit? Debounce webhook events (wait a few minutes after the last change before running) and store a hash of the ticket content so you skip the Claude call entirely if nothing meaningful changed since the last summary.

Can I run this without managing my own Anthropic API keys? Yes — SubToAPI gives you an HTTPS endpoint and application keys (sub_live_...) with streaming, usage metadata, and team seats, so you can plug Claude into your Jira automation without separately provisioning and billing Anthropic infrastructure. Start at /signup.