standup-report

name

standup-report

description

Generates the user's daily standup message in the Done / Will do / Blockers format from git history, PRs/issues, and the user's own notes, ready to paste into the team chat, with an optional short follow-up thread for extra detail. Use when the user asks for "standup", "my check-in", "daily update", or to put together the day's status message for the team. Do not use for meeting summaries — use `meeting-analysis` — or for status reports longer than a standup; write those as documents.

Standup Report

Generate the user's daily standup message: what moved forward, what comes next, and what is blocked. Assemble evidence from the repository and the user's own account, draft the three-section message, confirm it with the user, and deliver it ready to paste into the team's chat tool (Slack, Teams, or whatever the team uses).

A standup is a pulse, not a report. The format is lightweight — a greeting and emoji markers are fine — but the substance stays concrete, verifiable, and honest.

When to use

• The user asks for a standup, check-in, daily update, or the day's status message.
• The user wants yesterday's work and today's plan summarized for the team chat.

Skip if

• The input is a meeting transcript or the user wants a meeting summarized — use meeting-analysis instead.
• The user needs a status update longer than a standup (weekly summary, retrospective, project report) — write those as documents, not chat messages.

Message template

<optional greeting line — e.g. "Good morning, team! Daily check-in:" — with the team @-mention if the user wants one>

🟢 **Done**
- <concrete verb + artifact, one line — e.g. "Merged PR #118 — retry handling in the sync client">
- <2–4 bullets per section>

🟡 **Will do**
- <next meaningful deliverable, one line — e.g. "Open the follow-up PR wiring retries into the batch endpoint">

🔴 **Blockers**
- <what is blocked + what is needed + from whom (by role), one line — or exactly "No blockers today.">

Example, filled:

Good morning, team! Daily check-in:

🟢 **Done**
- Merged PR #118 — retry handling in the sync client
- Opened PR #123 — pagination for the export endpoint
- Published the draft rollout plan for team review

🟡 **Will do**
- Start the auth-module migration once PR #123 lands
- Turn rollout-plan feedback into the final checklist

🔴 **Blockers**
- PR #123 (pagination for the export endpoint) awaits reviewer feedback — blocks the migration start

Formatting rules

• One line per bullet. Never hard-wrap inside a bullet — chat tools soft-wrap, and a hard-wrapped bullet renders as broken fragments.
• 2–4 bullets per section. More than that is a report, not a pulse — move the overflow to the thread or cut it.
• Blank line between sections — the message breathes better.
• The 🟢/🟡/🔴 markers and bold section headers are the format's identity — keep them. If the team's chat tool renders emoji shortcodes more reliably than literal emoji, swap them at delivery time.
• Team @-mention is optional and never assumed. If the user wants one, ask for the exact group handle — do not invent or guess it.
• Greeting matches the time of day, and is optional.
• Inline links where the chat renders markdown: a labeled link to a PR or issue beats a raw URL. In Blockers, make the link label descriptive enough that the reader grasps what is blocked without clicking.
• Joint work reads in the plural, solo work in the singular. "We aligned on the rollout plan" credits the team; "I opened the PR" owns the work. Do not claim shared work as solo, and do not dilute solo work into "we".
• No blockers? Say so explicitly ("No blockers today.") — never invent one to fill the section.

Assemble the content

1. Identity. Derive the author from git config user.name (and user.email for log filtering). If unset or ambiguous, ask the user. Never hardcode a person.
2. Window. Done covers the span since the last standup — default: yesterday plus today so far. Will do covers the next working day.
3. Git history. Run git log --oneline --since="yesterday" --author="<name>" in the current repository, plus any other repositories the user names.
4. PRs and issues. When gh is available and the repository is on GitHub, pull the user's recently merged and open PRs (gh pr list --author "@me" --state merged / --state open) and recently closed or assigned issues (gh issue list --assignee "@me"). If gh is missing or errors, skip this source silently — it is an enrichment, not a requirement.
5. User-pointed sources. Read whatever task list, tracker export, or planning file the user points at. Do not guess paths and do not crawl the workspace looking for one.
6. The user's own words. Ask what the artifacts do not show: reviews given, meetings held, decisions made, teammates unblocked, direction changes.
7. Draft, then confirm. Always show the assembled draft and confirm it with the user before final delivery — artifacts under-report the day, and the user knows what actually happened.

Quality rules

#	Rule	Why
1	Done bullets use concrete, verifiable verbs anchored to artifacts — "opened PR", "merged", "published", "fixed" — never "worked on" or "looked into".	Vague verbs hide state.
2	Verb proportional to the work: "refined" ≠ "reworked" ≠ "rebuilt" — pick the smallest verb that is still true.	Inflated verbs erode trust.
3	Will-do items sit at deliverable altitude — the next meaningful outcome, not micro-actions like "reply to a review comment".	Teammates read outcomes, not todo lists.
4	Report state at posting time: if something changed since yesterday's plan, write the current truth, not the stale intention.	Stale intentions misdirect the team.
5	Never cite CI or test status as an accomplishment.	Green tests are table stakes, not progress.
6	"Decided" / "closed" only for decisions actually made; "discussed" / "aligned" for conversations that set direction.	Conflating them creates phantom commitments.
7	Waiting on review or feedback IS a blocker — name it honestly, with what is needed and from whom (a role, not a personal callout).	Unnamed waits stall work silently.
8	An honest thin day beats a padded one.	Padding is visible and costs credibility.

Two further checks before showing the draft:

• Will do lists only what the user owns. A teammate's deliverable or a team-wide goal does not belong there; the user's own coordination step toward it ("raise the cutover date with the platform team") does.
• Cut execution parentheticals. A detail like "(rebase expected, no conflicts)" belongs in the PR, not the pulse — if it matters, move it to the thread.

Apply the rules while drafting, not as an afterthought — most rewrites come from inflated verbs (rule 2) and missing review-wait blockers (rule 7).

Optional detail thread

• When one item genuinely needs context — links, error detail, design rationale, material to attach — offer a short follow-up thread message instead of bloating the main message.
• Threshold: one or two extra details belong in the bullet itself; a thread is only for genuinely dense material.
• Thread format: free-form and short. It does not repeat the Done / Will do / Blockers structure. Title it with the date and topic.

Example thread message:

Thread — <date>: export-endpoint pagination

Context for PR #123: went with cursor-based pagination over offset — offset scans degraded badly past large row counts.
Benchmark numbers and the query-plan comparison: <link>
Client impact: none — the old offset params keep working until the next major version.

Delivery

• Put the final message in a fenced code block, ready to select and paste into the chat. Never deliver it as a blockquote or decorated markdown — terminal border characters contaminate the copy-paste.
• If a thread was drafted, deliver it in its own separate fenced block after the main message.

Persistence

• Default is message-only: deliver the text and stop.
• If the user keeps a standup history directory, offer once to save a copy there — ask for the location the first time, then reuse the answer without re-asking.
• When saving: one file per day, named by date (e.g. YYYY-MM-DD.md), containing the message and the thread if there is one. If the day's file already exists, update it rather than duplicating.

Saved-file layout:

# Standup — YYYY-MM-DD

## Message
(the message exactly as delivered)

## Thread (optional) — "topic"
(the thread text)