Jira
Talk to Jira in plain language to view, create, update, and transition issues and check sprint status without leaving the agent.
Overview
Jira is an agent skill most often used in Build (also Operate, Ship) that connects your coding agent to Jira issues via CLI or MCP for natural-language ticket and sprint management.
Install
npx skills add https://github.com/davila7/claude-code-templates --skill jiraWhat is this skill?
- Auto-detects jira CLI vs Atlassian MCP vs setup guidance
- Natural-language mapping to view, list, create, move, and assign issues
- Triggers on issue keys (e.g. PROJ-123), sprint, backlog, and ticket keywords
- Quick-reference CLI commands for common intents (my issues, in-progress, transitions)
- Falls back to guiding CLI install when no backend is available
- Three backend paths: CLI, Atlassian MCP, or guided setup when neither is available
Adoption & trust: 887 installs on skills.sh; 27.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You reference PROJ-123 in chat but still have to open Jira or memorize CLI flags to update status, assign work, or see your sprint.
Who is it for?
Solo builders and tiny teams who live in Claude Code or Cursor and want ticket updates without leaving the agent session.
Skip if: Bulk Jira administration, custom workflow design, or orgs that forbid CLI shell access and have no Atlassian MCP configured.
When should I use this skill?
User mentions Jira issues (e.g. PROJ-123), tickets, sprints, backlog, or asks to create/view/update issues or check sprint status.
What do I get? / Deliverables
The agent runs the right Jira backend commands or MCP tools so issues are viewed, created, transitioned, or listed from the conversation.
- Executed Jira queries and mutations (view/list/create/move/assign)
- Setup guidance when no backend is detected
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Issue and sprint work is canonical on the Build shelf under project management where tickets tie implementation to delivery. PM subphase is where backlog, sprint, and assignment workflows live for solo builders coordinating work in Jira.
Where it fits
Pull your in-progress Jira list before picking the next feature to implement.
Transition release-blocking tickets to Done after deploy from the agent session.
View and assign an incident ticket when a user reports a bug tied to a Jira key.
How it compares
Use as a chat-driven Jira front-end, not as a full PM methodology or standalone MCP server catalog entry.
Common Questions / FAQ
Who is jira for?
Indie developers and small teams who track work in Jira and want their AI coding agent to read and update issues when they mention tickets, sprints, or issue keys.
When should I use jira?
During build and PM work to list your issues or sprint items, create or update tickets, and transition states; during ship/operate when closing or triaging production-related issues linked in Jira.
Is jira safe to install?
It may invoke shell commands against the jira CLI or MCP tools with your Atlassian credentials—review the Security Audits panel on this page and scope API tokens minimally.
SKILL.md
READMESKILL.md - Jira
# Jira Natural language interaction with Jira. Supports multiple backends. ## Backend Detection **Run this check first** to determine which backend to use: ``` 1. Check if jira CLI is available: → Run: which jira → If found: USE CLI BACKEND 2. If no CLI, check for Atlassian MCP: → Look for mcp__atlassian__* tools → If available: USE MCP BACKEND 3. If neither available: → GUIDE USER TO SETUP ``` | Backend | When to Use | Reference | |---------|-------------|-----------| | **CLI** | `jira` command available | `references/commands.md` | | **MCP** | Atlassian MCP tools available | `references/mcp.md` | | **None** | Neither available | Guide to install CLI | --- ## Quick Reference (CLI) > Skip this section if using MCP backend. | Intent | Command | |--------|---------| | View issue | `jira issue view ISSUE-KEY` | | List my issues | `jira issue list -a$(jira me)` | | My in-progress | `jira issue list -a$(jira me) -s"In Progress"` | | Create issue | `jira issue create -tType -s"Summary" -b"Description"` | | Move/transition | `jira issue move ISSUE-KEY "State"` | | Assign to me | `jira issue assign ISSUE-KEY $(jira me)` | | Unassign | `jira issue assign ISSUE-KEY x` | | Add comment | `jira issue comment add ISSUE-KEY -b"Comment text"` | | Open in browser | `jira open ISSUE-KEY` | | Current sprint | `jira sprint list --state active` | | Who am I | `jira me` | --- ## Quick Reference (MCP) > Skip this section if using CLI backend. | Intent | MCP Tool | |--------|----------| | Search issues | `mcp__atlassian__searchJiraIssuesUsingJql` | | View issue | `mcp__atlassian__getJiraIssue` | | Create issue | `mcp__atlassian__createJiraIssue` | | Update issue | `mcp__atlassian__editJiraIssue` | | Get transitions | `mcp__atlassian__getTransitionsForJiraIssue` | | Transition | `mcp__atlassian__transitionJiraIssue` | | Add comment | `mcp__atlassian__addCommentToJiraIssue` | | User lookup | `mcp__atlassian__lookupJiraAccountId` | | List projects | `mcp__atlassian__getVisibleJiraProjects` | See `references/mcp.md` for full MCP patterns. --- ## Triggers - "create a jira ticket" - "show me PROJ-123" - "list my tickets" - "move ticket to done" - "what's in the current sprint" --- ## Issue Key Detection Issue keys follow the pattern: `[A-Z]+-[0-9]+` (e.g., PROJ-123, ABC-1). When a user mentions an issue key in conversation: - **CLI:** `jira issue view KEY` or `jira open KEY` - **MCP:** `mcp__atlassian__jira_get_issue` with the key --- ## Workflow **Creating tickets:** 1. Research context if user references code/tickets/PRs 2. Draft ticket content 3. Review with user 4. Create using appropriate backend **Updating tickets:** 1. Fetch issue details first 2. Check status (careful with in-progress tickets) 3. Show current vs proposed changes 4. Get approval before updating 5. Add comment explaining changes --- ## Before Any Operation Ask yourself: 1. **What's the current state?** — Always fetch the issue first. Don't assume status, assignee, or fields are what user thinks they are. 2. **Who else is affected?** — Check watchers, linked issues, parent epics. A "simple edit" might notify 10 people. 3. **Is this reversible?** — Transitions may have one-way gates. Some workflows require intermediate states. Description edits have no undo. 4. **Do I have the right identifiers?** — Issue keys, transition IDs, account IDs. Display names don't work for assignment (MCP). --- ## NEVER - **NEVER transition without fetching current status** — Workflows may require intermediate states. "To Do" → "Done" might fail silently if "In Progress" is required first. - **NEVER assign using display name (MCP)** — Only account IDs work. Always