Sprint health digest

Standup with the homework done: the issues that have not moved, the pull requests waiting on review, the scope that crept in since planning - one digest, with links, before the team joins the call.

Talk to us Read the docs

The brief

Written like you’d brief a person.

This is the whole setup - a procedure in plain language, with tools and specialist agents referenced inline. When it runs is not written here: that’s the trigger, configured beside it.

List the sprint's issues with #yekar.linear.list-issues, the open pull requests with #yekar.github.list-pull-requests, and the commits since yesterday with #yekar.github.list-commits. Flag issues with no movement for two days, reviews waiting over a day, and work added since planning; post the digest with #yekar.slack.send-message. Never change an issue's state or assignee.

How it runs

From trigger to logged outcome.

Trigger

Schedule - Every weekday, thirty minutes before standup

Read the sprint
Every issue in the cycle, its state, owner and last update.
Correlate the code
Pull requests and commits matched to the issues they serve.
Flag the stalls
No movement, no owner, or a review waiting too long.
Note the scope change
What was added or dropped since planning, so it gets said out loud.
Post the digest
Links, owners, and the two or three questions worth the meeting.

Where people stay in control

Nothing consequential runs on its own.

The agent reports; it never re-assigns, re-prioritises or closes an issue.
Retrospective suggestions are proposals for the team, not rules it applies.

Tools it uses

Runs on accounts you already have.

Linear
GitHub
Slack

Connected once, governed per agent - this use case gets only the tools listed here.

Illustrative savings

$400–$1,000 / month

Assumes 2–4 teams whose leads spend 15–25 minutes a day assembling standup and sprint status.

Illustrative monthly savings, estimated from typical handling time at public salary benchmarks, reviewed August 2026. Not a promise or a guarantee - your numbers depend on volume and process.

What makes this dependable

Put it to workRun recurring work on the business's clock Connect its toolsTell safe reads from consequential writes Operate and improveTrace every trigger attempt

All use cases →