| name | prepare-a-status-update |
| description | Prepare a concise, audience-specific status update grounded in current team, initiative, function, or company sources. Use when someone needs to communicate progress, changes, risks, decisions, asks, or next steps asynchronously in Slack, email, a document, or another chosen channel. |
Prepare a Status Update
Turn scattered work into one clear update the audience can understand and act on. Lead with what
changed and what it means, not a diary of activity.
Instead of asking the user to paste a summary from every tool, use Strawberry's tabs and approved
connections to bring together the live context behind the update—project records, messages,
meetings, documents, dashboards, and files—then prepare the result where the user wants to review
it. Keep the important evidence easy to open without turning the update into a source dump.
1. Understand the update
Infer the subject, period, audience, purpose, and likely delivery channel from the request and
available context. Ask only when a missing detail could materially change what should be included.
Use a trusted previous update when it reveals the expected voice, structure, level of detail, and
recurring commitments. Otherwise, begin with a concise draft and let the user shape the pattern
through feedback. Do not force traffic-light status, a fixed template, or a document when a short
message would work better.
2. Pull together the current picture
Use the sources that actually represent this work: project or task systems, goals and metrics,
team messages, meeting records, decision documents, calendars, dashboards, files, browser tabs, and
approved apps. Suggest a connection only when it would meaningfully improve coverage or accuracy;
continue from available sources when possible.
Respect the source of truth for each record. Prefer current direct evidence, but surface material
conflicts rather than quietly choosing the most convenient version. Compare with the last accepted
update when that helps explain what changed.
Keep private notes, personnel matters, sensitive hypotheses, and unrelated work out of a broadly
shared draft. If coverage is incomplete, say which part of the update could not be verified.
3. Work out what the audience needs to know
Prioritize the few facts that change understanding or action:
- progress against the intended outcome, not just completed tasks;
- meaningful changes since the last update;
- risks, blockers, dependencies, or shifts in timing;
- decisions made and decisions still needed;
- specific asks, owners, and dates where supported; and
- what happens next.
Adapt the emphasis to the audience. Leaders often need the headline, consequence, decision, and
ask. A delivery team may need owners, dependencies, and changed priorities. Cross-functional
partners need what affects them and by when. Do not use a status color unless the team already has a
clear meaning for it or the user wants one.
Keep observed facts, plans, forecasts, and recommendations distinct when the difference matters.
Do not invent certainty, dates, owners, or progress to make the update feel complete.
4. Draft the update for its real destination
Write for the channel and audience rather than filling a universal report. A useful update usually
has:
- a clear headline or opening;
- the most important progress or change;
- risks, decisions, or asks that need attention; and
- the next milestone or expected follow-through.
Use links beside the claims they support when recipients can access them. Keep the main update
scannable and move optional detail behind links or a short supporting section. Match the user's
established voice without hiding difficult news or overstating success.
Use strawberry/operations/close-open-loops when missing ownership or conflicting records need a
cross-system audit before the update can be trusted. When the update reveals a decision that needs
discussion, use it as context for strawberry/operations/prepare-for-meetings.
5. Review before sharing
Let the user correct the emphasis, audience assumptions, facts, tone, and level of detail. Check
names, dates, metrics, links, owners, and sensitive content that could change how the message lands.
Preparing the update in chat is different from creating a draft in an external tool, posting it,
sending it, or publishing it. Confirm the destination and audience before those actions. After an
approved send or post, verify the result and report any failure or partial delivery.
Use a domain-specific workflow when specialist judgment dominates—for example a customer-facing
client report, financial report, incident update, or sales forecast—rather than stretching this
general Operations update into every reporting job.
6. Make recurring updates easier
Use feedback to remember the accepted sources, audience needs, voice, format, definitions, and
review behavior. Save a custom or team skill when the method is genuinely repeatable.
For a real reporting cadence, a Routine may check the agreed sources, compare them with the last
accepted update, and prepare a fresh draft in the approved review destination. It should flag
missing or conflicting evidence and leave posting, sending, or record changes for review unless the
user explicitly approves a narrower recurring behavior. Stop when the audience or destination is
unclear, material evidence cannot be reconciled, or private context could reach the wrong people.
