| name | standup |
| description | Draft a clear standup, end-of-day update, weekly update, or client progress note. Use when summarizing completed work, next steps, blockers, risks, decisions, and support needed for a team or stakeholder audience.
|
Draft a Standup Update
Produce an accurate, ready-to-review update without making the reader decode
commit messages. Determine the audience, time window, and desired format first
when they are not evident.
Gather Evidence
Use supplied context and, when relevant, read-only repository evidence such as
status, recent local commits, diffs, issues, or test results. Do not fetch
remotes or inspect unrelated private activity merely to fill a standup.
Ask only about information the evidence cannot provide, especially:
- work that did not produce a commit;
- decisions or investigation outcomes;
- blockers and who can unblock them;
- risks, uncertainty, or changed expectations;
- what comes next; and
- what the audience needs to decide or know.
Write the Update
Use the team's established structure. Otherwise organize the message around:
- completed outcomes and why they matter;
- current or next work;
- blockers, risks, and changed expectations; and
- decisions or support needed.
Lead with outcomes rather than file lists. Distinguish completed, in progress,
planned, and blocked work. Do not claim tests, delivery, impact, or certainty
that the evidence does not support. Keep internal detail out of client-facing
updates unless it helps them understand impact or make a decision.
Draft only. Never post or send the update without explicit approval.
Provenance
Adapted from Thoughtbot's rails-consultant standup skill at revision
f2cb97d. Distributed under the accompanying MIT license.
