From atlassian
Builds a visual Jira sprint dashboard from project, board, filter, JQL, or URL data. Useful for standups, sprint reviews, delivery reviews, and WIP planning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/atlassian:jira-sprint-dashboard-canvasThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Build a focused dashboard that helps an engineering manager, tech lead, or
Build a focused dashboard that helps an engineering manager, tech lead, or senior engineer see current Jira work quickly enough to decide what needs attention. The output is a dashboard, not a prose report and not a generic health score.
This skill is read-only by default. Do not create, update, transition, assign, or comment on Jira work items unless the user explicitly asks for a write action after reviewing the dashboard.
Use the richest dashboard renderer supported by the current environment. The dashboard content, claims, counts, and source appendix must stay consistent across renderers; only the presentation changes.
Choose the renderer in this order:
Do not mention that Cursor Canvas is unavailable unless the user specifically asked for Cursor Canvas. If the user asked for a dashboard generally, use the best available renderer without apologizing for the environment.
Use this section only when running in Cursor with Canvas support.
Read ~/.cursor/skills-cursor/canvas/SKILL.md before writing canvas code. If
you need exact exports or prop shapes, read the files in
~/.cursor/skills-cursor/canvas/sdk/.
Canvas constraints:
.canvas.tsx file in the Cursor canvases directory.cursor/canvas. Do not import react, CSSProperties,
JSX, Atlaskit, or other packages.Stack, Grid, Card, Stat, Table,
Pill, Callout, UsageBar, BarChart, LineChart, PieChart, and Code
over raw HTML.useHostTheme() for custom styles. Do not hardcode hex colors, gradients,
box shadows, ADS variables, unsupported CSS frameworks, or @atlaskit/*.Use this section when Cursor Canvas is unavailable.
For an interactive artifact renderer:
For static HTML:
For Markdown:
For JSON fallback:
Do not guess the Jira scope. If the user does not provide a project key, space key, board, sprint, filter, JQL, work item keys, or Jira URL, stop and ask for one. A dashboard from a random visible project or guessed team context is worse than no dashboard.
If the user gives a project or space key but no sprint, board, or filter, start
with the Jira JQL project field and the user's key:
project = "SPACE_KEY" AND sprint in openSprints() ORDER BY Rank ASC
If the open sprint result is empty, stale, or misleading, switch to snapshot mode and say so in a compact caveat below the top bar:
project = "SPACE_KEY" AND statusCategory != Done ORDER BY priority DESC, updated ASC
project = "SPACE_KEY" AND updated >= -60d ORDER BY updated DESC
Use a 60-day recent movement window by default unless the user asks for another period.
Use read-only Jira search. Request only fields needed for the dashboard and tolerate missing fields.
Useful fields: key, summary, status, statusCategory, assignee,
priority, issuetype, created, updated, resolutiondate, duedate,
parent, issuelinks, labels, components, fixVersions, sprint, and any
available estimate/story point field.
Start with maxResults: 100. For complete sprint, board, or filter dashboards,
paginate until the scope is complete or too large for useful work-item-level
rendering.
Default to one complete paginated scope query. Derive ordinary dashboard signals locally from the returned work item set instead of issuing separate JQL calls for each signal.
Derive these locally when the scope query returned the required fields:
statusCategory = Done and resolutiondate.statusCategory != Done and updated.statusCategory != Done and empty assignee.statusCategory != Done and priority.status, statusCategory, and labels.Use targeted follow-up queries only when they are needed to support a visible claim that cannot be derived safely from the scope data, when the scope is too large for useful local processing, or when the user asks for an audit-style dashboard with exact evidence per signal.
Rule of thumb:
Examples of targeted follow-up queries, only when justified:
<scope> AND statusCategory = Done ORDER BY resolutiondate DESC<scope> AND statusCategory != Done AND updated <= -3d ORDER BY updated ASC<scope> AND statusCategory != Done AND assignee is EMPTY ORDER BY priority DESC, updated ASC<scope> AND statusCategory != Done AND priority in (Highest, High) ORDER BY priority DESC, updated ASC<scope> AND statusCategory != Done AND (status = Blocked OR text ~ "blocked" OR labels in (blocked, blocker)) ORDER BY priority DESC, updated ASCDo not make negative claims such as "no blockers" or "no dependencies" unless the source appendix shows the query or returned field coverage that supports the claim. If only status and labels were checked for blockers, say that no status/label blockers were found rather than claiming there are no blockers. If a signal was not checked, say so.
For derived signals, cite the base scope JQL and field coverage in the source appendix instead of inventing separate support queries. Include additional JQL only for targeted follow-up queries that were actually run.
For work item links (issuelinks), fetch linked work item status/category when
possible. If linked details are unavailable, show dependency status as unknown
rather than resolved.
Before designing the output, create a compact renderer-independent work item model with:
Unassignedactive, inactive, unknown, or unassignedDerived signals should stay explainable from Jira facts: done, active, not started, stale, very stale, blocked, unowned, inactive owner, time-sensitive, support-impacting, cross-space dependency, and missing planning data. Mark weak text-only signals as inferred.
Create a dashboard model before rendering. Every renderer should use this same model.
Include:
Needs attention.Do not invent data to fill the model. Empty or unsupported sections should be omitted.
Keep the visible dashboard simple and deterministic. When the data exists, broadly follow this order:
Compact context header
Four-stat top bar
Needs attention should combine the highest-signal risks: blocked, stale,
unassigned, time-sensitive, or unresolved linked work.Scope caveat, only when needed
Capacity or commitment bar
Sprint charts
Owner load and gaps
Risk and attention
Highest-priority work item table
Recently completed and optional detail
Source appendix
Needs attention at the bottom.If the full data set is unavailable, preserve the same broad order and omit the sections or charts that cannot be rendered honestly.
success for done,
warning for stale/deadline risk, danger for blocked/overdue/severe risk,
info for caveats/linked work, and neutral for low-signal facts.For Cursor Canvas:
For interactive artifacts or static HTML:
For Markdown:
Before returning:
cursor/canvas.npx claudepluginhub atlassian/atlassian-mcp-server --plugin atlassianEpic creation and sprint management - create epics, manage sprints, view backlog, estimate with story points. TRIGGERS: 'create an epic', 'create epic', 'new epic', 'show the backlog', 'view backlog', 'add to sprint', 'move to sprint', 'set story points', 'sprint planning', 'epic for', 'link to epic', 'sprint list', 'active sprint', 'velocity', 'create subtask'. NOT FOR: bugs/tasks/stories without epic context (use jira-issue), field ID discovery (use jira-fields), searching issues by JQL (use jira-search), transitioning issues through workflow (use jira-lifecycle).
Interacts with RHDH Jira projects (RHIDP, RHDHPLAN, RHDHBUGS, RHDHSUPP) using acli and GraphQL. Covers the full lifecycle: create issues, assign, refine, plan sprints, report, track releases, update status.
Generates project status reports from Jira issues using JQL, categorizes by status/priority, analyzes blockers/progress, formats for executives/teams, and publishes to Confluence.