Home / Guides & Tutorials / The AI Coding Workflow That Ships: From …

CHAPTER 4 OF 7 · 10 min · 3 COPYABLE ASSETS

How to auto-create JIRA tickets from a PRD with Claude Code and MCP

Run /create-stories to split a PRD into JIRA tickets via the Atlassian MCP server: acceptance criteria, dependencies, and technical notes included automatically.

TL;DW

With a reviewed PRD, run /create-stories with three arguments: the PRD path, your JIRA project ID, and the epic ID. Claude Code breaks the document into user stories, then uses the Atlassian MCP server to create every ticket, complete with acceptance criteria and technical-note comments it researched from your codebase. The same flow works with the GitHub CLI or the Linear MCP server. Setup is a single .mcp.json file, and Claude can write that file for you.

Watch: FULL Guide to Becoming a Principled Agentic Engineer (Build Anything with AI)

▶ Watch this chapter on YouTube from 28:54

Lesson · 9 parts

After the brain dump, Cole is barely typing anymore. 'I'm running commands, I'm answering questions, that's really all I have to do.' The stories command takes the PRD path plus the JIRA project and epic IDs. It can run in a fresh context window, though a short session like this one is fine to continue in place.

The command walks four phases. Load the PRD (all the context it needs). Break it into user stories in the format the command defines, acceptance criteria included. Self-check that every phase of the PRD became a story, so nothing silently drops. Then, if the JIRA arguments are present, push everything through the MCP server; if not, the stories stay as local markdown files, which is how many solo developers run their whole system.

Both IDs come straight from JIRA's interface: the project key sits in the project settings, and the epic ID shows on the epic itself.

The invocation. Find both IDs in JIRA's UI

/create-stories .agents/prd-phase-2.md <jira-project-id> <epic-id>

Using GitHub instead? The identical process runs through the GitHub CLI creating issues. Linear? The Linear MCP server. The tracker is an implementation detail. Once tickets exist, developers work in parallel, self-assigning through the MCP server or getting assigned the moment they pick up a piece of work.

Run /mcp in Claude Code and the connected Atlassian server appears, which covers Confluence as well as JIRA. The PRD can live in Confluence, tickets in JIRA, and agents shuttle context between them. All the CRUD grunt work of task management (creating, updating, assigning) becomes agent territory.

The whole integration is one .mcp.json file, and you do not configure it by hand. Claude Code has access to its own documentation, searches the web for the current Atlassian setup, knows to create the file, and wires everything. A PM or QA engineer can do this without a developer.

The .mcp.json file lives at the repo root and lists every MCP server the project can reach, so it ships with the codebase: a teammate who clones the repo inherits the same integrations. The Atlassian server covers JIRA and Confluence with one connection, and the first call triggers a browser login to authorize your Atlassian account.

If a tool call fails later, treat the agent as its own support engineer. Paste the exact error, ask it to check /mcp status, and let it search the Atlassian documentation. Connection issues are usually stale auth or a renamed cloud ID, and the agent finds both quickly.

The setup prompt. It works for any MCP server

Help me set up the Atlassian MCP server for JIRA and Confluence. Search the web for the current configuration if you need to, create the .mcp.json file, and verify the connection works. If it fails, debug it and search the Atlassian docs for fixes.

Cole did not hand-configure any of this. He pointed Claude Code at his personal repository of commands and skills and said: set up a new repo for the workshop, bring my resources in, and customize them to work with JIRA instead of GitHub. The agent did all of it. The tooling you are learning was assembled by the tooling.

As stories push to JIRA, the token counter climbs. That is the agent formulating MCP tool calls. Ctrl+O expands full visibility: the create-issue tool, the project and epic parameters, and a green circle when each call completes. Refresh JIRA and tickets materialize mid-run.

Click into any created ticket: story format, acceptance criteria, exactly what the command specified. Then the surprise. The agent added technical notes as comments, having researched the codebase for how it would implement each feature. A PM alone could not provide that context. The agent provides it to every developer up front.

An acceptance criterion worth copying

Given a poll with live mode enabled,
when a new vote is submitted,
then the presenter view updates within 2 seconds
and the total count matches the database exactly.

At an organization, the PM now takes this populated backlog to the development team, usually a scrum or sprint-planning session where wrong assumptions get fixed and tickets get refined. Solo developers: these are your GitHub issues, and you handle them one at a time. The agent keeps working in the background either way.

Cole picks the presenter projection page: full-screen live results with animated charts. The principle he lands on matters more than the pick. The input to writing code should always be an artifact, a JIRA ticket or a GitHub issue, never a vague memory of a conversation. That artifact is what enters the PIV loop next.

Study notes

Part 1 of 9 · 28:54 to 29:40

Run /create-stories with three arguments

Concept Measure the workflow by keystrokes for a moment: after the initial brain dump, the human contribution is running commands and answering questions. That is what it looks like when the AI layer carries the procedure and the human carries only the judgment.

Pitfall The on-camera shortcut, skipping PRD iteration, is flagged by Cole himself: do as I say, not as I do. On real work, the previous chapter's review pass happens before this command ever runs, because tickets faithfully inherit every flaw the PRD still contains.

Do this

Create the epic in JIRA first. That is the one manual step.
Copy the /create-stories invocation from the lesson panel and fill in your PRD path, project ID, and epic ID.

Part 2 of 9 · 29:40 to 30:44

Tracker-agnostic by design

Concept Both IDs come straight from JIRA's interface: the project key sits in project settings, the epic ID on the epic's own page. Thirty seconds of lookup completes the invocation. If you use another tracker, the equivalents are the repo name or the Linear team and project.

Example The tracker swap in practice: on GitHub, the same command shells out to gh issue create once per story. On Linear, it calls the Linear MCP server. The story-derivation phase is untouched in both cases, which tells you where the real logic lives: in the procedure, not the integration.

Do this

Using GitHub or Linear? Swap the JIRA step for the GitHub CLI or Linear MCP. Everything else stays.

Part 3 of 9 · 30:44 to 31:47

Let agents own the entire admin layer

Why it matters Auto-assignment sounds like a toy until you have run a team board: agents handling the assign-update-close churn removes the coordination tax that makes trackers rot. The board stays truthful without anyone spending Friday afternoon doing JIRA hygiene, and stale tickets stop lying to standup.

Concept Run /mcp in Claude Code and read the list of connected servers. One Atlassian connection covers JIRA and Confluence together, so PRDs can live in Confluence while tickets live in JIRA, with agents shuttling context between the two tools instead of a human copy-pasting.

Do this

Run /mcp in Claude Code and confirm your Atlassian server is listed.

Part 4 of 9 · 31:47 to 33:08

Set up the MCP server, or make Claude do it

Concept The file .mcp.json at the repository root is the entire integration surface: it lists the MCP servers this project can reach. Because it ships with the codebase, a teammate who clones the repo inherits every connection on day one, with only the login left to do.

Example The setup conversation is genuinely this short: ask the agent to set up the Atlassian MCP server, let it search the current documentation, and complete the browser login when Atlassian asks. Configuration that used to be a developer's afternoon is now one prompt plus an OAuth click.

Try it Adopt the debugging stance before you need it: when a tool call fails, paste the exact error back and say debug this, check /mcp status, and search the Atlassian docs. Stale auth and renamed cloud IDs cause most failures, and the agent locates both faster than you will.

Do this

Paste the setup prompt from the lesson panel into Claude Code.
Complete the browser login when Atlassian asks.
Commit the generated .mcp.json so your team inherits the integration.

Part 5 of 9 · 33:08 to 34:11

Meta moment: Claude built this workshop repo

Example The workshop repo itself is the strongest evidence in the video: Cole pointed Claude Code at his personal commands and asked it to adapt everything for JIRA in a fresh repository. The agent migrated its own tooling. Your version: point it at a teammate's command folder and request the port.

Concept Back in the run, notice the consent gate: stories exist locally first, then the agent asks before pushing to JIRA. Outward-facing or destructive steps should always carry that pause, and it costs exactly one line of instruction inside the command file.

Do this

Try the same meta move: point Claude at a repo of your commands and ask it to adapt them to a new project.

Part 6 of 9 · 34:11 to 35:16

Watch the tool calls with Ctrl+O

Concept The climbing token counter is the work itself: each JIRA ticket is an MCP tool call the agent composes and sends. Nothing is hidden behind the spinner. Ctrl+O expands the full view: the create-issue tool, the parameters it chose, and a green circle per completed call.

Why it matters That visibility is your audit trail. When something lands wrong in the tracker, you read exactly which call did it and with which parameters, instead of guessing what the agent probably did. Make Ctrl+O a reflex during any MCP-heavy run; it converts suspicion into inspection.

Do this

Press Ctrl+O during the run and watch the create-issue calls.
Refresh JIRA and confirm tickets appear.

Part 7 of 9 · 35:16 to 36:24

Tickets arrive richer than most humans write them

Concept Open a created ticket and grade it honestly: user-story phrasing, acceptance criteria present, formatted precisely as the command specified. Compare it to what your team writes by hand on a rushed Tuesday. That comparison, not the demo gloss, is the honest value measurement.

Try it If anything reads wrong, too verbose, wrong emphasis, missing a field your team relies on, fix the command rather than the tickets. Editing output is a one-time patch that evaporates. Editing the procedure upgrades every run that will ever happen after it.

Do this

Open one created ticket.
Read the acceptance criteria and the technical-note comment the agent researched.

Part 8 of 9 · 36:24 to 37:29

In a real team, this is where refinement happens

Concept The technical-note comments are the sleeper feature of the whole chapter: before any human picked up the work, the agent researched the codebase and attached implementation suggestions to each ticket. Developers start from a map instead of a blank page, and estimation quality rises with them.

Concept Refinement still happens, and should: a scrum pass for teams, a deliberate read-through for soloists. The agent moved the starting line forward, not the finish line. Wrong assumptions still die in human review, exactly where your process already kills them.

Do this

Schedule the refinement pass: a team scrum, or a solo read-through if you work alone.

Part 9 of 9 · 37:29 to 38:44

Pick the first ticket. The artifact IS the input

Concept Watch the selection reasoning, not just the pick: Cole wants a ticket that is visual, self-contained, and travels end to end through the app's data flow. Those are strong criteria for demos and equally strong for your own first run at this workflow.

Try it Pick your own first ticket now with the same filter: small, visible, end to end. Your first PIV loop should teach you the loop itself, not wrestle your gnarliest architectural problem. Save the dragon for the third or fourth cycle, once the process feels boring.

Why it matters The closing principle carries the entire chapter: code work starts from an artifact, a ticket or an issue, never from the memory of a conversation. Artifacts persist, transfer cleanly between people and agents, and settle disputes. Conversations do none of those things.

Do this

Pick one ticket as your PIV-loop input and write down its ID.
You will prime against it in the next chapter.

Key terms

MCP server: A Model Context Protocol connector that lets an agent operate external tools such as JIRA or Confluence.
Epic: JIRA's container for related tickets; the shelf a sprint's work sits on.
Acceptance criteria: Testable conditions that define when a ticket counts as done.

Key takeaways

Three arguments drive the whole step: PRD path, JIRA project ID, epic ID. Swap the JIRA calls for the GitHub CLI or Linear MCP and nothing else changes.
You never do JIRA admin again. Creating, assigning, and updating tickets is agent work now.
Ctrl+O in Claude Code reveals the raw MCP tool calls: your visibility into what the agent is actually doing.
The agent does more than create tickets. It researches the codebase and attaches technical implementation notes as comments.

Watch out

The epic must exist first. Creating it was the only manual JIRA work in the entire demo. /create-stories fills an epic; it does not create one.
If the MCP server refuses to connect, paste the error back to the agent and tell it to search the Atlassian docs. Coding agents debug their own tooling well.

Check your understanding

What three arguments does /create-stories need, and what must already exist in JIRA?

The PRD path, the JIRA project ID, and the epic ID. The epic itself must be created beforehand; it was the one piece of manual JIRA work in the demo.

Beyond creating tickets, what extra context does the agent attach?

Technical implementation notes as comments on each ticket, researched from the actual codebase before any developer picks up the work.

01 28:54 Step Run /create-stories with three arguments ▾

02 29:40 Concept Tracker-agnostic by design ▾

03 30:44 Concept Let agents own the entire admin layer ▾

04 31:47 Step Set up the MCP server, or make Claude do it ▾

05 33:08 Note Meta moment: Claude built this workshop repo ▾

06 34:11 Step Watch the tool calls with Ctrl+O ▾

07 35:16 Concept Tickets arrive richer than most humans write them ▾

08 36:24 Note In a real team, this is where refinement happens ▾

09 37:29 Step Pick the first ticket. The artifact IS the input ▾