communication-refiner

Communication Refiner

What this skill does

Takes rough thoughts, meeting notes, or draft messages and turns them into clear, professional communication that:

• Leads with the ask — Action items and requests come first, not buried at the end
• Makes ownership explicit — Names who should do what, rather than leaving it ambiguous
• Translates problems into proposals — Converts issue-spotting into a suggested path forward
• Respects people's time — Shows urgency without being unreasonable; signals flexibility
• Backgrounds the context — Keeps the main message lean, pushes deep context into references

Why this matters

Two common pitfalls in professional communication:

1. Raising problems without a path forward. It's easy to spot what's broken. The harder (and more valuable) skill is saying "here's what I think we should do, here's why, here are alternatives I considered, and I'm open to pushing back." This keeps things moving and unblocked.

2. Overloading the reader. People have limited attention — treat them like they have a small context window. Put the ask up front, keep supporting details brief, and link to external references (Notion docs, Miro boards, PDFs, flowcharts) for anyone who wants to go deeper. The main thread should be scannable in under 30 seconds.

Workflow

1. Huddle Gate — figure out if this should be a message or a conversation

Before writing anything, assess whether the user's input is ready for written communication or would be better served by a live discussion.

Route toward a conversation when:

• The user doesn't have a clear recommendation yet — they're still figuring out what they think
• There are multiple unknowns and they need input from others before forming a view
• The topic is sensitive, politically nuanced, or benefits from real-time back-and-forth
• The input is exploratory: "I noticed X but I'm not sure what it means yet"
• There are competing options and the right call genuinely isn't clear

Route toward a written message when:

• The user has identified a problem and has a sense of the fix
• Action items are clear, they just need to be communicated
• Context can be adequately summarized in a short message
• The user already has a preference and wants to propose it

If it's unclear, ask the user directly: "Do you feel like you have enough of a picture to write this up, or would it be better to huddle with [person/team] first?"

If the gate says "conversation"

Don't just say "you should talk to them." Draft the request to have that conversation — make it actionable and specific, not a vague "can we chat?":

Hey [Name], I spotted something in [area/system] I want to run by you.
I don't have the full picture yet — [one sentence on what you've found so
far]. Got 15 min today or tomorrow to huddle? I'll bring what I've got
and we can figure out next steps together.

Include a mini-agenda so the other person knows what they're walking into:

• What sparked the need to talk
• What you've figured out so far (even if incomplete)
• What you're hoping to get out of the conversation (advice? decision? brainstorming?)

If a calendar invite would be more appropriate than an ad hoc huddle, suggest that and draft the meeting title + description too.

If the gate says "written message"

Proceed to step 2.

2. Understand the input

Read what the user gives you — it might be:

• Rough notes from a conversation
• A stream-of-consciousness brain dump
• A draft message that needs tightening
• A problem they've identified but haven't framed constructively

If anything is unclear (who the audience is, what format they want, urgency level), ask a quick clarifying question before proceeding.

3. Structure the message

Use this structure, adapting tone to the situation:

## Ask / Action Items [if applicable]
- [Name] — [specific action they should take]
- [Name] — [specific action they should take]

If no specific people are named, frame it as:
- "What I'm asking for: [clear request]"

## Proposal / Next Steps
State your recommended path forward clearly. If you have a preference,
lead with it — but acknowledge alternatives:

"I'd recommend [X] because [brief reason]. We also considered [Y] and
[Z] — happy to discuss, but wanted to put a stake in the ground so we
can keep moving."

## Context (brief)
One or two sentences of background — only what's essential to understand
the ask. If there's more, link to a reference asset:

"More detail in [this Notion doc / Miro board / PDF] if useful."

## Flexibility / Time Acknowledgment
If timing is relevant, acknowledge it without pressure:

"No rush on this — let me know what works for your schedule and I'm
happy to work around it."

4. Choose the output format

Ask the user which format they want, or infer from context:

• Slack/Teams message — Shorter, conversational tone, use line breaks and bullet points for readability
• Email — Slightly more formal, can be longer, include a clear subject line
• Bullet-point summary — Structured outline they can adapt into their own words

5. Apply the refinement principles

When rewriting, keep these in mind:

Principle	What it means
Ask first	The reader should know what's expected of them within the first few lines
Name names	If multiple people are involved, say specifically who should do what
Propose, don't just poke holes	If you identify a problem, pair it with a suggested fix
Show your reasoning briefly	One sentence on why you prefer X over Y — enough to be persuasive, not so much that it bogs down
Link out for depth	"See [doc/board/link] for full context" — keeps the message lean
Signal flexibility	Make it clear you're open to discussion and not imposing unreasonable timelines
Keep it scannable	Use headings, bullets, short paragraphs — the whole message should be digestible in ~30 seconds

Examples

Example 1: Huddle gate → conversation request

Input:

"I was looking at the deployment pipeline and I'm seeing some weird behavior with the staging environment. Sometimes the tests pass, sometimes they don't. I'm not sure if it's a flaky test issue or something with the infra config. Haven't dug deep enough yet."

Assessment: Exploratory — user doesn't have a clear recommendation. Route toward a huddle.

Output (Slack message to teammate):

Hey [Name], I'm seeing some inconsistent behavior in the staging pipeline — tests pass sometimes, fail other times, and I haven't pinned down whether it's flaky tests or an infra config issue yet. Want to huddle for 15 min today or tomorrow? I'll walk through what I've seen so far and we can figure out where to dig together. No rush — whenever works for you.

---

Example 2: Written message → polished proposal

Before:

"So I was looking at the onboarding flow and I noticed that if the user skips the profile setup step, then when they get to the dashboard the welcome modal never triggers, which means they never see the tooltips. Also the analytics event doesn't fire so we can't track drop-off. Not sure what the right fix is but wanted to flag it."

After (Slack message):

Ask: Can we sync on the onboarding flow gap? I'd like to propose a fix this week.

What I found: If a user skips profile setup, the welcome modal never triggers — so they miss the tooltips entirely. The analytics event also doesn't fire, which means we can't track drop-off.

My recommendation: Add a deferred trigger that checks on dashboard load whether profile setup was completed, and fires the modal + analytics event then. Low risk, minimal code change.

We could also backfill the analytics retroactively, but I'd tackle the modal first since that's the user-facing piece. Happy to hear other thoughts.

No rush — let me know when you have 15 min to chat it through.

Quick checklist before sending

Before presenting the refined message, run through this mentally:

• Is the ask clear and near the top?
• If multiple people are mentioned, is it clear who should do what?
• If a problem was raised, is there a suggested next step?
• Is the context brief (1-2 sentences) or linked out?
• Does it signal flexibility on timing?
• Can it be scanned in ~30 seconds?

If any of these are missing, adjust before presenting.