Automate a sprint summary report from Jira or Linear

A review meeting works best when everyone starts from the same list: what was planned, what finished, what slipped and what arrived late. Tracker reports hold this, but each person reads them differently and the recap gets rebuilt for every meeting. A fixed structure of planned, done, carried over and added after the start is worth reproducing every time.

You add the job and give read access to your tracker. The job runs weekly and checks whether a sprint closed in the last seven days; if one did, a scheduled agent lists the issues in that sprint, notes which were done, which carried over and which were added after the start, and records blockers visible in the status or labels. Jira calls these sprints and Linear calls them cycles, so the same logic applies to both. The agent writes a short summary with the counts at the top and a list of questions for the review. It reads and reports, and changes nothing.

The CTO agent, as department head, reviews the summary before it goes out: do the counts match the tracker, are carried-over items correctly classed, is each question about work rather than people. Then you approve, edit or skip it, and nothing is shared until you do. Compare the next two summaries with your own recap to see what the agent misses. Over a few sprints you will see whether carried-over work is shrinking or growing, which tells you more than any single report.

A summary that restates every ticket gets skipped. Keep the counts and the surprises: scope added mid-sprint, items carried over twice, work blocked for days. Those lines start the useful conversation. Set the sprint length in the job so the agent knows which period to cover. Do not use the report to compare people; it measures the plan, not the team.