Exec update
Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.
npx -y skills add ramanbamba/10x-pm --skill exec-updateAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write a concise executive status update or weekly memo in SCR (Situation-Complication-Resolution) style. Use when the user says "write my exec update", "status update for leadership", "weekly update", "steering committee summary", or shares raw notes about project progress to be turned into an upward-facing memo.
SKILL.md
2.8 KB, as published. Nobody here has run it
Exec Update
Write the update a busy executive actually reads: the headline is the message, asks are explicit, and bad news arrives before they hear it elsewhere.
Before writing
- Ask what changed since the last update — an update is a delta, not a project description.
- Ask what the user needs from the readers: a decision, resources, air cover, or nothing. If nothing, say so in the memo ("FYI, no asks").
- Ask about anything at risk. If the user hesitates, remind them: executives forgive slips they hear early and punish slips they discover late.
Workflow
- Write the headline last, place it first. One sentence carrying the whole message: status + most important change + the ask. The reader must get the message even if they stop there. "Project update — week 12" is a subject line, not a headline.
- Status with trend, not just color. On track ↗ / At risk → / Off track ↘, against the original commitment. Re-baselining without saying so is lying with extra steps.
- Structure as SCR — situation (where we are), complication (what's changed or threatens), resolution (what we're doing about it, what we need).
- Make asks decidable. Each ask: what, from whom, by when, and what happens if not. "We need alignment" is not an ask; "Need [VP] to approve the vendor contract by Friday or launch slips 2 weeks" is.
- Compress ruthlessly. 250 words max for the body. Details go in a linked appendix, not the memo.
Output format
**[Project] — [date]**
**Headline:** [The one sentence.]
**Status:** [🟢/🟡/🔴] [On track ↗ / At risk → / Off track ↘] vs. commitment of [original date/target]
**Since last update**
- [Material change 1 — outcome, not activity]
- [Material change 2]
**Risks & what we're doing**
- [Risk → mitigation → date it resolves or escalates]
**Asks**
- [What · from whom · by when · consequence if missed]
[or: "No asks — FYI only."]
**Numbers**
[The 2–3 metrics this project is accountable to, current vs. target]
[Appendix link for detail]
Quality bar — self-check
- Headline carries the message alone. Cover the rest of the memo; would the exec still know what's happening and what you need?
- Status is against original commitment, with slips named.
- Progress is outcomes, not activity. "Held 6 meetings" fails; "cut checkout latency 40%" passes.
- Bad news is in the first half, never buried under wins.
- Every ask has a deadline and a consequence.
- ≤250 words. Count them.