Write the sprint recap from what actually happened
A recap grounded in the tracker rather than in what people remember. Built for whoever writes the recap on Friday from a half-remembered week.
Linear
Notion
4 steps2 integrationsRuns weekly
The recap is reconstructed from memory. What it costs while the work is still done by hand.
- 01The recap is reconstructed from memory and the tracker.
- 02Carried-over work quietly disappears from the story.
- 03Everyone writes it in a different format.

Read closedsprint 24 · 31 issues done
Read carried7 open · 2 blocked
- Build recapshipped, carried, blocked
Publish notescreate_page · Sprint 24 recap
One workflow, four steps. ModuleX drafts this graph from a single sentence, and every step stays editable.
- 01Read what closed in the sprint.
Linear
- 02Read what carried over and why it is still open.
Linear
- 03Assemble the recap: shipped, carried, and blocked.ModuleX
- 04Publish it where the team keeps its notes.
Notion
The workflow is an editable graph. Reading runs freely; publish it where the team keeps its notes waits for your opt-in approval until you loosen it. The graph is the receipt.
Recapped from the record. Paste this into ModuleX chat, or hit Use this workflow.

write the sprint recap from what actually happened: read what closed in the sprint; read what carried over and why it is still open; assemble the recap: shipped, carried, and blocked; publish it where the team keeps its notes. Ask me before anything is sent or written.
to: composerOr skip the workflow entirely. Ask the assistant in chat and it runs the same job agentically: it picks the right actions, chains them, and reports back. The composer is for when you want it repeatable.

Write the sprint recap from what actually happened. A recap grounded in the tracker rather than in what people remember.
linear · search_issues
notion · create_page
A recap grounded in the tracker rather than in what people remember.
Where this fits. The tools it runs on, and the teams that run it.
Keep the momentum. Nearby workflows that reuse the accounts you just connected.
Check database health without opening the dashboardA short, regular status that tells you when something moved out of range, and stays quiet otherwise. Built for a small team with no dedicated operations engineer.
Put an external MCP server to workA tool that was not in the catalog, usable in the same place as the 175+ that are. Built for teams with internal tools that no catalog will ever cover.
Start the day knowing what moved in the repoA short brief showing what shipped and what is waiting on a person. Built for an engineering manager reconstructing yesterday from notifications.
About this use case.
No. It reports what closed and what did not.