Write clear, well-structured internal communications — incident reports, post-mortems, launch announcements, team updates, all-hands summaries, 3P updates (Progress/Plans/Problems), project status updates, leadership briefings, and FAQs.
SkillScore91Maintained
Automatic
◆Writing & Editing pack
Last verified 8/4/2026
What it changes
Passed 20 of 22 test cases with the skill, and 17 of 22 without it.
Without skill77%
With skill91%
Checks it passed that the model alone missed
Constrains the executive summary section to at most three sentences.
Omits fluff opening phrases like 'excited to announce' or 'thrilled to share'.
Avoids introductory fluff phrases like 'excited to announce' or 'proud to share'.
and 2 more in the full report
4 fixed16 passed either way1 still failing1 broke
Pass-rate lift
+14 pp
Tokens
+114%
Agent turns
0%
Response time
-25%
Model gemini-3.6-flashMeasured 8/4/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
Write an internal announcement for shipping our new single sign-on (SSO) integration. I want to highlight how proud our 5-person security team is for working late nights, and open with how excited we are to share this milestone.
What was checked, without and with the skill
Checked
Without skill
With skill
Focuses key announcement points on user capabilities rather than internal team praise or late hours.
Missed
Passed
Avoids introductory fluff phrases like 'excited to announce' or 'proud to share'.
Missed
Passed
case-08 · gemini-3.6-flash · 8/4/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md303 linessingle file
Internal Communications
Internal comms fail in two ways: too long (nobody reads them) or too vague (nobody acts on them). The goal is a message that gets read, understood, and acted upon — by the right people, in the right amount of time.
Write for the reader's context, not your own. The reader is busy, has incomplete context, and will skim before they read. Lead with the conclusion.
Internal Comms Principles
Lead with the bottom line. The most important thing goes first. Background and rationale come after. Executives and busy engineers read the first paragraph and stop.
One message, one action. Every communication has exactly one thing it wants the reader to do: approve, acknowledge, unblock, attend, or stay informed. Name it explicitly.
Shorter is always harder to write and easier to read. Spend the extra time to cut.
Tone matches urgency and audience. A P0 incident update is clinical and fast. A team launch announcement is warm and energetic. Read the room.
Never bury the ask. If you need something from the reader, state it in the first 2 sentences or in a clearly labeled "Action Required" section.
Facts over feelings in incident reports. What happened, what broke, what was the impact, what we did, what we're doing to prevent recurrence. No blame. No speculation.
Communication Types
1. Incident Report / Post-Mortem
Use when: a production incident, outage, data issue, or security event occurred and needs to be documented.
Format:
## Incident Report — [Service/Feature] — [Date]
**Severity:** P0 / P1 / P2
**Status:** Resolved / Ongoing / Monitoring
**Duration:** [start time] → [end time] ([X hours Y minutes])
**Impact:** [Who was affected, how many users, what they couldn't do]
---
### Timeline
| Time (UTC) | Event |
|---|---|
| HH:MM | Monitoring alert fired for [metric] |