prepare-a-status-update

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.