From commcare-tech
Prepare for the next sprint. Reviews your board and drafts your sprint plan message.
npx claudepluginhub dimagi/dimagi-claude-workflows --plugin commcare-techThis skill uses the workspace's default tool permissions.
Review the engineer's current and next sprint boards, flag anything that needs attention, and draft a sprint plan message for the Slack channel defined in Constants.
Generates structured sprint brief from Jira data, goals, tickets, owners, dependencies, and carry-overs. Groups by theme, identifies critical path, flags risks.
Recommends sprint scope by pulling backlog from Jira/Linear MCP or manual input, calculating team capacity from velocity and availability, and suggesting committed work, stretch goals, and deferred items.
Plans sprints by estimating capacity (PTO/meetings), prioritizing backlog, setting goals, identifying risks, and generating markdown plans. For kickoffs, sizing against availability, P0 decisions, carryover.
Share bugs, ideas, or general feedback.
Review the engineer's current and next sprint boards, flag anything that needs attention, and draft a sprint plan message for the Slack channel defined in Constants.
$ARGUMENTS — The engineer's name (for Jira lookup) or just run with no arguments to self-assign. Examples:
/sprint-prep (uses current authenticated user)/sprint-prep Graham/sprint-prep help (shows what this command does)SAASdbff467f-3c3f-4ced-a2ba-a29e1941edd6customfield_1001097https://dimagi.atlassian.net/browse/#commcare-tech-sprint-grooming-and-planningC08FEMC126LThe CommCare Tech team runs two-week sprints named with sequential letters (e.g., Sprint U, Sprint V, Sprint W). Each sprint cycle has two parallel sprints in the SAAS project:
Sprint names follow the pattern: CommCare [Product|Platform] [Letter] [(dates)]
| Status | Category | Meaning |
|---|---|---|
| Prioritized | To Do | Ready to be worked on but not started |
| In Progress | In Progress | Actively being worked on |
| In Review | In Progress | PR is up, awaiting review or QA |
| Accepted | Done | Work is complete and merged |
| Deployed | Done | Live in production |
| Won't Do | Done | Intentionally not doing |
$ARGUMENTS is empty or not provided, use atlassianUserInfo to get the current authenticated user's account ID and display name.$ARGUMENTS is a name, use lookupJiraAccountId with the cloud ID to resolve their account ID.$ARGUMENTS is "help", explain what this command does and exit.Store the resolved accountId and displayName for use in all subsequent queries.
Search for active sprints using JQL:
project = SAAS AND sprint in openSprints() ORDER BY created DESC
Fetch at least 5 results. Extract sprint data from customfield_10010 on each issue. Identify:
Also search for future sprints by looking for sprints in the next letter. Use JQL:
project = SAAS AND sprint in futureSprints() ORDER BY created DESC
Fetch at least 5 results. Identify:
If future sprints aren't created yet, note this and skip next-sprint analysis.
For each active sprint the engineer has tickets in, query:
project = SAAS AND assignee = "<accountId>" AND sprint = <sprint_id> ORDER BY status ASC
Run separately for Platform and Product sprints.
For each ticket, capture the ticket key, summary, and current status. Do not display the raw ticket list to the engineer — use this data internally to prepare for steps 4 and 7.
For each next sprint (Platform and Product), query:
project = SAAS AND assignee = "<accountId>" AND sprint = <next_sprint_id> ORDER BY status ASC
Summarize what's already lined up. If the next sprint is empty for this engineer, flag it:
⚠️ No tickets in the next [Platform|Product] sprint. You may need to pull from the backlog or create tickets for planned work.
Ask the following four questions one at a time, waiting for the engineer's response after each before proceeding to the next.
Question 1 — Highlights: Group the completed and in-review tickets into thematic categories (up to 5, but could be just 1 if the work was focused). Include tickets with status Accepted, Deployed, or In Review — if a PR is up, the engineering work is done and it counts as a highlight. Present those categories — not individual tickets — and ask:
Here's what you completed this sprint. Which of these do you want to highlight?
• Category A — brief description • Category B — brief description
Wait for response. When the engineer selects a category, note the individual tickets in that category for use in the draft.
Question 2 — Carryovers and why: Show the tickets still in progress (In Progress or Prioritized/not started) and ask. In Review tickets are already covered as highlights above — only include them here if they've been in review for an unusually long time and might genuinely be stuck:
Are any of these tickets at risk of rolling over? If so, what's blocking them or slowing them down?
• SAAS-AAAAA (In Progress): summary • SAAS-BBBBB (Prioritized): summary
Wait for response.
Follow-up if the answer is thin: If the engineer identifies tickets at risk but doesn't explain why (e.g., they just say "yes, SAAS-12345" or "that one might roll"), follow up and ask what's making it hard to finish — is it waiting on review, blocked by another team, more complex than expected, etc. The "why" is the most important part of the sprint update because it's what helps others reading the message understand where they can jump in. Don't be pushy, but do ask once.
Wait for response.
Question 3 — Next sprint highlights: If the engineer has no tickets in the next sprint, warn them but continue:
⚠️ No tickets assigned in the next sprint yet. This might be intentional, but wanted to flag it.
If there are tickets, group them into thematic categories (up to 5, could be just 1) and ask:
Here's what's lined up for next sprint. Anything you want to call out?
• Category A — brief description • Category B — brief description
Wait for response. When the engineer selects a category, note it for use in the draft summary sentence.
Question 4 — Upcoming challenges: Ask:
Anything coming up that could impact next sprint? PTO, team members offline, dependencies on other teams, etc.?
Wait for response. This is about forward-looking risks — things that haven't blocked work yet but might. If they mention something, weave it into the draft message.
After all four responses are collected, proceed to draft the message.
Using the engineer's selected highlights and the data collected, draft a four-section message.
Format:
**Highlights from the last sprint**
Summary sentence here.
• [SAAS-XXXXX](https://dimagi.atlassian.net/browse/SAAS-XXXXX): One-line description of what was accomplished
• [SAAS-YYYYY](https://dimagi.atlassian.net/browse/SAAS-YYYYY): One-line description
**What might carry over**
Summary sentence here — this should clearly state WHY these are at risk.
• [SAAS-ZZZZZ](https://dimagi.atlassian.net/browse/SAAS-ZZZZZ): Brief note on status / why it's carrying over
**What I plan to work on in the next sprint**
Summary sentence here.
• [SAAS-AAAAA](https://dimagi.atlassian.net/browse/SAAS-AAAAA): Short description
• [SAAS-BBBBB](https://dimagi.atlassian.net/browse/SAAS-BBBBB): Short description
**Upcoming challenges**
Forward-looking risks — PTO, dependencies, team availability, etc. If the engineer said nothing, write "None".
Important: When sending to Slack via the API, use \n\n (double newline) between each section. Slack collapses single newlines, so you need two to get visible spacing between sections.
Rules for the draft:
**bold** syntax (double asterisks) for section headers. Single * renders as italic in Slack's API.Output the full report in this order:
1. Ask for highlights (step 7 above) — wait for response.
5. Draft Sprint Plan Message
The message should be split into two parts for Slack:
Part 1 — Channel message (TLDR): A short natural-language summary (2-3 sentences max). No prefix or label — just jump straight in. This is the message people actually read in the channel, so it needs to do real work. Structure it like this:
Write it conversationally — this should read like something a person would actually type in Slack, not a formal report. If nothing is at risk, keep it simple and just cover highlights + what's next. This is posted directly in the channel.
Part 2 — Thread reply (full update): The detailed sprint plan, posted as a reply in the thread of the TLDR message.
## TLDR (posted in channel)
[Natural language summary — vary the phrasing every time. Don't use a fixed template or start with the same words. Just write it like a person would.]
## Full Update (posted as thread reply)
**Highlights from the last sprint**
Summary sentence here.
• [SAAS-XXXXX](...): What was accomplished
**What might carry over**
Summary sentence here.
• [SAAS-YYYYY](...): Still in progress — brief status
**What I plan to work on in the next sprint**
Summary sentence here.
• [SAAS-ZZZZZ](...): Planned work
**Upcoming challenges**
Forward-looking risks — PTO, dependencies, team availability, etc.
6. Ask for confirmation
Anything you want to add, remove, or change before you post this?
/jira-ticket or do it manually.