---
name: "internal_communications_pack"
description: "Drafts workplace comms an agent can actually send: 3P updates, project and leadership updates, internal newsletters, FAQs, and incident reports. Ships ready-to-use templates with worked examples and review checklists. Triggers when someone asks to write, format, or review internal updates, team reports, company newsletters, internal FAQs, or incident/postmortem communications."
---

# Internal Communications Pack

## Purpose

Turns scattered notes, bullet dumps, and raw status into finished internal communications: weekly 3P updates (Progress, Plans, Problems), project and leadership updates, company newsletters, internal FAQs, and incident reports. The core rule: never ship a draft shaped like a data dump. Every piece comes back formatted for its audience, with a checklist showing it passed review.

## Workflow

1. **Identify the comm type.** Match the request to one of the five formats below. If it does not clearly fit any of them, fall back to the General comms guidance in `references/templates.md` and ask the user for audience and purpose before drafting.

2. **Gather the facts.** Before writing, confirm: who is this for (team, leadership, whole company), what period it covers (3P/status) or when it happened (incident), and where the facts came from. A draft that cannot name its source gets one line at the top: "Source: unverified, confirm before sending." Never fabricate numbers, dates, quotes, or names.

3. **Match the altitude to the audience.**
   - Team-level: concrete tasks, names, near-term dates. Granular is fine.
   - Leadership / org-level: outcomes, metrics, risks, decisions needed. Drop task-level detail.
   - Whole company: one idea per section, plain language, links out for detail.

4. **Draft from the template.** Use the worked template for the type in `references/templates.md`. Keep the house order of sections exactly; consistency is what makes recurring comms scannable. Every bullet must say what happened and why it matters, not just that work occurred.

5. **Run the review checklist** (in `references/review-checklists.md`) for that type. Fix everything the checklist flags. If a flag cannot be resolved because a fact is missing, mark it `[NEEDS CONFIRMATION]` in the draft instead of guessing.

6. **Return the draft.** Hand back the formatted text plus the source line and any confirmation markers. No preamble about process, just the piece and what still needs the user's eyes.

## Output Contract

- A finished draft in the requested format, matching the template's section order.
- A source note (where the facts came from) and `[NEEDS CONFIRMATION]` markers on anything unverified.
- If the request is ambiguous: one short clarifying question, not a draft full of hedges.

## Operating Rules

1. **Verify before publishing.** Every name, number, link, and owner in the draft gets checked against its source before the draft goes out. Comms errors travel fast and erode trust faster.

2. **Metrics over adjectives.** "Shipped onboarding v2, adoption up 18% week over week" beats "the team crushed it this week." If a metric is unavailable, say so rather than inflating a vibe.

3. **Never invent answers.** For FAQs, only answer what a source supports. A question with no authoritative answer gets "Needs an official response from [owner]" rather than a confident guess.

4. **Incidents stay blameless.** Write about systems and processes, never people. "The log-checking step had no documented owner" is correct. "Sam forgot to check the logs" never ships.

5. **Right-size every piece.** A 3P update reads in 60 seconds. An incident report stays to 1-2 pages. A newsletter leads with the single most important item and links out for depth. Cut throat-clearing and preamble; lead with the news.

6. **One clear ask per problem.** Problems and risks sections name the blocker, its impact, and the specific help or decision needed, with an owner and a date.

7. **Keep recurring formats stable.** Once a team adopts a newsletter or 3P format, new drafts keep the same sections in the same order. Do not restyle for variety.

8. **Style law.** No em dashes, ever. No ChatGPT-speak (delve, unlock, elevate, "in today's fast-paced world", "it's not X, it's Y" pivots, rhetorical questions answered by the writer). Plain, direct language, varied rhythm.