Async Standup: Build It From GitHub and Jira, Not Forms

Search “async standup” and the first page is a settled argument. Async beats the meeting for distributed teams. Use the three questions: what did you do yesterday, what will you do today, what is blocking you. Pick a bot that asks them in Slack on a schedule. Expect the updates to turn into noise after a month, and fight that with a template, a reminder, and a “standup champion”.

What none of the pages say is why the updates turn into noise. They turn into noise because the three questions ask a person to retype facts that two systems already hold. “I merged the pricing fix” is a line in GitHub. “I’m on the invoice export” is a ticket state in Jira or Linear. The one line a person actually needs to write, “I’m blocked on a decision about tax rounding and I need Priya”, is the one that gets buried under the other two, and the one the bot cannot chase.

This post is the version for an engineering team: how to build the async standup from the systems of record instead of from forms, what a person still has to add, how the agents on the team report in the same post, and where the meeting ends up. The worked example is a YAGNI Team, where the Agent that does this job is Harper, the Chronicler.

What is an async standup, and why do most of them decay?

An async standup is the daily standup held in writing. Each person posts the three answers to a channel, on their own clock, and everyone reads them instead of attending a call. The case for it is sound: a fifteen-minute meeting for seven people is 105 person-minutes a day, it lands at the wrong hour for at least one time zone, and a written record can be searched in a way a call cannot.

The decay is just as well documented, and the ranking pages are honest about it. Within a few weeks the updates read like yesterday’s. People post “same as yesterday, still on the export”. The blocker question gets an @mention that nobody owns. Then a few people stop posting, the channel goes quiet, and the team either reinstates the meeting or runs neither.

The standup-bot pages treat this as a discipline problem and prescribe reminders and templates. It is a design problem. A form that asks for facts the tools already hold trains people to paste, then to skip. The accountability a written standup is supposed to create comes from the record, and a record of pasted summaries holds nobody to anything.

What are the three questions really asking for?

Each question has a source of truth that is not the person, and a residue that is. Separate them and the standup changes shape.

The question	Where the answer already lives	What only a person can add
What did you finish?	GitHub: every pull request merged on the team’s repositories since the last post, with the merge as the receipt	Nothing. A merge is a fact
What are you working on?	Jira or Linear: every ticket in progress, with the branch, the draft pull request, or the review round it is sitting in	Whether it is still the right thing to be on
What is blocking you?	The open decisions: a plan waiting for approval, a review waiting for a verdict, a question nobody has answered	Why it is blocked, and who has to answer

The first column is a report. The second column is a job for a reader of GitHub and the tracker, and it is the same job every morning. The third column is judgment, and it is the part the three-question form hides under two lines of retyping.

The design that follows: generate the first two columns from the sources, with each line linked to its evidence, and make the third column the headline, addressed to a named person. Tracking engineering progress without a project manager makes the same split for the weekly status; the daily version is just shorter.

How do you build the standup from GitHub, Jira, and Linear instead of forms?

On a YAGNI Team this is one line on the Team page, under Any time: Harper posts the Daily Brief to the Slack channel the Team names, on the Rhythm a person sets, weekday mornings by default. Harper reads the Team’s connected tools, GitHub and Jira or Linear, and the Team’s own record of its tickets, and writes one Update, which is what a Harper line posts, in three parts.

What shipped, with the Receipt from the source. The pull request merged, the check passed, the ticket closed in the tracker. Every line carries the pull request number, so “the pricing fix shipped” reads “Pricing rounds tax per line item, #2167”, and #2167 opens on GitHub. Nothing appears under this heading on YAGNI’s say-so; it appears because the source confirmed it.

What is in flight, so a reader can see where the work actually is. A plan waiting for approval. A draft pull request in its second review round. A browser walk with video attached. Each line names the stage the ticket is in and links to its case file, the one record that holds the proposal, the plan, the runs, the pull request, and the review.

What needs a person, counted and linked. Each line points at the case file where that decision is answered, with the name of the person it is addressed to. The Update never mints a second copy of an ask, so answering it on the case file clears it everywhere it appears.

How Harper writes is set on the line. Written as picks the shape: Full list, every change on one short line tagged by area with who made it; Highlights, the change that matters most, a few notable ones, and the rest counted; or Custom, Harper’s house style plus the Team’s own instructions. The Approach holds the settings a person sets over the instructions: the audience (Managers, Engineers, Customers), the length, and what it groups by, such as theme, repository, or author. Preview runs the line over the last seven days and posts nothing, so a Team can read what Tuesday’s post would have said before it goes to a channel.

Two more things the form-based version cannot do. On a quiet morning, nothing arrives: a Team whose pull requests were all reviewed and needed nothing files one short note saying so, and it supersedes the last one rather than stacking. And every decision open for more than a day reminds the person it is addressed to, once a day, in the tray and by email when that person has no Slack link, until it is answered.

What does a morning’s Update look like?

A Tuesday on a Checkout Team with four engineers and the six Agents engaged. Harper’s line is set to Highlights, for engineers, grouped by theme.

Checkout, Tuesday

Shipped. Pricing rounds tax per line item instead of per order, #2167, merged by Priya. Invoice PDF regenerates when a line item changes, #2163, merged by Sam. Also: two dependency bumps, #2165 and #2166.

In flight. Invoice export to CSV, CHK-412: Wright’s draft pull request #2171 is in its second review round, Proctor asked for a test on the empty-cart case. Coupon stacking rules, CHK-418: plan waiting for approval. Refund webhook retries, CHK-420: Fletcher (beta) walked it in a browser, video attached, one failing step on partial refunds.

Needs a person. 2 things. Approve or send back the plan for CHK-418, supervised by Priya, open since yesterday. Decide whether a partial refund should retry on a 5xx from the processor: Wright stopped the build on CHK-423 to ask, addressed to Priya as the Team’s owner.

Every number is a link. Priya reads it in two minutes, clicks the plan for CHK-418, and the second item is the kind of product-intent question that, once she answers it, lands in the Team’s Decisions ledger so no Agent has to ask it again. Nobody typed any of it, and nobody could have pasted yesterday’s.

Compare the form version of the same morning. Sam: “Merged the PDF thing, now on the export.” Priya: “Reviewing, some planning.” Nobody mentions that a plan has been waiting a day, because the person who would mention it is the one it is waiting on.

How do the agents on the team report?

In the same Update, by name, with the same receipts. This is the part the ranking pages do not have a sentence for, because the standup bots were built when everyone posting was a person.

On a YAGNI Team the work is credited to the Agent that did it. Bailey, the Product Manager, proposes the next ticket from the backlog, and a proposal waiting for acceptance is a “needs a person” line. Reeve, the Staff Engineer, plans an accepted ticket, and a plan waiting for approval is another. Wright, the Builder, opens draft pull requests overnight, and those are “in flight” lines with the pull request number. Proctor, the Reviewer, posts one review per pull request, including the pull requests people opened, and an approving verdict is what moves a ticket toward merge. Fletcher, in beta, attaches a browser walk. Harper reports on all of it and on the humans alike, because the sources are the same: GitHub holds everyone’s pull requests, and the tracker holds everyone’s tickets.

What the Update never does is narrate the Agents’ own process. “Wright ran its tests twice” is not news. “Wright opened #2171, second review round” is. Every Update keeps a collapsed “How this was written” at the bottom of its own case file: what Harper read, what each setting resolved to, every cut and why. A manager who wants to know why a line was left out can find out; a reader who does not never sees it.

Why is “what needs a person” the line that matters?

Because it is the only line in the standup that changes what happens today. The other two are a record. This one is a queue.

A standup bot handles blockers with an @mention in a thread, and an @mention to a channel is addressed to nobody. On a YAGNI Team every supervised line names its supervisor, so the gate reads “supervised by Priya” in the Update, on the case file, and on Work’s Waiting on you view, which is the same list ordered oldest first. Any member of the Team may still answer, and the record says who did. A gate that goes unanswered for a day reminds its person; a proposal untouched for three weeks closes on its own. Human in the loop AI agents walks the three clicks a person keeps on a ticket; the Daily Brief is where those clicks are listed each morning.

This is also where the standup stops being a status ritual and becomes the management loop. A proposal accepted, a plan sent back, a pull request merged: each goes on the line’s track record, and each correction is a candidate Playbook rule. Ten minutes with the morning’s Update is the whole loop. If it takes longer, the line is told to say less.

Typed check-ins, activity sync, or a Team that reports?

Three ways to run an async standup, and the ranking pages only compare the first against the meeting.

	Standup bot (typed check-ins)	Activity-sync tool	YAGNI Team (Harper)
Where the update comes from	People answer three questions on a schedule	Commits, pull requests, and ticket moves pulled from the tools	GitHub, Jira or Linear, and the Team’s own record of each ticket
Evidence per line	None; prose	Commit hashes or ticket keys, often unlinked	Every line links to its pull request, ticket, or case file
What needs a person	An @mention in a thread	Not a first-class output	Counted, named, linked, reminded daily until answered
Agents’ work	Not represented	A commit by a bot account	Named Agents, reported beside the people, with the same receipts
Quiet day	Three “same as yesterday” posts	A short list	One note that supersedes the last; nothing stacks
Pricing	Per seat per month	Per seat per month	No seats; metered per run on one rate card, shown on Usage
What a person still does	Everything	Read it	Answer what is theirs; merge

The honest read of the middle column: activity sync is the right instinct and most tools stop at the commit log. A list of commit hashes is not a standup either. The line that makes the record useful is the one that says what the change was, who made it, and where it is now, with the evidence one click away, and that takes a reader of the sources that writes for a person, not a feed of events.

Does generating the standup lose the human part?

The standup-bot vendors argue it does. Their 2026 guides say to automate the reminders but keep people writing the updates, because the writing is where the connection is.

The human part of a standup was never the sentence “I merged the PDF fix”. It is the sentence after it: “and I think we should hold the export until the tax decision lands.” Generating the first sentence from GitHub is what makes room for the second. On a YAGNI Team the second sentence has a place to go: a reply on the case file, a Decision recorded in the ledger, a correction that becomes a Playbook rule. The record keeps the judgment and drops the retyping.

The meeting, if the team keeps one, changes too. It starts from a shared account of what happened rather than from six people reconstructing one, so it can be five minutes on the two things that need a person, or it can be skipped on a morning when the Update says nothing does.

Where does this leave the standup?

Two questions generated from the sources with the receipt on every line, one question addressed to a named person and chased until it is answered, and the people and the Agents reported in the same Update. That is an async standup that does not decay, because nobody has to remember to feed it.

YAGNI runs agent teams, managed like your engineering team. On each one, Harper posts the Daily Brief to Slack each morning with what shipped, what is in flight, and what needs a person, receipts attached, and Work holds the live record between mornings. The agentic software development lifecycle walks the six stages the Update reports on. See how Agent Teams work, or book 30 minutes to put a Team on one of your repositories and read its first morning’s Update before you turn the meeting off. Harper is one of six Agents; the guide to AI agents for software development covers the Team the Brief reports on.