agentleFS
michaelsvanbeekmichaelsvanbeek/personal-agent-skills/skills/comms/SKILL.md

comms

Skill1 starsChanged 7 months agoMITView on GitHub

Writing for specific audiences: leadership, peers, team, and org-wide. Use when: preparing an executive briefing, writing a team newsletter, communicating up/down/ laterally, announcing a launch or change, escalating an issue, delivering difficult messages, pushing back on a request, or building team visibility across the org.

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 7

    Distinctive

    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:

    Don't bury the lede — if the project is off track, say so first

    line 74
  2. Distinctive:

    Use their language (revenue, retention) not yours (story points, tech debt)

    line 76
  3. Distinctive:

    Document agreements — follow up Slack with a written summary or email

    line 105
  4. Distinctive:

    Don't sugarcoat — teams respect honesty

    line 116
  5. Distinctive:

    Keep it accessible to non-engineers.

    line 123
  6. Distinctive:

    Keep it scannable — bullets, headers, bold key phrases

    line 157
  7. Distinctive:

    Document the issue, impact, and what you've tried

    line 196

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “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

Communications

When to Use

  • Preparing an executive briefing or leadership update
  • Writing a team or org newsletter
  • Announcing a launch, migration, or deprecation
  • Managing expectations when timelines slip
  • Negotiating priorities with peers or product
  • Escalating a blocking issue
  • Delivering difficult messages
  • Building team visibility across the org

For recurring status updates (weekly, monthly, quarterly), see the status-updates skill.


Principles

  1. Know your audience — tailor depth, language, and framing
  2. Lead with "so what" — why should this person care? Start there.
  3. Be direct — state your point in the first 2 sentences
  4. Propose, don't just present — come with a recommendation
  5. Quantify — numbers build credibility
  6. Close the loop — end with a clear next step or ask

Writing for Each Audience

Upward (Manager, VP, Exec)

They care about: business impact, risks, decisions needed, confidence level.

Executive Briefing

## [Topic] — [Date]

### Bottom Line
[1–2 sentences: the key message. Most important thing first.]

### Context
[2–3 sentences: enough background to understand]

### Options
| Option | Pros | Cons | Effort | Rec |
|--------|------|------|--------|-----|
| A | ... | ... | ... | ← |
| B | ... | ... | ... | |

### Recommendation
[Which option and why — 2 sentences]

### Ask
[Specific: "I need a decision by Friday" or "Approve option A"]

Tips:

  • Don't bury the lede — if the project is off track, say so first
  • Frame problems with solutions — "X is at risk. My plan: Y"
  • Use their language (revenue, retention) not yours (story points, tech debt)
  • Pre-wire important decisions — align with your manager before the VP meeting

Lateral (Peer EMs, PMs, Designers)

They care about: dependencies, shared priorities, capacity, coordination.

## [Topic] — Cross-Team Update

### Context
[What's happening and why it affects both teams]

### Our Plan
[What we're doing and our timeline]

### What We Need From You
[Specific, timeboxed asks]

### What You Can Expect From Us
[Deliverables and dates]

### Open Questions
[Things to resolve together]

Tips:

  • Be transparent about constraints
  • Negotiate, don't mandate — you have influence, not authority
  • Document agreements — follow up Slack with a written summary or email
  • Proactive > reactive

Downward (Your Team)

They care about: context, impact on their work, recognition, honesty.

Tips:

  • Share context generously — the "why" matters more than the "what"
  • Be transparent about uncertainty
  • Celebrate publicly, coach privately
  • Don't sugarcoat — teams respect honesty
  • Repeat important messages across channels

Org-Wide (Broad Audience)

They care about: high-level impact, customer stories, team culture.

Keep it accessible to non-engineers. Good for team visibility and recruiting.


Newsletter Format

Cadence: bi-weekly or monthly Channel: Slack, email, or Confluence Length: 3–5 minutes to read

# [Team Name] Update — [Date]

## Wins
- [Win with impact] — [brief context]
- [Win with impact]

## What's Coming
- [Initiative] — expected by [date], enables [outcome]

## By the Numbers
- [Metric]: [current] (from [previous])

## Spotlight
[Person or topic] — [what happened and why it matters]

## Links
- [Confluence page, demo recording, or dashboard]

Rules:

  • Lead with impact, not effort
  • Name people — recognition builds morale and visibility
  • Include visuals when possible — charts, screenshots
  • Keep it scannable — bullets, headers, bold key phrases
  • Consistent cadence — same schedule every time

Announcements (launches, deprecations, changes)

# [Announcement Title]

## What's Changing
[1–2 sentences]

## Why
[1–2 sentences]

## Impact
[Who is affected and how]

## Timeline
| Date | Milestone |
|------|-----------|

## What You Need to Do
[Numbered action items]

## Questions?
[Slack channel, FAQ link, contact person]

Post the announcement before the change, not after.


Escalation

Before Escalating

  1. Attempt to resolve at the current level
  2. Document the issue, impact, and what you've tried
  3. Notify the other party that you plan to escalate

Escalation Message

## Escalation: [Issue]

### Situation
[Factual, no editorializing]

### Impact
[Business impact: customers, revenue, timeline]

### What We've Tried
[Steps taken]

### What We Need
[Specific decision or action]

### Timeline
[Urgency: "Need a decision by EOD"]

Stick to facts. Quantify impact. Propose a path forward.


Pushing Back

"I understand the importance of [their request]. Here's the trade-off:
taking this on would mean [what we'd deprioritize].

My recommendation is [alternative]. If [their request] is the higher
priority, I'm open to adjusting — I want to make sure we're making
that trade-off intentionally."

Delivering Bad News

  1. Be direct — "We're going to miss the deadline by two weeks"
  2. Own it — acknowledge what your team could have done differently
  3. Bring a plan — bad news + recovery plan is 10× better than bad news alone
  4. Give advance notice — get ahead of it

Anti-Patterns

Anti-PatternFix
Burying bad newsLead with the most important item
Problems without solutionsAlways propose a path forward
Jargon with execsTranslate to business language
Vague asksMake every ask specific and actionable
Over-communicatingMatch detail to audience; less is more for execs
Forgetting to name peopleAlways credit individuals

Related Skills

  • status-updates — Recurring cadence-based updates
  • planning — Presenting plans to stakeholders
  • meeting-facilitation — Running effective meetings
  • inbox-management — Triaging incoming communications

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.