Plan change communications
Plans the communications for an organisational change such as a new system, a reorg or a policy, by audience and phase, with key messages, channels, timing, managers' role and feedback loops.
Change communication fails in predictable ways: one big announcement and silence afterwards, the same message for everyone regardless of how they are affected, managers hearing about it at the same time as their teams, no route for questions, and "communication" ending at go-live just when people need help. Change practitioners (Prosci's ADKAR model is a common reference) sequence communication to build awareness of why the change is happening, desire to take part, knowledge of how, ability in practice, and reinforcement afterwards. Their research consistently finds employees want to hear the business reasons from senior leaders and the personal impact from their direct manager, which makes a manager briefing and toolkit central. Messages need repeating several times through different channels before most people have absorbed them. Some changes also carry formal obligations first: in many countries, reorganisations, redundancies and new monitoring tools require consultation with employee representatives, such as a works council or union, before any announcement.
Plan the communications for this change.Only if [GO_LIVE_DATE] is given: Go-live: .
Only if [KNOWN_CONCERNS] is given:
- If the change or the reason for it is unclear, ask up to three questions and stop. A missing go-live date becomes a placeholder, and the timeline uses relative weeks (T-6 weeks).
- Check for obligations that must come before any announcement: employee representative consultation (reorgs, job losses, monitoring tools, working-time changes), legal or HR review, customer or regulator notice. List what applies under Risks and gaps as "check with HR or legal", without stating the law for a specific country.
- Audience impact map: for each audience, what changes for them day to day, the degree of impact (high, medium, low), what they will most likely worry about, what they need to know or be able to do, and who they should hear it from.
- Core messages: one core message (why, what, when, in two sentences), three supporting messages, and what is not changing. Then one line per audience on "what this means for you".
- Timeline across phases: before announcement (leaders and managers briefed first), announcement, preparation and training, go-live, and reinforcement (at least four to six weeks after go-live). For each communication: date or relative week, audience, message, channel, sender, and owner. Leaders explain why; managers explain what it means for the team; training covers how.
- Manager toolkit: what managers get and when (briefing session, talking points, FAQ, where to escalate questions they cannot answer), and what they are asked to do.
- Feedback and measures: the channels for questions and concerns (Q&A sessions, a shared mailbox, pulse questions), how the FAQ is updated and how often, and adoption or understanding measures with targets where the input allows.
- Address each known concern explicitly in messages, timing or support.
- Use only facts from the input; never invent dates, numbers, decisions or names. Use
[need: …]. - Honest messages: no promise that nobody is affected unless the input says so, no spin on reasons, and say what is not yet decided.
- No announcement to affected staff before their managers are briefed, and no all-staff announcement before required consultation is complete.
- Plans proportionate to the change: a small policy tweak gets a short plan; a reorg gets the full treatment.
- Plain language; no change-management jargon in the messages themselves.
Summary
Three to five sentences: the change, the approach and the critical dates.
Audience impact map
Table: audience, what changes, impact level, likely concerns, need to know or do, messenger.
Core messages
Core message, supporting messages, what is not changing, then a line per audience.
Timeline
Table: when, audience, message, channel, sender, owner.
Manager toolkit
Bullets with dates.
Feedback and measures
Bullets.
Risks and gaps
Bullets: obligations to check, risks with mitigations, and [need: …] items.
2 required values still a placeholder; the assistant will ask for them.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Writing and communication
- category
- Business writing
- level
- Intermediate
- made for
- People manager, Operations, Executive / leader, Project / program manager
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-03
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install plan-change-communications --target claude-codenpx skills add hermes-hq/hodios-dist --skill plan-change-communications -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-writing-communication@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of Business writingWrite an internal announcement
Writes an internal announcement of a reorg, policy change or launch that explains what is changing, why, the impact on each group and where to ask, plus an FAQ and a pre-send check.
write-internal-announcementWrite manager talking points for a change
Writes talking points, likely questions with honest answers and a do-not-say list so every manager can cascade an organisational change to their team consistently and truthfully.
write-manager-talking-pointsWrite a customer change notice
Tells customers about a change such as new hours, a move, a temporary closure or a discontinued product - what changes, when, why and what to do - across email, signs, posts and listings.
write-customer-change-noticeWrite an executive summary
Writes an executive summary of a long document that leads with the bottom line, the key points and the ask, using only facts from the source. Use before sending a report to busy readers.
write-executive-summaryWrite a project proposal or business case
Writes an internal project proposal or business case covering the problem, options, recommendation, cost, benefits and risks, and marks every missing number instead of inventing it.
write-project-proposalWrite a project status report
Writes a project status report with an evidence-based RAG status, progress, risks, decisions needed and next steps, formatted as an email, a document or a single slide.
write-status-report