| name | jira-tasks |
| description | Read-only Jira for the project's tracker: my tickets, open tickets, ticket status, jira backlog, link a workspace task to a ticket. NOT for write ops (create/transition/comment/log-work) and NOT for Confluence. |
| version | 1.0.0 |
| owner | swarmery-core |
| docs | {"status":"reviewed","source_sha":"29018bba26b7","updated":"2026-08-06T00:00:00.000Z"} |
Purpose
Read Jira to answer "what am I working on", "what's the status of <PROJECT-KEY>-115", or to
reconcile workspace tasks against tickets. Read-only by default — every write (create /
transition / comment / worklog) is a separate, explicit, user-requested action (see
Write-op policy).
Site and project key: this skill uses <jira-base-url> (e.g. yourteam.atlassian.net)
and <PROJECT-KEY> as placeholders. Check the consumer project's CLAUDE.md (or
.claude/project.json) for the actual Jira base URL, project key, and any pinned cloudId.
If none is documented, ask the user once and suggest recording it in CLAUDE.md.
Tool flow
The Atlassian MCP tools are deferred — their schemas are not loaded at start. Load them
before the first call, or the call fails with InputValidationError. Resolve by tool name,
never by a hardcoded channel prefix: at least two channels can expose the same tool names
under different prefixes — an officially-installed Atlassian MCP plugin (e.g. a
mcp__plugin_atlassian_atlassian__*-shaped prefix) or a claude.ai Atlassian/Rovo connector
(e.g. a mcp__claude_ai_Atlassian_Rovo__*-shaped prefix) — and which channel, if any, is live
varies by session and by machine. Hardcoding one prefix reports "no access" against a perfectly
reachable Jira the moment the other channel is the one that's live:
ToolSearch query: "+atlassian getAccessibleAtlassianResources searchJiraIssuesUsingJql getJiraIssue"
Read the full tool names back from the result and use whichever prefix actually resolved for
every call in this session — if two channels resolve at once, prefer whichever one's
getAccessibleAtlassianResources response matches the project's jira.baseUrl. This is the
same provider-agnostic resolution jira-pack's preflight step performs; see
plugins/jira-pack/skills/jira-access-preflight/SKILL.md (Steps 1-2) for the canonical
procedure this skill's narrower read-only lookup follows.
Every Jira call needs a cloudId. Resolve it by calling
getAccessibleAtlassianResources (no args) and taking the id of the <jira-base-url>
resource. If the project's CLAUDE.md pins a cloudId, use it directly — but if any call
404s (site migrated, token re-scoped), re-resolve rather than retrying a stale id.
- Search / list →
searchJiraIssuesUsingJql (cloudId, jql, fields, maxResults).
Request only the fields you'll print (key,status,summary,updated,assignee) — don't pull
full descriptions for a list.
- Single ticket →
getJiraIssue (cloudId, issueIdOrKey: "<PROJECT-KEY>-115").
JQL recipes
| Intent | JQL |
|---|
| My open work | assignee = currentUser() AND project = <PROJECT-KEY> AND statusCategory != Done ORDER BY updated DESC |
| Recently updated (last week) | project = <PROJECT-KEY> AND updated >= -7d ORDER BY updated DESC |
| By label | project = <PROJECT-KEY> AND labels = <label> ORDER BY updated DESC |
| In-progress across the team | project = <PROJECT-KEY> AND statusCategory = "In Progress" ORDER BY updated DESC |
Single ticket (or use getJiraIssue) | key = <PROJECT-KEY>-115 |
currentUser() resolves to the caller's Atlassian account — no need to hardcode an accountId.
statusCategory != Done is more robust than listing status names, which vary per board.
Join-key convention (tickets ↔ workspace tasks)
Workspace task cards link themselves to tickets via a Tickets: line in the task-card
README.md (under working/YYYY/MM/DD/<slug>/ in the agent workspace — resolved by
agent-work.sh from AGENT_PROJECT), e.g. Tickets: <PROJECT-KEY>-115, <PROJECT-KEY>-93.
This is the join key in both directions:
- Reporting a ticket? Grep for an existing task dir first:
rg -l "<PROJECT-KEY>-115" <workspace>/working — if one exists, mention the task slug +
its SUMMARY.md so the user sees prior work, not a cold ticket.
- Reporting a task? Read its
Tickets: line and pull those keys' live status so the
card's status and Jira agree.
When you start work that maps to a ticket, add the Tickets: <PROJECT-KEY>-<n> line to the
task README (that's a workspace-file edit, not a Jira write — always fine).
Output shape
Render a compact table, most-recently-updated first — never dump raw issue JSON:
| Key | Status | Summary | Updated |
|----------|--------------|------------------------------------------|------------|
| ABC-115 | In Progress | Image retention policy relax | 2026-07-03 |
| ABC-93 | In Review | Memory-leak audit | 2026-07-02 |
Truncate long summaries to one line. Link known task dirs inline. For a single ticket,
a short field list (status, assignee, labels, updated, description gist) beats the full blob.
Write-op policy
Creating issues, transitioning status, adding comments, and logging worklogs are write
operations. Per the rules/ASK.md posture (default to NO; surface what/why/blast-radius
before acting), each one requires an explicit user request in the current conversation —
never as a side effect of a read, a report, or "while I was in there". A request to list or
check tickets never authorises a mutation.
- Don't auto-transition a ticket because a fix merged.
- Don't comment "done" on the user's behalf unprompted.
- The one blessed pattern: after shipping a fix, the user may ask you to drop an
MR-links comment (branch/MR URLs + one-line result) on the ticket. Still surface it
first — it's user-visible and user-requested, not silent.
Write tools (createJiraIssue, transitionJiraIssue, addCommentToJiraIssue,
addWorklogToJiraIssue) are loadable via ToolSearch the same way, but only reach for them
once the user has explicitly asked for that specific change.
Exception — a run launched via /jira-fix in a project with jira-pack enabled. This
read-only, always-ask policy governs ad-hoc queries in this skill only. jira-pack's
@jira-task-runner agent carries its own, broader write mandate — comment/transition/board
mutation without a per-action confirmation prompt — but that mandate is scoped strictly to a
run explicitly started through /jira-fix; it never leaks into an ad-hoc "what's the status of
<KEY>" query answered by this skill, and this skill's always-ask posture never narrows what
/jira-fix is allowed to do inside its own run. See
plugins/jira-pack/agents/jira-task-runner.md (## Boundary with plugins/core/skills/jira-tasks/SKILL.md)
for the same boundary stated from the other side.
Related
rules/ASK.md — human-confirmation posture this skill defers to for any write.rules/ALWAYS.md — the Tickets: task-card convention and workspace layout.plugins/jira-pack/ — /jira-fix's end-to-end autonomous run (access preflight,
reproduction, delegated fix, evidence comment, QA transition); see the exception above for
how its broader write mandate relates to this skill's read-only default.- Atlassian plugin skills (
atlassian:generate-status-report,
atlassian:capture-tasks-from-meeting-notes) — heavier report/write workflows; this skill
is the lightweight read path.
How to use
What it does
This skill answers Jira questions without changing anything. Ask what you are working on, what a ticket's status is, or what changed in the last week, and you get a compact table back instead of raw issue JSON. It also links tickets to your workspace task cards in both directions, so a ticket lookup surfaces prior work you already have on disk.
When to use it
- You want your open tickets, a team's in-progress list, or a project backlog view.
- You need the live status, assignee, and labels of one ticket by key.
- You are writing up a workspace task and want its
Tickets: line reconciled against real Jira status.
- You are about to start work and want to check whether a task card for that ticket already exists.
When not to use it
- You want to create, transition, comment on, or log work against a ticket — those are writes, and each needs an explicit request from you first.
- You want a full autonomous run on a ticket (reproduce, fix, evidence comment, QA transition) — use
/jira-fix instead.
- You want a formatted status report published to a wiki — use
atlassian:generate-status-report.
- You need Confluence pages rather than issues — this skill is Jira-only.
How to invoke
Skill(skill: "core:jira-tasks")
Invoke it, then state the question in plain words — "my open tickets", "status of <PROJECT-KEY>-115", "what moved this week".
Inputs
- Question or ticket key — what you want to know — required.
- Jira base URL and project key — read from the project's
CLAUDE.md or .claude/project.json; you are asked once if neither records them.
- Pinned cloudId — optional; it is re-resolved automatically if a call returns 404.
What you get back
A table sorted most-recently-updated first, with key, status, summary, and updated date. Summaries are truncated to one line. For a single ticket you get a short field list instead — status, assignee, labels, updated, and the gist of the description. If a workspace task card already references the ticket, its slug is named inline. Nothing in Jira is modified.
Worked example
Skill(skill: "core:jira-tasks")
> what am I working on in <PROJECT-KEY>?
The skill loads the Atlassian tools by name, resolves the site's cloudId, and runs
assignee = currentUser() AND project = <PROJECT-KEY> AND statusCategory != Done ORDER BY updated DESC.
You get a four-column table of your open tickets, with a note where an existing task card already carries one of those keys on its Tickets: line.
Related
jira-pack:jira-fix — prefer it when you want a ticket driven end to end, not just read.jira-pack:jira-config — prefer it when the Jira settings themselves need validating.atlassian:triage-issue — prefer it when checking a bug report for duplicates before filing.
