You have one evening. Who is waiting on you?

You finally have an evening for your projects. Before you have written a line you are in six tabs, reading a thread from May, trying to work out whether that pull request still needs you. Forty minutes later the evening is gone, and the person who sent the fix still has not heard from you.

That is the maintainer's real problem. Not motivation. Not even time. The reading comes before the doing, and the reading is where the evening goes.

Three questions, in that order

Every returning maintainer asks the same three things. How do I make the most of tonight? What should I start with? Who is waiting on me?

Standup answers them from a GitHub handle. Type it, wait about a minute, and you get a brief: one line on what is still standing, then one to three things to do, each with the evidence it saw and the minutes it will take. A stranger's account, trekhleb: twelve public repositories read in 52 seconds, three people waiting for a reply, named, with their pull request numbers.

Play demo

The recording opens on the in-app hero, so it can look like a static banner until playback.

People first is a rule, not a mood

The ordering is the product. Anything a person is waiting on comes before anything that only costs you. Then whatever will be lost or painful later: unpushed work, a branch going stale. Then the thread you were pulling when you stopped. Bots are named and set aside; a Dependabot pull request is never someone waiting.

Why that order? Because a reply is what keeps a contributor close, and silence, even the unintended kind, is how they drift away. A project's health starts with communication, so the tool puts the human before the housekeeping. Every time.

It never tells you off

People leave projects because life happens. So the brief opens with what is in good shape, and it never pads: a quiet account gets one item, not three invented ones. When it could not see something, it says so in plain words.

It is read-only, and it shows you. The agent has no tool that can write to GitHub, and every read lands in an audit that ships with the brief. No login, no install, and private repositories stay invisible by design.

Where it meets you

The same brief arrives wherever you already work: the web page, a CLI, an MCP server so Claude or Cursor can answer "what should I do first?", and a GitHub Action that opens one issue every Monday morning.

How it is built

• A Strands Agents Graph: one scout agent per repository, all in flight at once, each returning a typed RepoRead (what moved, who is waiting, what will hurt, the dropped thread).
• One triage agent reads every scout report, applies the people-first rule and returns a Pydantic Brief through structured output. That single object feeds the page, the CLI text, the MCP result and the Action's issue body.
• A hook on every graph node writes the audit, so "read-only" is a record rather than a claim.
• One GitHub GraphQL call per account reads a person or an organisation the same way, for 1 point of the 5,000 an hour GitHub gives you.
• The model resolves at runtime: Gemini on Vertex AI in production, a Gemini API key, or Amazon Bedrock when neither is set.
• Python and Starlette, server-sent events for progress, hand-written CSS. The last brief per handle is one JSON file, so the next run can say what changed.

Source, MIT: github.com/hyperdrift-io/standup.

The other half of the loop

Last week's piece was about the asks nobody answered: maintainers who raised a hand and got silence. That is the helper's side of open source. Standup is the maintainer's side: making room to answer the person who showed up. Two halves of one loop, and both break in the same place, where the reading is.

If you build tools for maintainers, take the rule: order by who is waiting. The field is already in the API; the rule is one line. If you maintain something, type your handle and see who has been waiting on you tonight.