agentleFS
brittbritt/agent-skills/skills/stakeholder-updates/SKILL.md

stakeholder-updates

Skill11 starsChanged 6 days agoMITView on GitHub

Use when writing status updates, communicating delays or blockers, announcing launches, or requesting decisions and resources from stakeholders - structures the message by audience level (exec/management/peer/team) with lead-with-the-punchline framing

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do NOT use this skill for technical documentation or commit messages — it is for audience-facing status communication.

    line 19
  2. Distinctive:

    Does NOT affect: Web release (still May 15)

    line 90
  3. Distinctive:

    Every statement should answer: "Why does this matter?"

    line 115
  4. Distinctive:

    When things go wrong: "I underestimated the integration complexity" When things go right: "The engineering team delivered this ahead of …

    line 125
  5. Distinctive:

    When things go right: "The engineering team delivered this ahead of schedule"

    line 126
  6. Distinctive:

    Don't just state what you decided—explain why: "We're prioritizing mobile over tablet because 87% of our traffic is mobile, and tablet …

    line 129
  7. Distinctive:

    Gather context: before writing updates

    line 154
  8. Distinctive:

    Offer the user a draft to review: before sending, especially for sensitive or high-stakes messages

    line 155

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Stakeholder Updates Skill

This skill helps craft effective communications for stakeholders at various levels.

When to Use

Activate this skill when:

  • Writing status updates or progress reports
  • Communicating delays or blockers
  • Sharing launch announcements
  • Requesting decisions or resources
  • Reporting on milestones or outcomes

Do NOT use this skill for technical documentation or commit messages — it is for audience-facing status communication.

Core Principles

Know Your Audience

Executives (C-level):

  • Lead with business impact
  • Be concise (3-5 sentences)
  • Include metrics and outcomes
  • Avoid technical jargon
  • Focus on "what" and "why", not "how"

Management (Directors, VPs):

  • Balance detail with brevity
  • Include both progress and blockers
  • Provide context for decisions
  • Mention resource needs
  • Highlight risks and mitigation

Peers (Other PMs, Team Leads):

  • Can be more detailed
  • Include tactical information
  • Share lessons learned
  • Discuss trade-offs and alternatives
  • Be transparent about challenges

Team Members:

  • Provide full context
  • Explain "why" behind decisions
  • Share timelines and expectations
  • Acknowledge contributions
  • Be specific about next steps

Update Structure

Status Update Template

Subject/Title: [Concise summary of current state]

TL;DR: (1-2 sentences) Current status in plain language with key takeaway

Progress This Week:

  • Completed: [specific accomplishments]
  • In Progress: [active work with % complete]
  • Planned Next: [upcoming priorities]

Metrics/Impact:

  • [Quantifiable results or leading indicators]

Blockers/Risks:

  • [Issue]: Impact and proposed resolution

Decisions Needed:

  • [Decision]: Context, options, recommendation, deadline

Next Milestones:

  • [Date]: [Milestone and success criteria]

Example: Team Update (Project Delay)

Subject: Q2 Mobile Release - Timeline Update

Context: We've hit an integration blocker with the third-party payment SDK that requires vendor support.

Impact:

  • Original ship date: May 15
  • Revised ship date: May 29 (2-week delay)
  • Affects: iOS and Android apps
  • Does NOT affect: Web release (still May 15)

What Happened: The SDK update (required for PCI compliance) introduced breaking changes to the refund flow. Vendor confirmed this is a known issue and they're releasing a patch.

Mitigation:

  • Vendor committed to patch by May 22
  • QA time reduced by reusing web test scenarios
  • Stakeholder communications sent
  • Customer impact: None (no existing feature affected)

What I Need:

  • Your approval to adjust the milestone in Jira
  • Communication to sales team (I've drafted a message)

Lessons: Adding "SDK update review" step to our release checklist to catch this earlier next time.

Communication Best Practices

Lead with the Punchline

❌ "We've been working on improving the checkout flow and after several iterations and testing..." ✅ "Checkout conversion is up 23% since Tuesday's launch."

Use the "So What?" Test

Every statement should answer: "Why does this matter?"

❌ "We added a progress indicator" ✅ "We added a progress indicator, reducing checkout abandonment by 12%"

Be Specific with Numbers

❌ "Most users are happy" ✅ "NPS increased from 42 to 58 (n=247 responses)"

Own Problems, Share Credit

When things go wrong: "I underestimated the integration complexity" When things go right: "The engineering team delivered this ahead of schedule"

Provide Context for Decisions

Don't just state what you decided—explain why: "We're prioritizing mobile over tablet because 87% of our traffic is mobile, and tablet usage is trending down (15% decrease QoQ)."

Signal Confidence Levels

  • "We will ship May 15" (high confidence, committed)
  • "We expect to ship around May 15" (medium confidence, estimate)
  • "We're targeting mid-May" (lower confidence, subject to change)

Special Situations

Announcing Bad News

  1. State the problem clearly (no sugarcoating)
  2. Explain the impact (who is affected, how much)
  3. Own the mistake (if applicable)
  4. Present the solution (what you're doing about it)
  5. Set expectations (timeline for resolution)

Example: "The feature we shipped yesterday caused a 30% increase in page load time. This affects all users on mobile devices. I approved the release without adequate performance testing—my mistake. We've rolled back the change and users should see normal performance within the hour. We're adding performance benchmarks to our release checklist."

The same structure adapts to requesting resources (need, justification, trade-off, options, clear next step) and celebrating wins (specific accomplishment, credit by name, tie to strategy).

Workflow Tips

  1. Gather context before writing updates
  2. Offer the user a draft to review before sending, especially for sensitive or high-stakes messages
  3. Follow up on action items and decisions requested

Red Flags to Avoid

  • ❌ Burying the lede - Don't hide important info in paragraph 3
  • ❌ Jargon overload - Assume your audience doesn't know technical terms
  • ❌ Defensiveness - Own mistakes without excuses
  • ❌ Vagueness - "We're working on it" tells them nothing
  • ❌ Over-promising - Under-promise and over-deliver
  • ❌ No action items - Every update should have a clear next step

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.