teamcraft-glgd: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 Drive document that becomes part of the project's history and informs sprint planning for the next cycle.

## Hard Constraints

- The `teamcraft-glgd:retro-analyzer` agent does the data gathering — pass it the milestone data from GitLab API calls, not file paths. The skill reads the GitLab 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.
- If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.
- This skill uses the Task tool to invoke the `teamcraft-glgd: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.

## Resolve Drive Account

Call `mcp__google-drive__list_accounts` before any other Drive operation:
- **No accounts** — Drive is not configured for this user. Tell them and skip Drive operations.
- **One account** — Use it. Pass `account_email` explicitly on every Drive tool call this session.
- **Multiple accounts** — Present the list, ask which account to use for this session. Pass that `account_email` on every Drive tool call.

If any Drive call returns a permission error, surface it: the active account may not have access to that file or folder. Offer to try another account if one is available.

## Identify the Project

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

## Identify the Sprint

Ask the user which sprint to retrospect — the milestone name or ID. If they don't know it off the top of their head, use `mcp__gitlab__list_milestones` to show available milestones for the confirmed project and let them select. Do not assume which sprint to use.

## Load Sprint Data

From GitLab, gather:
- All issues assigned to the milestone (IID, title, state, labels, assignees, `created_at`, `updated_at`, `closed_at`)
- All MRs associated with the milestone (IID, title, state, pipeline status, associated issue IIDs, `created_at`, `updated_at`, `merged_at`)
- Milestone details (start date, end date, name, goal/description)

## Run the Retro Analyzer

Use the `teamcraft-glgd:retro-analyzer` agent via the Task tool. Pass all the gathered data embedded in the task prompt:
- GitLab project namespace and numeric project ID
- Milestone ID, name, start date, end date
- The full issue list with state, labels, assignees, and timestamps (`created_at`, `updated_at`, `closed_at`)
- The full MR list with state, pipeline status, associated issue IIDs, and timestamps (`created_at`, `updated_at`, `merged_at`)
- The project's default branch name

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 Drive — if yes, ask the user to point at it or search Drive, then update it. If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.

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 where in Google Drive to store it — which folder. Never save to the Drive root. Do not search Drive for a location; ask the user directly. Record the URL.

## 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, ask them to point at the PRD in Drive and update the relevant sections.

## Close the Milestone

After the retro document is stored and any PRD updates are complete, offer to close the GitLab milestone:

> "The retrospective is complete. Would you like me to close the GitLab milestone '[milestone name]'? This marks the sprint as finished in GitLab — closed milestones are still visible but no longer active."

If yes, use `mcp__gitlab__edit_milestone` with `state_event: "close"` to close the milestone. Confirm success.

If no, leave the milestone open — the user may have reasons to keep it active.

## Done

Share the Drive 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.