codingthefuturewithai/teamcraft-jcg:sprint-retro

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.