Standup

Inspiration

Every maintainer knows the evening. You finally have a couple of hours for your projects, and three questions arrive at once: how do I make the most of this time, what should I start with, and who is waiting on me?

Behind every open-source project are people who reached out: a pull request, a question, a bug report. A reply keeps them close. A long silence, even an unintended one, lets them drift away. We believe communication is where a project's success starts, so we built an agent that does the reading and puts the people first.

What it does

Type a GitHub handle at standup.hyperdrift.io. About a minute later Standup answers those three questions in a short brief, one to three things, never padded:

• who is waiting on you, by handle
• the evidence it saw: pull request numbers, issue titles, days open
• one concrete next step and how many minutes it takes

People waiting come first. Work that will be lost or painful later comes next, then the thread you were pulling when you stopped. Bots are named and set aside: a Dependabot pull request is never someone waiting. The brief opens with what is still standing, because people step away from projects when life happens, and coming back should feel good.

Standup is read-only, and it shows it. Every read lands in "What Standup looked at", attached to the brief. No login, no install.

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

A real run on a stranger's account: twelve public repositories read in 52 seconds, and three contributors waiting for a reply surfaced with their pull request numbers and time estimates.

How we built it

The Strands Agents SDK carries the whole flow:

• A Strands Graph (GraphBuilder) with one scout agent per repository, all in flight at once. Each returns a typed RepoRead through structured_output: what moved, who is waiting, what will hurt, the dropped thread.
• A triage agent reads every scout report, applies the people-first ordering rule and returns a Pydantic Brief through structured_output. That single shape feeds the page, the CLI, the MCP tool and the Action's issue body.
• A Strands HookProvider on BeforeNodeCallEvent writes the audit trail, so "read-only" is a record, not a promise.
• The model provider resolves at runtime: Gemini on Vertex AI in production, a Gemini API key, or Amazon Bedrock through Strands when neither is set.
• One GitHub GraphQL call per account reads a person or an organisation the same way, at a cost of 1 point of the 5,000-point hourly budget.
• The page is Python and Starlette with server-sent events for live progress, semantic HTML and hand-written CSS. The last brief per handle is one JSON file, so the next run can say what changed. No database, no accounts.

Challenges we ran into

• Running a graph inside someone else's event loop. The MCP server is launched by Claude Desktop or Cursor, which already own the loop. The tool hands the run to its own thread so it never collides with the host.
• Node ids. Repository names like hello-docker and hello_docker normalise to the same graph node id, so two scouts collided until each id carried its position.
• Privacy on a public page. The handle never reaches analytics, crawlers are kept off brief pages, and a run keeps going even if the browser disconnects.
• Shell injection in the Action. The target reaches the shell as an environment variable, never through inline expansion.
• Honest emptiness. A quiet account gets one item, not three invented ones. When a scout or the API falls short, the brief says what it could not see.

Accomplishments that we're proud of

• The people-first rule holds on strangers' accounts: the contributors waiting for a reply surface first, with evidence a maintainer can check in one click.
• One typed brief, four places to receive it, with no per-surface prompt.
• Read-only you can verify: the agent has no tool that writes to GitHub, and the audit prints with every brief.

What we learned

The model is good at reading a repository. Deciding what matters tonight took an explicit rule, and the rule that works puts people first: answering someone who reached out does more for a project than any private clean-up. Structured output made the brief portable: once it was a typed object, the web page, CLI, MCP tool and GitHub Action came almost for free.

What's next for Standup

• Deploy the graph on Amazon Bedrock AgentCore.
• Read GitLab and Codeberg, where plenty of maintainers live.
• A small-team mode: one brief a team can share, so everyone knows who is waiting and nobody answers twice.

Built With

• amazon-bedrock
• gemini
• github-graphql
• mcp
• pydantic
• python
• server-sent-events
• starlette
• strands-agents
• vertex-ai