internal_communications_pack v1.0.0

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.