Use this when the iteration just ended and you want to generate a sprint report from GitHub commits and merged PRs instead of manual self-reports. More accurate than asking engineers what they worked on, and reduces reporting overhead.
Process
Step 1: Gather inputs
Ask the user to provide:
- Date range — iteration start and end dates (e.g., "Feb 24 – Feb 28")
- Repository — which repo(s) to pull from (name or URL)
- Iteration goal — what the team set out to accomplish this week
- Planned stories — the stories or tickets that were committed to (list with IDs if available)
- Any non-code context — retro highlights, demo feedback, learnings, risks (commits won't capture these)
If the user has GitHub MCP connected, pull the data directly. Otherwise, ask them to paste the output of:
git log --oneline --since="(start date)" --until="(end date)" --merges
or a list of merged PRs from the GitHub UI.
Step 2: Analyze commits and PRs
For each merged PR or significant commit:
- Summarize what it delivered — in user-facing terms, not technical jargon
- Note referenced tickets — extract ticket/story IDs from PR titles, branch names, or commit messages
- Group related changes — multiple commits or PRs that serve the same feature should be one "Delivered" item
Step 3: Cross-reference against the plan
Compare the commit activity against the iteration plan:
- Delivered — planned stories with matching commits/PRs (confirmed shipped)
- Carried over — planned stories with no matching commits (not started or still in progress)
- Unplanned work — commits that don't match any planned story (bugs, tech debt, ad-hoc requests)
Flag open PRs separately — work in review is not the same as work that shipped.
Step 4: Generate the report
Use the same format as /sprint-report:
Iteration Report — (Date range)
Source: Generated from GitHub commits and merged PRs
Summary
(2-3 sentences: what we accomplished and the key takeaway. This is the part the user should write or heavily edit — commits tell you what, not why.)
Delivered
- (Item 1 — described in user-facing terms. Reference: PR #X, Story #Y)
- (Item 2)
- (Item 3)
Carried Over
- (Story 1 — no matching commits found. Why: (ask the user — was this deprioritized, blocked, or still in progress?))
- (None — if everything planned was shipped)
Unplanned Work
- (Item 1 — commits that don't match planned stories. Describe what it was and why it happened if known.)
- (None — if all work was planned)
Key Learnings
(The user fills this in — commits don't capture learnings. Prompt them for: research findings, technical discoveries, process insights.)
Next Iteration Preview
(Current plan — what the team intends to work on next week.)
Risks & Needs
(Specific, actionable — what could slow the team down and what's needed from stakeholders.)
Step 5: Review and enrich
Ask the user:
- Are the delivered items accurate? (Is everything listed actually deployed, not just merged?)
- For carried-over items: what happened? (Deprioritized? Blocked? Underestimated?)
- Any unplanned work that's missing? (Not all work shows up in commits — meetings, research, design reviews.)
- What were the key learnings this iteration? (The most valuable part of the report, and the part commits can't provide.)
- Does the summary narrative reflect what actually mattered this week?
Adjust based on feedback.
Related skills
/sprint-report— the manual version, for when commits aren't the right data source
Output location
Present the report as formatted text in the conversation for the user to share via email, Slack, or their preferred channel.
Example Output
Input
- Date range: March 10 – March 14, 2025
- Repository: github.com/luminary-health/patient-portal (main branch)
- Iteration goal: Launch secure messaging between patients and care teams, and unblock the mobile app release by resolving the iOS auth token bug
- Planned stories: PORTAL-204 (Secure messaging inbox UI), PORTAL-205 (Message send/receive API), PORTAL-211 (Push notification on new message), PORTAL-198 (iOS auth token refresh bug)
- Merged PRs (pasted from GitHub):
- PR #312 — "feat(PORTAL-204): render inbox thread list with read/unread state"
- PR #318 — "feat(PORTAL-205): POST /messages endpoint with provider threading"
- PR #321 — "fix(PORTAL-198): resolve token expiry race condition on iOS 17"
- PR #325 — "chore: upgrade axios 1.6 → 1.7.2 (CVE-2024-39338)"
- PR #327 — "fix: correct date formatting bug in appointment reminders (reported by UAT)"
- Non-code context: Demo to the clinical ops team on Thursday went well — they flagged that message attachments (photos) will be a hard requirement before rollout; push notifications (PORTAL-211) were descoped mid-sprint when we discovered APNs certificate provisioning needs InfoSec sign-off
Output
Iteration Report — March 10 – 14, 2025
Source: Generated from GitHub commits and merged PRs — luminary-health/patient-portal
Summary
The team delivered the core secure messaging feature: patients can now view their inbox and exchange messages with their care team through a working API. The iOS auth token bug blocking mobile release was also resolved. Push notifications were descoped due to a dependency on InfoSec, and the clinical ops demo surfaced a new requirement (message attachments) that will need to be scoped before production rollout.
Delivered
- Secure messaging inbox — Patients can view message threads with read/unread state rendered correctly in the UI. (PR #312, PORTAL-204)
- Message send/receive API — Backend endpoint live; supports threaded conversations grouped by provider. (PR #318, PORTAL-205)
- iOS auth token fix — Resolved a race condition causing token expiry failures on iOS 17, unblocking the pending mobile release. (PR #321, PORTAL-198)
- Security dependency patch — Upgraded axios to address CVE-2024-39338. Low user-facing impact; important for compliance posture. (PR #325, unplanned)
- Appointment reminder date formatting fix — Corrected a display bug surfaced during UAT; dates now render consistently across timezones. (PR #327, unplanned)
Carried Over
| Story | Description | Status |
|---|---|---|
| PORTAL-211 | Push notifications on new message | Descoped — APNs certificate requires InfoSec sign-off. Ticket moved to backlog pending approval. |
Unplanned Work
- Axios CVE patch (PR #325) — Security advisory required immediate action; took ~2 hours. Not on the sprint plan but the right call.
- Appointment reminder bug fix (PR #327) — Reported by UAT team during the week. Estimated ~half a day. Consider whether UAT-reported bugs need a standing buffer in future sprints.
Key Learnings
Commits don't capture this — please fill in before sending. Prompts to consider:
- The clinical ops demo revealed that message attachments are a hard requirement before rollout — this wasn't in the original scope. How do we tighten requirements discovery earlier in the process?
- APNs provisioning hit a wall with InfoSec. Are there other infrastructure dependencies in the backlog that have similar approval gates we haven't surfaced yet?
Next Iteration Preview
- PORTAL-211 (Push notifications) — resume once InfoSec APNs approval is confirmed
- PORTAL-229 (Message attachment support — photo upload) — newly flagged as pre-launch requirement
- PORTAL-215 (Care team availability display in messaging thread)
- Mobile release coordination pending iOS fix validation in staging
Risks & Needs
- Attachment scope may delay launch — Clinical ops consider this a hard requirement. Need product and clinical ops aligned on whether to delay GA or ship messaging without attachments by end of next week.
- InfoSec APNs dependency — PORTAL-211 is blocked until certificate provisioning is approved. Owner: @dana.reyes to follow up with InfoSec before March 17.
- UAT feedback loop — Two unplanned bug fixes originated from UAT this sprint. Recommend scheduling a mid-sprint UAT sync to catch these earlier.
Are the delivered items accurate as shipped to production, or were any merged but not yet deployed? And for the Key Learnings section — what's the one thing the team would do differently next sprint?