Rolls up engineering team status into an exec-ready written update with exactly three sections - progress in outcomes, risks with likelihood and mitigation, and asks with owners and deadlines - scannable in under 90 seconds. Use when someone asks "write my weekly eng update", "summarize team status for leadership", "turn these standup notes into an exec update", or is prepping for a leadership sync. Do NOT use for updates to external or cross-functional stakeholders on a project - use stakeholder-update instead - for public incident communication - use status-page-update - or for monthly investor letters - use investor-update-writer instead.
Click to play with sound.
---
name: Eng Status Rollup
description: Rolls up engineering team status into an exec-ready written update with exactly three sections - progress in outcomes, risks with likelihood and mitigation, and asks with owners and deadlines - scannable in under 90 seconds. Use when someone asks "write my weekly eng update", "summarize team status for leadership", "turn these standup notes into an exec update", or is prepping for a leadership sync. Do NOT use for updates to external or cross-functional stakeholders on a project - use stakeholder-update instead - for public incident communication - use status-page-update - or for monthly investor letters - use investor-update-writer instead.
---
# Eng Status Rollup
Execs do not need a feature list. They need three answers: are we on track, what might go wrong, and what do you need from us? A rollup that buries those answers under activity logs trains leadership to skim it - and then the one week the update contains a real red flag, nobody reads it. Everything in this skill defends the 90-second scan.
## Operating procedure
### Step 1: gather inputs
- The raw material: standup notes, sprint board, incident log, whatever exists for the period since the last update.
- The last rollup sent, so claims stay consistent - a risk that silently disappears without a resolution line destroys credibility faster than the risk itself would have.
- The audience (direct exec, VP group, company-wide) and the milestone or date the team is publicly committed to.
- Anything the manager knows but hasn't written down; ask directly "what are you worried about this week?" - the real risk is usually in the answer, not the ticket system.
If a claim is unverified ("I think the migration is on schedule"), label it as unconfirmed rather than rounding up to green.
### Step 2: write Progress - outcomes, max 4 bullets
Lead with outcomes, not activities. "Auth service is live for 20% of users" beats "we finished the auth service work." Translate internal metrics into milestone language - velocity numbers require context an exec doesn't have. If nothing shipped, say so in one sentence with the reason; a padded progress section reads as exactly what it is. Hard cap: 4 bullets. The fifth-most-important thing this week is, by definition, not exec-relevant.
### Step 3: write Risks and Blockers