teamcraft-jcg:sprint-retro

What this skill does

## Goal

Produce a retrospective report that captures what the team learned in this sprint — what worked, what didn't, what to keep doing, and what to change. The data analysis is automated; the insights come from the team. Both go into a Confluence page that becomes part of the project's history and informs sprint planning for the next cycle.

## Hard Constraints

- The `teamcraft-jcg:retro-analyzer` agent does the data gathering — pass it the sprint data from API calls, not file paths. The skill reads the data and embeds it in the agent task prompt.
- Do not write the retrospective document until the team conversation is complete and the developer confirms the contents.
- This skill uses the Task tool to invoke the `teamcraft-jcg:retro-analyzer` agent. The retro-analyzer works purely from the data passed in the task prompt — no filesystem access required. It works in Claude Code and Claude Cowork.
- Use sprint listing tools to surface sprints from the board before asking the user — never demand the exact name cold.

## Identify the Project

Use `mcp__sooperset-mcp-atlassian__jira_get_all_projects` to see what is visible, surface the results, and ask the user which Jira project this retrospective is for. Never assume. Confirm once identified.

## Identify the Sprint

Use `mcp__sooperset-mcp-atlassian__jira_get_agile_boards` to find the project's board, then `mcp__sooperset-mcp-atlassian__jira_get_sprints_from_board` to list sprints. Surface the sprint names (especially closed/completed sprints) and ask the user to confirm which sprint to retrospect. Confirm the sprint name before proceeding.

## Load Sprint Data

Use `mcp__sooperset-mcp-atlassian__jira_get_sprint_issues` to get the sprint's complete issue list. Supplement with `mcp__sooperset-mcp-atlassian__jira_search` for additional detail:

- JQL: `project = PROJ AND sprint = "[Sprint Name]" ORDER BY status ASC`
- For each issue: key, summary, status, issue type, assignee, priority, `created`, `updated`, `resolutiondate`

Sprint start and end dates are available from the sprint data returned by `jira_get_sprints_from_board`. Use these for cycle time calculations and the retro document header.

For PR data: Try in this order — (1) `gh pr list --state all --json number,title,state,createdAt,mergedAt,headRefName` via Bash, filtered by sprint date range; (2) if Bash is unavailable, use a GitHub MCP connector if one is configured; (3) if neither is available, omit PR data — note the gap and proceed with Jira-only data for the retrospective.

For pipeline data: `gh run list --limit 30` via Bash only — no MCP equivalent for GitHub Actions. If Bash is unavailable, omit CI/CD data and note it.

The GitHub repo is identified from `git remote -v` via Bash if available. If Bash is unavailable, read it from `.teamcraft/project.md` or ask the user. The Jira project key comes from `.teamcraft/project.md` if it exists.

## Run the Retro Analyzer

Use the `teamcraft-jcg:retro-analyzer` agent via the Task tool. Pass all the gathered data embedded in the task prompt:
- Jira project key and name
- Sprint name, start date, end date (as provided by the user)
- The full issue list with status, issue type, assignee, and timestamps (`created`, `updated`, `resolutiondate`)
- The full PR list with state and timestamps (`createdAt`, `mergedAt`)
- Pipeline/workflow run data

The agent returns a structured data report. Present the key metrics to the team as the factual starting point for the conversation.

## Facilitate the Retrospective

Guide a focused team conversation. The data report opens the discussion — the team provides the interpretation and insights.

Cover what matters for this team and this sprint. Natural areas:
- **What went well** — practices, patterns, or decisions worth preserving
- **What didn't work** — friction, delays, surprises, or decisions to revisit
- **Velocity and capacity** — was the sprint appropriately loaded? What does the data say about throughput?
- **Deviations that matter** — were there plan deviations from this sprint that should change how the team plans or estimates next time?
- **Conventions or patterns that emerged** — did the team establish any new practices during this sprint that should be documented?

This is a conversation, not a form to fill out. Follow the team's energy. Don't rush through areas that generate good discussion. Skip areas that have nothing useful to say.

## Capture Emerging Conventions

If the team identifies new conventions or standards that emerged during this sprint (a testing pattern, a code organization decision, an API design choice), note them explicitly. Ask whether to update the conventions document in Confluence — if yes, use `mcp__sooperset-mcp-atlassian__confluence_search` to find it by title, or use the page ID from `.teamcraft/project.md` if recorded there, then update it with `mcp__sooperset-mcp-atlassian__confluence_update_page`. When fetching a page, use the page ID from search results — do not ask the user for local paths.

Similarly, if CLAUDE.md should be updated to reflect what the codebase now looks like (new patterns established during this sprint, for example), note that for the developer to action in Claude Code.

## Produce the Retrospective Document

Compose the retrospective document:
- Sprint name, dates, and completion rate from the data
- Key metrics summary from the retro-analyzer report
- What worked, what didn't work, and what to try next — from the team conversation
- Action items: specific, owned, with a target sprint if applicable
- Any conventions or patterns captured

Show the complete document for review. Do not store until the user confirms.

Ask the user which Confluence space to store the retro under. Use `mcp__sooperset-mcp-atlassian__confluence_search` if they need help identifying available spaces. Once the space is confirmed, use `mcp__sooperset-mcp-atlassian__confluence_get_page_children` to browse its structure and recommend a specific parent page location based on what already exists — if no suitable parent exists, recommend creating one. Confirm the location before creating with `mcp__sooperset-mcp-atlassian__confluence_create_page`.

## PRD Drift Check

Before closing, surface any requirements that emerged during this sprint that are not reflected in the PRD. Look at issues created during the sprint — especially those added after the sprint started — and assess whether they represent new scope, changed requirements, or discovered constraints that should be in the PRD.

If drift is found, flag it:

> "These issues created during this sprint may represent scope not in the current PRD: [list]. If any represent real requirement changes, the PRD should be updated before the next sprint so agents plan from accurate requirements."

Ask whether the user wants to update the PRD now as part of closing the sprint. If yes, search for the PRD in Confluence via `mcp__sooperset-mcp-atlassian__confluence_search` and update the relevant sections.

## Close the Sprint

After the retro document is stored and any PRD updates are complete, remind the user to close the sprint in Jira:

> "The retrospective is complete. One last step: close the sprint in Jira. The Atlassian MCP doesn't support closing sprints programmatically — you'll need to do this in the Jira board UI: go to your board, click 'Complete Sprint' (or the equivalent in your Jira version). This moves incomplete issues back to the backlog and marks the sprint as finished."

This is informational — do not block on it. If the user says it's already done or they'll do it later, move on.

## Done

Share the Confluence page URL. The sprint is closed. The natural next step is planning the next sprint — with this sprint's retrospective and any PRD updates as additional input alongside the backlog.