/jira-sprint-dashboard

name: jira-sprint-dashboard
description: >-
  Create a visual Jira sprint dashboard from Jira project, space, sprint, board,
  filter, JQL, work item keys, or Jira URL data. Use when the user asks for a
  Jira sprint dashboard, standup dashboard, sprint review, delivery review,
  engineering manager dashboard, WIP review, planning view, closeout view, or a
  visual snapshot of Jira work that is more useful than a flat report. Use the
  richest dashboard format supported by the current agent, such as Cursor
  Canvas, an interactive artifact, HTML, or Markdown.

Jira Sprint Dashboard

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.

Output Mode

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:

1. Cursor Canvas, if running in Cursor with Canvas support. 2. Interactive artifact, if the current agent supports HTML, React, or similar artifact output. 3. Static HTML file, if file creation is available and useful. 4. Markdown dashboard, if no richer visual renderer is available. 5. Structured JSON plus concise summary, only if visual rendering is impossible.

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.

Cursor Canvas Renderer

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:

• Create one `.canvas.tsx` file in the Cursor canvases directory.
• Import only from `cursor/canvas`. Do not import `react`, `CSSProperties`,

`JSX`, Atlaskit, or other packages.

• Embed Jira data inline in the canvas; do not fetch from the canvas.
• Prefer Canvas primitives such as `Stack`, `Grid`, `Card`, `Stat`, `Table`,

`Pill`, `Callout`, `UsageBar`, `BarChart`, `LineChart`, `PieChart`, and `Code` over raw HTML.

• Use `useHostTheme()` for custom styles. Do not hardcode hex colors, gradients,

box shadows, ADS variables, unsupported CSS frameworks, or `@atlaskit/*`.

• Do not publish or share the canvas unless the user asks.

Portable Renderers

Use this section when Cursor Canvas is unavailable.

For an interactive artifact renderer:

• Render the same dashboard model as an interactive artifact.
• Prefer tables, compact charts, stat rows, and collapsible source details.
• Keep interactions lightweight: filtering, expanding details, or switching

chart/table views is fine; do not require live Jira fetching from the artifact.

For static HTML:

• Create a self-contained dashboard file with embedded data.
• Use responsive layout, accessible tables, and simple chart-like visuals when

chart libraries are unavailable.

• Do not fetch Jira data from the HTML file.

For Markdown:

• Preserve the dashboard order.
• Use compact tables for stats, owner load, risks, highest-priority work, and

source appendix.

• Use textual chart substitutes only when they remain honest, such as counts,

percentages, and simple bars.

• Avoid turning the output into a long prose report.

For JSON fallback:

• Return the normalized dashboard model.
• Include a short human-readable summary with the highest-signal risks and the

source scope.

Get The Scope

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.

Not every board supports sprints. Team-managed boards of type `simple` have no sprints at all: `sprint in openSprints()` returns nothing and a board-sprint lookup fails with "The board does not support sprints". Treat that as a signal to go straight to snapshot mode rather than an error worth retrying.

Query Jira

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.

**Sprint and story points live in custom fields, which the default response omits.** Jira search defaults to a compact view, so a sprint dashboard built from it will look sprint-less even when the sprint is active. To get them, either pass `view: "evidence"` (or `"full"`), or request this site's `customfield_*` IDs explicitly — the IDs differ per Cloud site. Custom field values come back under `fields.customFields`, not as top-level `customfield_*` keys.

Start with `maxResults: 100`. For complete sprint