herdr-dia
The Morning Brief knows which pull requests need you. This prototype lets you act on them from the browser. This report says what it does today, what a version built into Dia could do, and the tradeoffs behind that.
01 · The morning
Before the day kicks in, Dia's brief lays out the pull requests waiting on you. You read it with coffee, work out what each one needs, and then open a terminal somewhere else to do it. The browser knew what needed attention, the agents could do the work, and you carried the decisions between the two by hand. By the third pull request the context from the brief has gone.
The bet was small and specific. If the brief could hand a pull request to a coding agent and keep that agent in view, you would act on the brief instead of leaving it. Underneath that sat a second bet: that an agent's own permission modes are enough to make this safe, so the browser would not need a permission system of its own.
02 · What it does today
Open a pull request in Dia and the panel sits beside it. Two buttons start work. Review with an agent hands the pull request to a coding agent on your own machine, in your own checkout, signed in as you. Update the PR takes the change you and Dia agreed on, gives the agent a worktree of its own, and pushes the result to the pull request, so your checkout stays as you left it. From there the extension does six things.
Active board
One row for each session the extension started, on any repository, with its live state: reviewing, updating, needs you, review ready, finished. The row that needs you sorts to the top. Open a row for its actions; End closes the agent's tab and tidies up after it.
Peek
Open a running review and read what the agent has written so far, without interrupting it. Refresh reads it again.
Review ready
When the agent finishes, its row says review ready and opens on its own. The review shows findings by severity with file and line, a recommendation, and the full text. It is read out of the agent's plan file without answering the agent's dialog, so the agent stays parked until you decide.
Tell the agent what to do
A field under the review sends your instruction straight to the agent. Post as comment and Apply the fixes are that field with the words filled in. Your instruction is the approval: from then on the panel answers the agent's own dialogs on your behalf, and anything it does not recognise waits for you.
A queue you can filter
Built from your GitHub notifications and review requests, in five tabs: Favourites for the people you follow, Mine for your own pull requests, Brief for what is addressed to you, Team for what your team owes, and Other for notifications that are not pull requests. Narrow it to the repositories you choose, and to unapproved pull requests only, which is the default. Every row has Review with an agent.
Merge when it is approved
On Mine, each of your pull requests carries its review decision. Merge stays disabled until the pull request is approved and mergeable, takes two clicks, and stays off while the panel is showing a remembered answer rather than a fresh one from GitHub.
Figure 1. A review that is ready. The panel is rendered here against fictional data.
It is a browser extension and a small local process, public under MIT, and it works with whichever coding agent the local runtime has installed. It took two evenings to reach first use, and I have used it every day since. The extension fills the gap until the browser can do this itself.
03 · What it can do tomorrow
The extension fills the gap today. These are the things a version built into the browser could do that it cannot.
The biggest one is Dia's chat. An extension cannot reach it, so today you paste the change you and Dia agreed on into the panel. Built in, the conversation you already had would be the brief, and the paste would go away.
The read-only gate could hold for every agent. Today it is Claude Code's plan mode, and agents without one post their reviews themselves. With the gate on the credentials, a token that cannot post until you act, every agent would get the same guarantee.
The panel could stop reading the agent's screen. Ready state and the dialogs the panel answers are matches against Claude Code's text today, and a release can change that text. A runtime that reports when it is waiting for you would remove the guesswork.
Nothing would need installing. Today it assumes a runtime and an agent on your machine, and it loads unpacked. A helper the browser manages, or a hosted runtime, would remove both.
Three known defects in the extension are listed in the design document and are the first fixes: sessions are not scoped to the GitHub identity that started them, any blocked review reads as ready including one stopped on a login prompt, and a review the agent already posted is still offered Post as comment.
04 · Integration with Dia
Built into Dia rather than beside it, the same feature would sit where you already are.
Figure 2. The proposed integration. Panels 1 and 2 use Dia's surface as a user sees it. Panel 3 is an assumption.
The brief's own list carries the action, so the morning list is also the board. A running agent is a collapsed card in the tab's chat, with Peek, and the tab Live Work already opened carries the same state. The finished review arrives as a turn in the conversation where you discussed the diff with Dia, with the decision beside it, and your reply is the approval. Because the conversation is already there, the update brief carries what you and Dia agreed on without a paste.
What it should include, whatever the internals turn out to be: dispatch from the brief, a session you can see and open while it runs, the review as a turn with the decision next to it, and no irreversible action without you.
On where the agent runs, I would start with the local runtime, for the people who already have an agent installed, and let the evaluation plan in the design document decide whether a hosted runtime earns its cost. A hosted runtime is the version that does not depend on the agent having a plan mode, because the read-only gate moves to the credentials.
Everything here about Dia's internals is an assumption. The browser is closed source, and what I know of it is what is public and what I see as a user. The design document lists each assumption with a way to check it, and the decision records behind the prototype sit next to it. Assume I don't know.
05 · Tradeoffs
| Choice | One way | The other | My read |
|---|---|---|---|
| Where the list comes from | The brief: already ranked from a source that knows you; needs the feature to reach it | A separate queue: works from an extension today; duplicates the brief | The brief. |
| Extension or feature | Extension: fills the gap today, works in any Chromium browser, cannot reach the chat | Feature: closes the loop through the conversation; needs decisions about process launch and sessions | Extension until the feature exists. |
| What the brief becomes | A summary you read: calm, finished in a minute, and nothing in it changes after you close it | A place you act from: items carry a button and a live state, so the morning list is also the board, and the brief has to reflect what happened after you clicked | Act from it, on the items the brief already chose to show, and let it carry their state through the day. |
06 · Next
The next step is a conversation. I'd like to walk you through this against a live pull request, and then talk about where it goes. How far can agentic engineering move into the browser, and what does an orchestration product built on one look like? Does any of this fit the picture you already have for Dia, and what would you need on the infrastructure side to run it? That last question decides more than the design does. I'm excited to learn more about how the team works and where an agentic engineering background can help. Let's get together and talk.