Update to Atlassian Rovo

{
  "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.",
  "included_files": [],
  "skill_md_contents": "---\nname: jira-sprint-dashboard\ndescription: >-\n  Create a visual Jira sprint dashboard from Jira project, space, sprint, board,\n  filter, JQL, work item keys, or Jira URL data. Use when the user asks for a\n  Jira sprint dashboard, standup dashboard, sprint review, delivery review,\n  engineering manager dashboard, WIP review, planning view, closeout view, or a\n  visual snapshot of Jira work that is more useful than a flat report. Use the\n  richest dashboard format supported by the current agent, such as Cursor\n  Canvas, an interactive artifact, HTML, or Markdown.\n---\n\n# Jira Sprint Dashboard\n\nBuild a focused dashboard that helps an engineering manager, tech lead, or\nsenior engineer see current Jira work quickly enough to decide what needs\nattention. The output is a dashboard, not a prose report and not a generic\nhealth score.\n\nThis skill is read-only by default. Do not create, update, transition, assign,\nor comment on Jira work items unless the user explicitly asks for a write action\nafter reviewing the dashboard.\n\n## Output Mode\n\nUse the richest dashboard renderer supported by the current environment. The\ndashboard content, claims, counts, and source appendix must stay consistent\nacross renderers; only the presentation changes.\n\nChoose the renderer in this order:\n\n1. Cursor Canvas, if running in Cursor with Canvas support.\n2. Interactive artifact, if the current agent supports HTML, React, or similar\n   artifact output.\n3. Static HTML file, if file creation is available and useful.\n4. Markdown dashboard, if no richer visual renderer is available.\n5. Structured JSON plus concise summary, only if visual rendering is impossible.\n\nDo not mention that Cursor Canvas is unavailable unless the user specifically\nasked for Cursor Canvas. If the user asked for a dashboard generally, use the\nbest available renderer without apologizing for the environment.\n\n## Cursor Canvas Renderer\n\nUse this section only when running in Cursor with Canvas support.\n\nRead `~/.cursor/skills-cursor/canvas/SKILL.md` before writing canvas code. If\nyou need exact exports or prop shapes, read the files in\n`~/.cursor/skills-cursor/canvas/sdk/`.\n\nCanvas constraints:\n\n- Create one `.canvas.tsx` file in the Cursor canvases directory.\n- Import only from `cursor/canvas`. Do not import `react`, `CSSProperties`,\n  `JSX`, Atlaskit, or other packages.\n- Embed Jira data inline in the canvas; do not fetch from the canvas.\n- Prefer Canvas primitives such as `Stack`, `Grid`, `Card`, `Stat`, `Table`,\n  `Pill`, `Callout`, `UsageBar`, `BarChart`, `LineChart`, `PieChart`, and `Code`\n  over raw HTML.\n- Use `useHostTheme()` for custom styles. Do not hardcode hex colors, gradients,\n  box shadows, ADS variables, unsupported CSS frameworks, or `@atlaskit/*`.\n- Do not publish or share the canvas unless the user asks.\n\n## Portable Renderers\n\nUse this section when Cursor Canvas is unavailable.\n\nFor an interactive artifact renderer:\n\n- Render the same dashboard model as an interactive artifact.\n- Prefer tables, compact charts, stat rows, and collapsible source details.\n- Keep interactions lightweight: filtering, expanding details, or switching\n  chart/table views is fine; do not require live Jira fetching from the artifact.\n\nFor static HTML:\n\n- Create a self-contained dashboard file with embedded data.\n- Use responsive layout, accessible tables, and simple chart-like visuals when\n  chart libraries are unavailable.\n- Do not fetch Jira data from the HTML file.\n\nFor Markdown:\n\n- Preserve the dashboard order.\n- Use compact tables for stats, owner load, risks, highest-priority work, and\n  source appendix.\n- Use textual chart substitutes only when they remain honest, such as counts,\n  percentages, and simple bars.\n- Avoid turning the output into a long prose report.\n\nFor JSON fallback:\n\n- Return the normalized dashboard model.\n- Include a short human-readable summary with the highest-signal risks and the\n  source scope.\n\n## Get The Scope\n\nDo not guess the Jira scope. If the user does not provide a project key, space\nkey, board, sprint, filter, JQL, work item keys, or Jira URL, stop and ask for\none. A dashboard from a random visible project or guessed team context is worse\nthan no dashboard.\n\nIf the user gives a project or space key but no sprint, board, or filter, start\nwith the Jira JQL `project` field and the user's key:\n\n```jql\nproject = \"SPACE_KEY\" AND sprint in openSprints() ORDER BY Rank ASC\n```\n\nIf the open sprint result is empty, stale, or misleading, switch to snapshot\nmode and say so in a compact caveat below the top bar:\n\n```jql\nproject = \"SPACE_KEY\" AND statusCategory != Done ORDER BY priority DESC, updated ASC\nproject = \"SPACE_KEY\" AND updated >= -60d ORDER BY updated DESC\n```\n\nUse a 60-day recent movement window by default unless the user asks for another\nperiod.\n\n## Query Jira\n\nUse read-only Jira search. Request only fields needed for the dashboard and\ntolerate missing fields.\n\nUseful fields: `key`, `summary`, `status`, `statusCategory`, `assignee`,\n`priority`, `issuetype`, `created`, `updated`, `resolutiondate`, `duedate`,\n`parent`, `issuelinks`, `labels`, `components`, `fixVersions`, `sprint`, and any\navailable estimate/story point field.\n\nStart with `maxResults: 100`. For complete sprint, board, or filter dashboards,\npaginate until the scope is complete or too large for useful work-item-level\nrendering.\n\nDefault to one complete paginated scope query. Derive ordinary dashboard signals\nlocally from the returned work item set instead of issuing separate JQL calls for\neach signal.\n\nDerive these locally when the scope query returned the required fields:\n\n- Recently completed from `statusCategory = Done` and `resolutiondate`.\n- Aging unfinished from `statusCategory != Done` and `updated`.\n- Unowned unfinished from `statusCategory != Done` and empty `assignee`.\n- High-priority unfinished from `statusCategory != Done` and `priority`.\n- Status or label blockers from `status`, `statusCategory`, and `labels`.\n- Owner load, stale work, due date risk, and planning gaps from the normalized\n  scope dataset.\n\nUse targeted follow-up queries only when they are needed to support a visible\nclaim that cannot be derived safely from the scope data, when the scope is too\nlarge for useful local processing, or when the user asks for an audit-style\ndashboard with exact evidence per signal.\n\nRule of thumb:\n\n- Small or medium sprint dashboard: prefer one full paginated scope query, with\n  at most one targeted blocker-text or dependency-status follow-up when needed.\n- Large scope dashboard: use narrower follow-up queries when pulling and\n  processing the full work-item set would be slow or low-value.\n- Evidence-heavy review: multiple focused queries are acceptable when the exact\n  JQL evidence matters more than minimizing calls.\n\nExamples of targeted follow-up queries, only when justified:\n\n- Recently completed: `<scope> AND statusCategory = Done ORDER BY resolutiondate DESC`\n- Aging unfinished: `<scope> AND statusCategory != Done AND updated <= -3d ORDER BY updated ASC`\n- Unowned unfinished: `<scope> AND statusCategory != Done AND assignee is EMPTY ORDER BY priority DESC, updated ASC`\n- High-priority unfinished: `<scope> AND statusCategory != Done AND priority in (Highest, High) ORDER BY priority DESC, updated ASC`\n- Blocked signal: `<scope> AND statusCategory != Done AND (status = Blocked OR text ~ \"blocked\" OR labels in (blocked, blocker)) ORDER BY priority DESC, updated ASC`\n\nDo not make negative claims such as \"no blockers\" or \"no dependencies\" unless\nthe source appendix shows the query or returned field coverage that supports the\nclaim. If only status and labels were checked for blockers, say that no\nstatus/label blockers were found rather than claiming there are no blockers. If\na signal was not checked, say so.\n\nFor derived signals, cite the base scope JQL and field coverage in the source\nappendix instead of inventing separate support queries. Include additional JQL\nonly for targeted follow-up queries that were actually run.\n\nFor work item links (`issuelinks`), fetch linked work item status/category when\npossible. If linked details are unavailable, show dependency status as unknown\nrather than resolved.\n\n## Normalize\n\nBefore designing the output, create a compact renderer-independent work item\nmodel with:\n\n- Key, URL, summary, type, status, status category, priority\n- Assignee display name or `Unassigned`\n- Owner status as `active`, `inactive`, `unknown`, or `unassigned`\n- Created age, updated age, resolution age when done, due date distance\n- Parent/epic/workstream, sprint, estimate, components, versions, labels\n- Linked work item keys, direction, link type, and linked status when available\n\nDerived signals should stay explainable from Jira facts: done, active, not\nstarted, stale, very stale, blocked, unowned, inactive owner, time-sensitive,\nsupport-impacting, cross-space dependency, and missing planning data. Mark weak\ntext-only signals as inferred.\n\n## Dashboard Model\n\nCreate a dashboard model before rendering. Every renderer should use this same\nmodel.\n\nInclude:\n\n- Context metadata: title, project or space, sprint, board, filter, JQL, window,\n  query timestamp, and mode.\n- Four top stats: committed or total scope, done or completed, active or in\n  progress, and needs attention.\n- Scope caveat, only when sprint data is missing, mixed, stale, or blended with\n  recent project movement.\n- Optional capacity or commitment segments, only when real data exists.\n- Optional chart data, only when categories, values, units, and time ranges are\n  available.\n- Owner load and gaps.\n- Risk and attention items.\n- Highest-priority work item table.\n- Recently completed work.\n- Source appendix with exact JQL, field coverage, assumptions, and the\n  composition of `Needs attention`.\n\nDo not invent data to fill the model. Empty or unsupported sections should be\nomitted.\n\n## Dashboard Shape\n\nKeep the visible dashboard simple and deterministic. When the data exists,\nbroadly follow this order:\n\n1. **Compact context header**\n   - Show title plus project, space, board, sprint, or window metadata.\n   - Keep it short. Do not put queries, field coverage, or executive-summary\n     prose at the top.\n\n2. **Four-stat top bar**\n   - Show exactly four stat values.\n   - Default to committed/total scope, done/completed, active/in progress, and\n     needs attention.\n   - Use work item counts when story points are unavailable.\n   - `Needs attention` should combine the highest-signal risks: blocked, stale,\n     unassigned, time-sensitive, or unresolved linked work.\n   - Put secondary counts below the fold only when they change the readout.\n\n3. **Scope caveat, only when needed**\n   - Use one compact caveat below the top bar when sprint data is missing,\n     mixed, stale, or blended with recent project movement.\n   - Keep it to 1 to 2 short sentences.\n\n4. **Capacity or commitment bar**\n   - Render a capacity or commitment visual only when capacity, commitment, or\n     allocation segment data is available.\n   - Skip it rather than inventing capacity, segment, or buffer values.\n\n5. **Sprint charts**\n   - If available, render remaining work over time as a line chart.\n   - Beside it, render status distribution as a pie chart or compact status\n     visual.\n   - Below those, render resolved/completed per working day as a bar chart.\n   - Skip any chart whose categories, values, units, or time range are missing.\n     Never render placeholder, sample, empty, or guessed charts.\n\n6. **Owner load and gaps**\n   - Show active, stale, blocked, support-impacting, and done counts by assignee.\n   - Include unassigned, inactive-owner, and unknown-owner-status buckets.\n   - Keep it compact; prefer a small table or bar chart over per-owner cards.\n\n7. **Risk and attention**\n   - Place this below owner load.\n   - Include only the work items most likely to need manager or lead attention.\n   - For each item, show key, reason, evidence, owner, age, and next question.\n   - Use a callout or highlighted row for the single highest delivery risk when\n     one stands out.\n\n8. **Highest-priority work item table**\n   - Include a compact table of top sprint work items or top attention items.\n   - Do not render every low-signal work item by default.\n\n9. **Recently completed and optional detail**\n   - If recently completed work exists, put it in a collapsed section or compact\n     table below the main readout.\n   - Workstream grouping and dependencies should appear only when they change\n     what the viewer should inspect next.\n   - Keep dependencies to unresolved or unknown-status linked work by default.\n\n10. **Source appendix**\n    - Put exact JQL, query timestamps, field coverage, assumptions, and the\n      composition of `Needs attention` at the bottom.\n\nIf the full data set is unavailable, preserve the same broad order and omit the\nsections or charts that cannot be rendered honestly.\n\n## Content And Style\n\n- Use charts and tables where they beat paragraphs.\n- Follow the reference layout order when the data supports it; skip unsupported\n  charts instead of changing the whole page shape.\n- Keep work item summaries short; avoid full descriptions unless a short excerpt\n  is needed to explain impact.\n- Tie every recommendation or next question to work item keys or aggregate\n  counts.\n- Separate Jira facts from derived or inferred signals.\n- Use semantic tones where the renderer supports them: `success` for done,\n  `warning` for stale/deadline risk, `danger` for blocked/overdue/severe risk,\n  `info` for caveats/linked work, and `neutral` for low-signal facts.\n- Pair color with labels. Prefer work item key links over large buttons.\n- Keep the first screen focused on status and attention, not process notes.\n\n## Renderer-Specific Style\n\nFor Cursor Canvas:\n\n- Use Canvas components and host theme styles.\n- Keep the top area compact: context header followed by exactly four stats.\n- Prefer Canvas tables and charts over custom layout code.\n\nFor interactive artifacts or static HTML:\n\n- Use a restrained dashboard layout with compact cards, tables, and simple\n  charts.\n- Keep text readable on mobile and desktop.\n- Use accessible labels for chart substitutes and status colors.\n- Keep source details below the main dashboard.\n\nFor Markdown:\n\n- Use short section headings.\n- Prefer tables over paragraphs.\n- Keep caveats and recommendations concise.\n- Put source queries at the bottom.\n\n## Self-Check\n\nBefore returning:\n\n- Scope came from the user or a provided URL; missing or ambiguous scope was\n  clarified before querying.\n- The selected renderer matches the current environment's capabilities.\n- Cursor Canvas instructions were used only when Cursor Canvas is available.\n- If Cursor Canvas was used, the canvas imports only from `cursor/canvas`.\n- The top area is a compact context header followed by exactly four stats.\n- There is no query list, field coverage, or executive summary above the top\n  bar.\n- Ordinary signals were derived from the paginated scope query when possible;\n  targeted follow-up queries were used only when they supported a visible claim\n  that the scope data could not safely support.\n- Counts reconcile with the queried work item set.\n- Empty sections are omitted.\n- Charts are rendered only when their categories, values, units, and time ranges\n  are available.\n- Risk labels are explainable from visible Jira data.\n- Source appendix includes exact JQL and field coverage for visible claims.\n- No Jira write tools were used.\n"
}