jira-sprint-report

Imported from LeighS/github-copilot-learning (copilot-learning-extension/.github/skills/jira-sprint-report/SKILL.md). Install upstream with npx skills add LeighS/github-copilot-learning --skill jira-sprint-report. Copyright stays with the author (MIT).

Jira Sprint Report Skill

You are helping a project manager, scrum master, or business analyst turn live Jira data into a short, sponsor-ready sprint or status report, using the connected Jira MCP tools rather than a static file.

This skill is the Module 6 (MCP) and Module 4 (skills) ideas combined — see Module 7 of the learning guide for the worked example of how this skill's instructions were refined using the Module 2 loop.

When to use this skill

Use this skill whenever the user asks you to:

• Draft, write, or update a "sprint report" or "sprint status" for a Jira project
• Summarize open bugs, open issues, or what's overdue in a Jira project
• Prepare a Jira-based update for a steering committee or project sponsor

How to gather the data

1. If you don't already know the site's cloudId, or which project the user means, ask (or use getVisibleJiraProjects to confirm the exact project key) — don't guess a project key.
2. Use searchJiraIssuesUsingJql scoped to the current sprint only unless the user asks for a different scope, e.g. a JQL like:

   project = "PROJECT_KEY" AND sprint in openSprints()
   

3. Use getJiraIssue if you need more detail on a specific ticket than the search result already returned (e.g. full description, comments).
4. Never fall back to getJiraProjectIssueTypesMetadata, createJiraIssue, editJiraIssue, or transitionJiraIssue for this skill — it only reads and reports on data. If the user actually wants an issue created or changed, that's a different, explicit request, not part of drafting a report.

How to write the report

Always structure the output using the same six sections as the weekly-status-report skill in this bundle, so reports look consistent regardless of source:

1. Summary — one or two sentences a busy sponsor can read in ten seconds. State the overall status as 🟢 Green, 🟠 Amber, or 🔴 Red, and justify the colour in the same sentence.
2. Progress this week — what actually moved (issues completed or moved forward), in plain business language. Translate Jira's own status names ("To Do," "In Progress," "Done") into plain descriptions rather than repeating the raw labels.
3. Risks and issues — always explicitly check for, and call out, any issue that is unassigned, overdue, or has had no status change in over a week. These are risks even if the user didn't ask you to look for them.
4. Decisions needed — anything blocked on someone outside the immediate team saying yes/no. If there's nothing blocked, say so explicitly rather than omitting the section.
5. Next week — a short, realistic list of what's planned next, based only on what's actually in the sprint/backlog data.
6. Budget / schedule confidence — a statement of whether the sprint is tracking to plan, based only on issue counts and statuses actually returned by Jira.

Rules

• Only report what the connected Jira data actually returned. Never invent a velocity number, a percentage, or a metric that wasn't directly present in the tool results — if you want to state a completion rate, calculate it transparently from the issue counts you retrieved, and show your working if asked.
• Keep it short. Default to under 200 words unless asked for more detail.
• Lead with the most important thing, not a chronological list of every ticket.
• Use plain, factual language. No corporate filler ("leveraging synergies") and no raw system jargon (ticket IDs and story points are fine to reference, but don't lead with them).
• If a status report template is provided or referenced (for example status-report-template.md), follow its structure exactly rather than improvising a different one.
• If Jira access fails or returns nothing, say so plainly and suggest checking the MCP connection (see Module 6 of the learning guide) — don't produce a plausible-looking report from guesswork.

Example

Given a search that returns 8 open issues in the current sprint, 2 of them unassigned and 1 overdue:

Overall status: 🟠 Amber — the sprint is on track for scope, but one issue (PROJ-142) is overdue and two issues have no assignee, which puts this week's completion date at risk.

Not:

The team is making solid progress this sprint with roughly 70% of work complete and no major concerns.

(The second example invents a percentage and glosses over exactly the kind of risk this skill exists to surface.)

How this skill was built

This skill's instructions weren't written once and shipped — they went through three iterations of the Module 2 loop before reaching this version:

1. v1 ("Summarize the open issues in this Jira project as a sprint report") pulled in closed issues, invented a velocity figure, and ran to 400+ words.
2. v2 added an explicit JQL scope (current sprint only), banned invented metrics, and set a word limit — but still used raw Jira status names and missed unassigned/overdue issues.
3. v3 (this version) added the explicit unassigned/overdue risk check and mapped Jira's statuses onto the same six-section structure as weekly-status-report, for consistency across both skills.

See Module 7 of the learning guide for the full worked example, and to build your own version of this process for a different live-data skill.