| name | communication-plan |
| description | Produce a PMBOK-shaped communication matrix, escalation paths, and meeting cadence from a project charter and stakeholder register. Invoke when the team needs a formal plan governing how project information flows to each audience. |
Originally authored for Agentic PM Kit (MIT).
When to use
Use this skill once the stakeholder register is complete and the project is entering execution. A communication plan defines the who, what, when, how, and language of every significant information flow. Typical triggers include:
- The project sponsor or PMO requires a formal communications matrix before authorizing the project to proceed.
- A new stakeholder is added and the existing informal communication habits are no longer sufficient.
- A retrospective reveals that key stakeholders received information late, incorrectly, or not at all.
- The project spans multiple organizations, languages, or time zones requiring explicit channel agreements.
Do not invoke as a substitute for the stakeholder-register skill — this skill consumes the register, it does not produce it.
Summon the SME
Before drafting, load the canonical project-communication reference to ground the matrix in established practice.
Reading the config. Check .pm-kit.config.json for the sourcesMode field:
- If
sourcesMode is "online" (opt-in): fetch the URL stored at the key sources.communicationPlan in vendor/pm-kit/sources-index.json using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the facilitation in what you read. Do not fabricate quotations or page numbers from any version of that page.
- If
sourcesMode is "offline" or the field is absent (the default): rely on your general knowledge of project communication management as described by the Project Management Institute and the PMBOK performance domain on Stakeholders. Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.communicationPlan in the output. Do not fabricate quotations or page numbers.
In both cases, the URL to cite is https://en.wikipedia.org/wiki/Communications_management.
Facilitation script
Walk the user through these steps in sequence. Do not skip steps or combine them.
Step 1 — Gather inputs. Ask the user to provide the stakeholder register and the project charter. Confirm both are available. If only one is available, proceed with a note that the plan is provisional until the missing input is obtained.
Step 2 — Classify information types. Review the stakeholder list with the user and agree on the categories of information each audience needs: status updates, decision requests, escalations, training, or celebration / recognition. Assign at least one category per stakeholder.
Step 3 — Assign cadence and channel. For each stakeholder-information pair, confirm the appropriate cadence (daily, weekly, biweekly, monthly, ad-hoc, milestone-only) and channel (email, synchronous meeting, chat, dashboard, shared document). Record channel ownership — who sends, not just who receives.
Step 4 — Define escalation paths. Ask the user to identify who resolves: (a) technical blockers, (b) scope change requests, (c) budget variances, (d) disputes between stakeholders. Record name-or-role and the expected resolution window for each escalation type.
Step 5 — Define the meeting cadence. List all recurring meetings the project will hold (standup, sprint review, retrospective, steering committee, PMO status call, etc.). For each meeting, confirm the audience, purpose, frequency, duration, and facilitator.
Step 6 — Document hygiene rules. Ask the user where decisions will be recorded (e.g., a decision log in the project wiki), where status reports will be stored, and what the retention policy is for meeting minutes. Record these agreements explicitly.
Step 7 — Confirm languages. Verify that the language.output value from .pm-kit.config.json matches the language in which the plan will be distributed. If stakeholders span multiple languages, note this in the plan and confirm which version is the binding source of truth.
Step 8 — Save the artifact. Save the filled artifact to docs/pm-kit/outputs/communication-plan/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 chars) derived from the project name (e.g., bookswap-campus-comms-plan). Confirm the final path with the user before writing. If the file exists, ask: overwrite, append a date suffix (e.g., -2026-04-20), or pick a new slug. The artifact begins with the three-line provenance header below (HTML comments, do not render):
<!-- Generated by agentic-pm-kit:communication-plan on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->
Languages
The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in .pm-kit.config.json and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list.
Facilitation dialogue. Speak to the user during facilitation in the language at language.communication. Use the string verbatim.
Filled artifact (saved TEMPLATE.md output). Produce the written artifact in the language at language.output. If language.output is absent or empty, fall back to language.communication.
Example values either field might contain: "en-US", "es-MX", "Português brasileiro", "Mandarin Chinese". Accept any string as given. This bifurcation is the normative pattern for every skill in the kit.
Acceptance gate
When the plan is complete, point the user to CHECKLIST.md (sibling file) and ask them to verify each item. Remind them that the output must be marked PASS or FAIL. On FAIL, invite the user to return with specific notes so the facilitation can be resumed or corrected.
