Status Update Generator

Status Update Generator

Overview

Weekly status updates eat 30-90 minutes of every PM's Friday afternoon and they almost always say the same thing in subtly different ways. This skill standardizes the artifact: pull tickets from Jira or Linear (or any JSON dump), and emit a structured update with five named sections -- Highlights, Blockers, Risks, Asks, What's Next -- plus a traffic-light status (Red / Yellow / Green) for the period. The structure follows SBNR (Status / Blockers / Next / Risks) and a condensed Amazon 6-pager narrative for Highlights; the stoplight verdict follows classic R/Y/G reporting.

Core Capabilities

• Six-section template — Header, Highlights, Blockers, Risks, Asks, What's Next, in a fixed order so exec readers scan in under 5 seconds (full section definitions in references/status-structure-and-workflow.md).
• Traffic-light discipline — Green / Yellow / Red rules plus anti-patterns (watermelon status, always-yellow, color creep).
• Multi-format rendering — status_generator.py emits all six SHARED_OUTPUT_SCHEMA formats: markdown, confluence, notion, linear, json, mermaid.
• SBNR mapping — compressed async-standup variant mapped to the weekly sections.

When to Use

• Weekly exec status update -- the standard Friday/Monday cadence brief sent to a sponsor, VP, or steering committee.
• Monthly board / leadership packet -- aggregate four weekly updates into a monthly view.
• Sprint review summary -- end-of-sprint communication that travels outside the team.
• Cross-team async standup -- distributed teams where a written async update replaces a sync meeting.
• Project kickoff status baseline -- the first status update establishes the template and traffic-light baseline.

When NOT to use: real-time incident response (use delivery-manager/ incident skills), deep retrospectives (use sprint-retrospective/), or one-to-one stakeholder reporting needing custom framing (use roadmap-communication/).

Clarify First

Before generating the update, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Traffic-light verdict (R/Y/G) — the human judgment the tool will not infer; sets the whole frame and must be defensible (prevents watermelon status)
• Audience — sponsor, VP, or steering committee (sets altitude and what belongs in Highlights vs Asks)
• This period's wins + blockers with real numbers — quantitative claims must come from telemetry, not ticket titles (fills Highlights and Blockers)
• The asks — the specific decisions or help you need from the reader this week (drives the Asks section)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

The traffic-light status is a human judgment, not a calculation — set it and document the rationale. See references/tool-and-troubleshooting.md for flags and the input JSON shape.

References

Load the reference that matches the task — keep this file lean and pull detail on demand:

• references/status-structure-and-workflow.md — full definition of each of the six sections, R/Y/G rules and anti-patterns, SBNR shorthand mapping, and the 6-step authoring workflow. Read when writing or standardizing an update.
• references/status-update-style-guide.md — voice, structural rules, traffic-light discipline, and 5 worked examples (Green / Yellow / Red across team types). Read when coaching writing quality or seeing full examples.
• references/red-flags.md — warning signs and failure modes in status reporting practice. Read when an update process feels performative or untrusted.
• references/tool-and-troubleshooting.md — status_generator.py flags, input JSON shape, Mermaid output, troubleshooting table, and success criteria. Read when running the tool or diagnosing a problem.
• assets/weekly_status_template.md — fill-in template matching the tool's input JSON structure. Use to draft an update by hand.