Work status report

This is a second report, not a replacement for the first. The first report answers the question or delivers the work. This one follows it and says, of everything in flight, how far each piece has actually got and what the person you're working with has to decide.

This exact format was approved on 2026-09-17 after reading one item written this way: "this report format was fucking perfect." What follows is that format, plus the two things that were named as missing — generalized so it works for whoever you're actually reporting to.

Which branch counts as "shared and done"

The fourth group below refers to a shared branch where finished work lands before it's live — one common setup calls it staging. Ask once, during setup, which branch that is for this project (git branch -r will list the real candidates — staging, develop, main are common answers), and use that name in the group heading from then on: "Done, committed, merged to <branch>." If nothing has been configured yet, say so plainly rather than guessing, and the fourth group's heading becomes "Done and committed (no shared branch configured yet, so merge isn't verified)."

Group everything by status, in this order

Four sections, always in this order, always with these names. Omit a section only when it holds nothing.

## Proposed

## Work in progress

## Done, not committed

## Done, committed, merged to <configured branch>

The stated reasoning for why this exact grouping: "you want to sort by the following categories: proposed / work in progress / done not committed / done, committed, merged to staging."

Status is a fact, never a courtesy. If the person refers to something as done and committed when it is done and uncommitted, it goes under "Done, not committed" and the item says so in its first sentence. Agreeing with a wrong status to avoid friction is how work gets shipped that nobody reviewed. Where a piece is committed on a working branch but has not reached the shared branch, say that inside the item rather than promoting it a section.

What each item contains

One numbered item per piece of work. Each is a short paragraph carrying four things, woven together as speech, never labelled:

1. What it is and where it actually stands — led by what is true or not yet true for a person, not by the code.
2. The intent read back, so they can validate or reject it — "I read that as you wanting…", written so they can answer "4 is false" and correct the understanding rather than the work. This is the part that makes the format worth reading: it exposes what the agent believes they want while there is still time to fix it.
3. What happens next — the specific next move, named concretely enough that they can veto it.
4. What they will have when it lands — the observable result, in terms they can check themselves.

Never write these as fields. *Intent I'm reading:* … *Plan:* … *Result:* is a data structure wearing prose, and it reads as such — see /how-to-talk-like-the-founder. The four things live inside the sentences, in that order, because that is the order a person says them.

White space — a blank line between sentences

The correction this enforces: don't skip using new lines generously — that makes text hard to read. Each sentence should have a full space between it and the next.

So inside every item, each sentence sits on its own line with a blank line between it and the next. This is not a paragraph of prose. It is a column of sentences the reader can scan at speed and stop on one. (This is a reading preference, not a universal law — if the person you're working with tells you they prefer normal paragraphs, honor that instead. The default, absent any stated preference, is the blank-line-per-sentence form above, because that's what produced the approved example.)

Example of the shape (illustrative, not real business data)

5. Your outage alerts still don't arrive.

When the app is unreachable for a real person, you want to hear it from the system within a minute rather than from a customer — and more than that, you want the way that happens to become the single way anything reaches you, so the next agent can't invent its own.

An agent is building that one canonical alarm path on the sender every other email already uses, registered where your canonical utilities live so it's findable rather than folklore.

It has to settle two things first: whether an email-governance check could quietly suppress an alarm to a flagged address, which would re-break this for a new reason, and what happens when a real outage makes many browsers report at once — one message per incident, not one per reporter.

Then the next unreachable-app moment puts an email in your inbox naming which endpoints failed and from which page, and the record that has been collecting failures stops growing.

Read what that item does. It opens with what is still true for the reader rather than with a component name. It states the intent back so they can correct the understanding. It names what is being built and the two open questions inside it, so a decision they disagree with is visible before it is made. It closes on the thing they will be able to check with their own eyes — an email in their inbox, and a number that stops growing.

Rules

• Every number, count and date is read fresh, not carried from earlier in the session. A stale figure in a status report is worse than no figure, because it looks current.
• One item per number. If an item holds two separately-falsifiable claims, split it, so "7 is false" means something.
• Never use a term the person hasn't been given. Say what it means instead of naming it.
• Anything blocked on the person gets said as a question they can answer in a sentence, not as a request for review.
• Anything unverified is named as unverified, with what would settle it.
• This skill governs shape and grouping. The voice rules in /how-to-talk-like-the-founder govern every sentence inside it and always win.

When this fires

After any substantive report or answer, when the person asks what is left, what is actionable, or for the status of work — and at the end of a session where work sits in more than one state. It is reusable anywhere a set of work items needs its standing made legible, not only for a morning health check. If the person tells you they only want this on request, or only at session end, honor that instead of firing it after every answer.

When the shared branch isn't configured yet

If no branch has been set for this project:

• Notice it: git rev-parse --verify <branch> fails, or nothing was configured during setup.
• Say so: "After I answer you, I'll add a short second report showing how far each piece of work has really got and what I think you want from it, so you can correct me before I build on a wrong guess. Which branch counts as finished-and-shared for you?" Suggest the likely candidates from git branch -r.
• Meanwhile: still produce the report. Label the last group "Done and committed (no shared branch configured, so merge not verified)" — never quietly drop the group or claim work was merged without checking.