Professional Communication Smart

A comprehensive skill for effective professional communication in software development — covering stakeholder emails, team messaging, meeting facilitation, technical presentations, code review feedback, and cross-functional collaboration with tone and clarity calibration.

When to Use This Skill

Choose Professional Communication Smart when you need to:

• Write clear emails and messages to technical and non-technical audiences
• Provide constructive code review feedback
• Facilitate productive meetings and capture decisions
• Present technical concepts to non-technical stakeholders
• Navigate cross-team communication challenges

Consider alternatives when:

• You need formal business proposals (use a business writing skill)
• You need marketing or sales copy (use a copywriting skill)
• You need academic or research writing (use a technical writing skill)

Quick Start

Copy
# Draft a stakeholder update
claude "Write an email to the VP of Product explaining that the v2.0 release will be delayed by 2 weeks due to a critical security vulnerability found during penetration testing. Tone: professional, transparent, solution-oriented."

Copy
Subject: v2.0 Release — New Timeline: Jan 15 (2-Week Adjustment)

Hi Rachel,

During our pre-release penetration test, we identified a
critical authentication vulnerability that allows session
hijacking under specific conditions. Releasing with this
issue would expose customer data to unacceptable risk.

**What we found**: An attacker with network access could
intercept session tokens during the OAuth2 handshake.

**What we're doing**: The fix is in progress — the
security team has already validated the approach. We need
2 weeks for implementation, testing, and re-verification.

**Updated timeline**:
- Security fix complete: Jan 8
- Regression testing: Jan 8-12
- Final pen test validation: Jan 13-14
- Release: Jan 15

All other v2.0 features remain on track. The delay
affects only the release date, not the feature scope.

Happy to walk through the details in our Thursday sync
if you'd like more technical context.

Best,
[Your Name]

Core Concepts

Communication Matrix

Audience	What They Care About	How to Communicate
Executives	Impact, timeline, risk	One-pager, bullet points
Product Managers	Scope, dependencies	Status updates, tradeoffs
Engineers	Technical details	Code refs, architecture
Designers	UX impact, feasibility	Visual examples, constraints
Customers	Value, reliability	Clear language, no jargon

Code Review Communication

Copy
## Code Review Feedback Tiers

### Blocking (Must Fix)
Prefix: "blocker:" or "must fix:"
Use for: Security issues, data loss risks, broken logic
Tone: Direct, with explanation of the risk

Example: "blocker: This SQL query interpolates user input
directly. This is vulnerable to SQL injection. Use
parameterized queries instead."

### Suggestion (Should Consider)
Prefix: "suggestion:" or "nit:"
Use for: Performance improvements, readability, patterns
Tone: Collaborative, explains the benefit

Example: "suggestion: Consider extracting this into a
helper function — it's duplicated in three places and
will be easier to maintain."

### Question (Seeking Understanding)
Prefix: "question:" or "curious:"
Use for: Understanding intent, exploring alternatives
Tone: Genuinely curious, not passive-aggressive

Example: "question: What was the reasoning behind using
a recursive approach here? I was thinking iteration
might be simpler for this case — but you may have
considered something I'm missing."

### Praise (Acknowledge Good Work)
Prefix: none, or "nice:" or "love this:"
Use for: Clever solutions, clean code, good tests
Tone: Specific and genuine

Example: "Nice — this error boundary pattern handles all
three failure modes cleanly. Really well structured."

Meeting Communication

Copy
## Meeting Types and Communication Approaches

### Decision Meeting
- **Goal**: Leave with a decision made
- **Structure**: Context (2 min) → Options (5 min) →
  Discussion (15 min) → Decision (3 min)
- **Output**: Written decision + rationale + owner

### Status Sync
- **Goal**: Align on current state
- **Structure**: Round-robin updates (2 min each)
- **Output**: Updated status board, new blockers logged

### Brainstorm
- **Goal**: Generate options, not evaluate them
- **Structure**: Diverge (ideas, 20 min) →
  Converge (group, 10 min) → Prioritize (5 min)
- **Output**: Ranked list of ideas for further exploration

### Retrospective
- **Goal**: Identify improvements
- **Structure**: What worked → What didn't →
  Action items (with owners and dates)
- **Output**: 3-5 action items assigned to specific people

Configuration

Parameter	Description	Example
audience	Primary audience for the message	"executive" / "engineer"
purpose	Communication purpose	"status_update" / "feedback"
tone	Desired communication tone	"professional" / "casual"
urgency	Message urgency level	"high" / "normal"
channel	Communication channel	"email" / "slack" / "meeting"
include_action	Include clear action items	true

Best Practices

1. Adapt your communication depth to the audience — An executive needs "release delayed 2 weeks due to security fix" in one sentence. An engineer needs the CVE details, the affected code path, and the proposed fix. Same event, completely different communication.

2. Make code review feedback about the code, not the person — "This function is confusing" becomes "I had trouble following the control flow in this function — would adding early returns for the error cases make the happy path clearer?" The second version invites collaboration instead of triggering defensiveness.

3. Start every message with context for the reader — "Following up on our discussion about the auth migration" orients the reader instantly. Jumping straight into "Can you review the PR?" without context forces them to guess which of their 15 active projects you're referencing.

4. Use structured formats for complex information — Tables for comparisons, numbered lists for sequential steps, bullet points for independent items. A paragraph of text containing 6 dates, 4 names, and 3 decisions is impossible to reference later.

5. Close every communication with a clear next step — "Let me know what you think" is vague. "Please approve option B by Thursday so we can begin implementation on Monday" tells the reader exactly what to do, by when, and why.

Common Issues

Technical jargon alienates non-technical stakeholders — Engineers default to technical language because it's precise. But "the API gateway rate limiter is dropping 503s" means nothing to a product manager. Translate: "Some users are getting errors during peak traffic because our system is rejecting requests to protect itself. We need to increase capacity."

Feedback comes across as passive-aggressive in text — "Interesting approach" in a code review can read as sarcasm. Text lacks vocal tone. When you mean something positively, be explicit: "Interesting approach — I hadn't considered using a state machine here, and it handles the edge cases well." Remove ambiguity.

Meeting decisions aren't recorded and get relitigated — A 45-minute discussion concludes with agreement, but nobody writes it down. Two weeks later, someone remembers the decision differently. Send a brief meeting summary within 24 hours listing each decision made, with rationale and owner. "Per today's meeting, we agreed to use PostgreSQL for the events service. Rationale: existing team expertise. Owner: Alex."