How to use Claude with Jira: a practical guide

Jira is where engineering work lives — issues, sprints, backlogs, roadmaps. Claude is useful alongside it for the writing work that engineers find tedious and non-engineers find hard to do well: writing clear issues, generating changelogs, summarizing sprint status for people who do not live in Jira, and translating customer-reported problems into actionable tickets.

There is a native Jira connector inside Claude.ai (for Claude for Teams and Claude Enterprise users), which lets Claude query your Jira workspace directly. There is also the copy-paste + API approach for teams without the connector. Both are covered here.

With the Jira connector (Claude for Teams / Enterprise)

If you have connected Jira to Claude, you can query your workspace directly in conversation.

Useful prompts:

• "What issues are currently blocked in the [project name] sprint?"
• "List all open bugs assigned to [engineer name] that are unresolved"
• "Summarize the status of epic [name or key] — what is done, in progress, and not started?"
• "What did we close in the last sprint in [project]?"

The connector is most valuable for sprint reviews, release preparation, and for project managers who need to pull status updates without bothering engineers.

What it does not do well: It cannot write back to Jira, create issues, or update status. It reads. For anything that changes data, you need to do that in Jira directly.

Without the connector (copy-paste and API approach)

Writing issue descriptions that engineers will actually use

The most common Jira failure mode is issues that contain only a title. "Fix login bug." "Update onboarding flow." These create unnecessary back-and-forth and slow down sprint planning.

Claude can turn a rough description into a proper issue in under a minute.

How to do it:

• Write the issue in plain language: "Users are hitting a 500 error when they apply a promo code at checkout after adding items from different currencies. Seems to only affect EU accounts. Started happening after the last deploy."
• Prompt: "Write a Jira issue description from this. Include: Summary (1-2 sentences), Steps to reproduce (numbered), Expected vs actual behavior, Impact (who is affected and how many users approximately), Priority context. Technical and specific. No filler."

This is especially valuable when issues come from customer support tickets or Slack messages — written in customer language, not engineer language.

Generating release notes from a sprint

At the end of a sprint or before a release, someone has to write the release notes. This involves reading through every closed issue, deciding what is user-visible, grouping by type, and writing in plain English.

How to do it:

• In Jira, filter by completed issues in the sprint and export or copy the list (key + title)
• Paste into Claude: "These are the issues we closed in sprint [name]. Write release notes. Group by: Features, Bug Fixes, Performance improvements. Plain language — written for customers who are not engineers. Skip purely internal or infrastructure work. Flag any issues that might need a separate announcement."

Writing sprint summaries for stakeholders

Product managers, executives, and CS teams regularly need to know what engineering shipped — but Jira is noise to anyone who does not live in it.

How to do it:

• Copy the sprint board (list view is cleanest) — done column and in-progress column
• Prompt: "This is our current sprint status. Write a 5-bullet summary for our Monday product sync. What shipped, what is still in progress, what is blocked and why. Written for a non-technical audience."

Turning customer-reported bugs into Jira issues

If you receive bug reports through support, Intercom, or email, someone has to translate customer language ("the thing I clicked didn't work") into an engineer-readable issue. This is a frequent bottleneck at companies where support and engineering use different tools.

How to do it:

• Copy the customer's raw report
• Prompt: "This is a customer-reported bug. Write a Jira issue. Extract: (1) what the user was trying to do, (2) what happened, (3) what they expected to happen, (4) any details about their environment or account type if mentioned. Fill in missing information with '[unknown — needs investigation]'. Technical and concise."

What does not work well

Claude cannot update Jira. Whether you use the connector or copy-paste, Claude only reads and writes text — it does not create issues, change status, or update fields. All Jira operations still happen in Jira.

Acceptance criteria still need engineering review. Claude generates reasonable acceptance criteria from a feature description, but it will miss edge cases specific to your architecture, data model, or existing behavior. Treat it as a starting draft.

Sprint velocity and capacity planning. Claude can summarize what is in a sprint, but it does not understand your team's historical velocity, individual engineer capacity, or the hidden complexity in specific tickets. Do not use it to plan sprint capacity.

The automation worth building

If your team has a developer: a webhook on new Jira issues created in a specific project that sends the title and description to Claude with a "write a fuller description and add acceptance criteria" prompt, then patches the issue via the Jira API. High value for teams where issues are created by people outside engineering.

---

This guide is part of the Claude + Tool series — practical guides for using Claude alongside the tools your team already uses. 14 guides published.

Further reading

• Discover tools that work with Claude — the connectors directory