Output Skill — Change Communication Production

Overview

This skill produces the change communication layer in two beats. Beat 1 runs at project scaffolding. Beat 2 runs when builds enter implementation. Follow the steps in order. Do not skip steps. Each step has validation criteria that must be met before proceeding.

Beat 1 — Structural Planning

When to run: During project scaffolding (Step 4 in engagement workflow — Project Plan + Blueprint).

Prerequisite: Project plan exists with build sequence and stakeholder map. Constraint matrix or diagnostic exists.

Step 1.1 — Apply the Team Filter

Answer one question: Does this client have a team that will be affected by the builds?

• If yes (team of 2+ people will experience changes from the builds) → proceed to Step 1.2
• If no (solo client, or builds only affect the owner) → this kit does not apply. Stop here. Note in the project plan: "Change communication not required — no team affected by builds."

Validation: The answer is documented in the project plan or master plan.

Step 1.2 — Map the Affected Team

From the reference data and project plan, identify:

• Which builds will affect which team members
• Who will experience new processes, tools, or reporting structures
• Who will have a new person directing their work or changing their workflow

Create a simple mapping:

Validation: Every person named exists in the reference data. Every build referenced matches the project plan.

Step 1.3 — Establish Ownership Mapping

Decide who is gold (process owner) in the communication documents:

• Gold = firm owner. Always. They own the communication — how the team hears about the change, when, and in what framing.
• Stone = operations manager / process owner of the operational system. They execute communication steps within the owner's plan.
• This is the inverse of the SOP. In the SOP, the operations manager is gold. In communication documents, the firm owner is gold.

Document this decision. It applies to all three deliverables when they're built in Beat 2.

Validation: The mapping is written down. It names specific people by name, not by role.

Step 1.4 — Build the Skeleton Communication Sequence

Create a preliminary sequence of communication steps. This is the structural spine — it will be populated with evidence, dates, and specific language in Beat 2.

Minimum skeleton:

Add or remove steps based on the specific builds in the project plan. Every build that touches team members needs a communication step.

Validation: Step 1 has no prerequisite. Every other step has exactly one prerequisite. The gate blocks everything below Step 1. No circular dependencies.

Step 1.5 — Identify Likely Resistance Patterns

From the constraint matrix, anticipate (do not fabricate) the resistance patterns that may surface:

• If the constraint pattern is "Right Person, No System" → likely resistance: "feels like micromanagement," authority questioning of the process owner
• If there's a new hire managing more senior staff → likely resistance: "why is [person] in charge?"
• If the engagement started during a busy period → likely resistance: "why now?"
• If team members have historically escalated directly to the owner → likely resistance: escalation routing will need to shift

These are structural predictions, not evidence. They will be replaced or confirmed with real evidence in Beat 2.

Validation: Each predicted pattern maps to something in the constraint matrix. No pattern is invented from templates.

Step 1.6 — Add Communication Items to Project Plan

Add the following to the project plan:

• Owner announcement as a milestone with target date
• Communication sequence as a reference item
• Note that Beat 2 deliverables will be built when first build enters Implement

Validation: The project plan references the communication sequence. The owner announcement has a target or trigger.

Beat 1 Gate — STOP

Run the Beat 1 Gate checklist from 04-change-communication-quality.md. All items must pass.

Beat 1 is complete. The skeleton lives in the project plan until Beat 2 triggers.

Beat 2 — Evidence-Based Build

When to run: First build enters Implement in the deploy cycle. Real evidence of team dynamics now exists.

Prerequisite: Beat 1 skeleton exists. Evidence is available (session transcripts, emails, Slack messages, or consultant notes showing team dynamics). Client brand system is defined (or use existing deliverables as reference).

Phase 1: Input Gathering and Gap Analysis

Step 2.1 — Read All Inputs

Read the following documents completely before producing anything:

• Beat 1 skeleton (communication sequence, ownership mapping, affected team, predicted resistance)
• Constraint matrix / diagnostic
• Project plan (builds, deploy chain status, stakeholders, outstanding items)
• The SOP or system being deployed
• Evidence of team dynamics (emails, Slack, session transcripts)
• Client quotes (from sessions, interviews, or email)
• Client brand system (skill file, QC checklist, existing deliverables for design reference)

Validation: Can you answer all of the following?

• What builds exist and what deploy stage is each in?
• Who is the process owner of the system being deployed?
• Who is the firm owner / change sponsor?
• What has the team seen so far? What haven't they seen?
• What resistance or confusion has surfaced? From whom?
• What communication has happened? Through what channel? By whom?
• What communication should have happened but hasn't?

Step 2.2 — Identify the Communication Gap

Map the current state against what should exist:

Validation: You can state the gap in one sentence. Pattern: "The [system] has been [approved/built/partially deployed], but the team [hasn't seen it / heard about it only through proxy / doesn't know who owns it / is experiencing outputs without introduction]."

Step 2.3 — Update the Communication Sequence

Take the Beat 1 skeleton and populate it with:

• Specific dates from the project plan timeline
• Specific build references (Build 1, Build 2, etc.)
• Specific names in the "By Whom" column
• Phase dividers aligned to the actual cycle (Before Active Close, During First Close Cycle, After First Close — or equivalent for non-accounting builds)
• Additional steps discovered from the evidence

The skeleton becomes the real communication sequence. Add rows, refine prerequisites, adjust the gate mechanism if needed.

Validation: The sequence has no circular dependencies. Every step has exactly one prerequisite (except Step 1). The gate blocks the correct downstream steps.

Step 2.4 — Identify Resistance Scenarios from Evidence

Replace Beat 1's predicted patterns with actual evidence. From the transcripts, emails, and Slack messages, extract the specific resistance patterns the owner may face:

• What did the team member actually say? (Use their words, not paraphrases)
• What was the context? (Were they responding to the system itself, or to how they learned about it?)
• What pattern does this represent? (Micromanagement, authority questioning, timing resistance, something else)

Build each scenario with: trigger phrase, acknowledge step, redirect, specific language the owner can adapt, avoid note.

Validation: Each scenario has a trigger traceable to actual evidence. The language sounds like the owner based on their quotes. No scenario uses generic template language.

Phase 2: Build the Deliverables

Step 2.5 — Confirm Ownership Color Mapping

Verify the Beat 1 ownership mapping against the brand system:

• Gold = firm owner (process owner of the communication)
• Copper/approver = whoever approves in the underlying operational system (if referenced)
• Stone = operations manager / team execution roles
• Steel blue = consultant
• Green = completed items
• Navy = structure / headers

Cross-reference against the brand skill to confirm color hex values and CSS class names.

Validation: No person appears in two different colors within the same document. The legend will match the CSS.

Step 2.6 — Build the Change Communication Plan

Structure:

1. Header — Client brand, document type, title, date, status badge
2. Context block (dark) — Why this document exists. Current state (what the team has seen, what they haven't). What this fixes.
3. Principles (2-3) — The communication principles driving the sequence. Owner's voice first. Show system before enforcing. Name wins when they happen.
4. Communication Sequence — Grid table with columns: Step number, What Gets Communicated, To Whom, By Whom (color-tagged), Prerequisite, By When. Phase dividers between logical groups. Gate rows where one step blocks others.
5. First Win Protocol (dark block) — Trigger definition, acknowledgment mechanism, example language, why it matters.
6. What This Needs from You — Action items for the owner, organized by timing (before first cycle, during first cycle, after first cycle). Each item has a what and a why.
7. Legend — Owner color dots with names
8. Footer — Client brand primary, consultant secondary

Content rules:

• Reference builds by number so the document maps to the project plan
• Every prerequisite must be traceable to something in the sequence
• The gate row must block downstream steps until the owner's announcement is complete
• Time references must match the actual close/cycle timeline (verify the month)
• No AI writing patterns: no "It's not X, it's Y" constructions, no negation-then-correction patterns, no clever parallel phrases

Step 2.7 — Build the Sponsor Activation Brief

Structure:

1. Header — Client brand, document type, title, date, status badge
2. Context block (dark) — The owner's role in this transition. What's been missing.
3. Team Announcement Framework — Three-part structure (What's Changing, Who Owns It, What It Means for You) with adapt notes and language blocks. Include optional context example.
4. 1:1 Conversation Scenarios — Tab/card structure for each resistance pattern from Step 2.4. Each scenario: trigger phrase, acknowledge step, redirect step, specific language, "avoid" note.
5. Sponsor Moments — 2-3 defined moments with when, duration, format.
6. Coaching Block (dark) — Transcript request framed as capability building. Frame: "leading your team through operational transition is a skill. This is the first time you've had a system to transition to."
7. Change Network — Name the 2-4 people positioned to make the process real for everyone else.
8. Footer

Content rules:

• Speech frameworks are starting points to adapt, never scripts. Label them explicitly as "adapt to your voice."
• 1:1 scenarios must use language that sounds like the owner based on their quotes.
• The coaching ask must be framed as building capability, never as catching mistakes.
• The change network must only include people already named in the project plan.

Step 2.8 — Build the Team Communication Playbook

Structure:

1. Header — Client brand, document type, title, date, subtitle ("Open the section you need. Read through once. Say it in your own voice."), status badge
2. Navigation — Tab bar with each communication type. Each tab shows: label (when), name, time estimate (duration + prep).
3. Sections (one per communication type, tabbed):

• Team Meeting — Meta bar (when/who/duration/format), numbered talking points with time estimates, language blocks, outcome box
• 1:1 Concerns — Meta bar, scenario selector (tabbed), each scenario with trigger, steps, language, avoid note, outcome box
• CEO Memo — Meta bar, 2-3 trigger templates with draft language and fill-in blanks, outcome box
• Weekly Check-In with Process Owner — Meta bar, 3 structured questions (anything need my attention, how's team responding, what do you need from me), outcome box explaining what this replaces

1. Footer

Content rules:

• Every section must be self-contained. The owner should be able to open any tab and use it without reading the others.
• Prep time must be shorter than the conversation itself.
• The playbook is interactive (JavaScript tab switching). Print mode must show all sections expanded.
• The weekly check-in section replaces the owner's old pattern of stepping into details. Name what it replaces explicitly.

Phase 3: Validation

Step 2.9 — Brand QC

Run the client's brand QC checklist against all three documents:

• Light/dark theme correct?
• Typography matches brand system?
• No consultant branding in client-facing areas?
• Header/footer pattern matches existing deliverables?
• Color meanings consistent within each document?
• Ownership mapping matches Step 2.5 decisions?

Step 2.10 — Content Rule Compliance

Scan all three documents for:

• [ ] No "It's not X, it's Y" constructions
• [ ] No "That's not a gift. That's homework" patterns
• [ ] No clever parallel phrases
• [ ] No fabricated experience claims
• [ ] No fabricated quotes — every quote traceable to evidence
• [ ] Role titles match client conventions
• [ ] Names are correct (verify spelling, role assignments)
• [ ] Month references are correct (the close cycle being deployed is the current month, not next month)
• [ ] Build references match the project plan numbering

Step 2.11 — Ownership Mapping Verification

For each document, verify:

• [ ] Gold tags only appear on the process owner of that specific document
• [ ] No person appears in two different colors within the same document
• [ ] Legend matches CSS definitions
• [ ] Border colors on cards/sections match the owner of that content
• [ ] If the same person is gold in one document and a different color in another, the reason is documented

Step 2.12 — Sequence Logic Verification

In the Change Communication Plan:

• [ ] Step 1 has no prerequisite
• [ ] Every other step has a prerequisite that references an earlier step or external condition
• [ ] Gate rows correctly block downstream steps
• [ ] The First Win trigger maps to a real milestone in the project plan
• [ ] Time references are accurate for the current cycle

Step 2.13 — Voice Authenticity Check

For the Sponsor Brief and Playbook speech frameworks:

• [ ] Language patterns match the owner's actual speech (check against quotes in evidence)
• [ ] Sentences are the length the owner actually speaks in
• [ ] Industry-specific terms match what the owner uses (not consultant terminology)
• [ ] The "avoid" notes in 1:1 scenarios are actionable and specific
• [ ] Nothing in the speech frameworks would surprise the owner or feel foreign to them

Output

Beat 1 Output

• Updated project plan with communication items
• Communication sequence skeleton (embedded in project plan or separate planning document)
• Ownership mapping decision (documented)
• Affected team mapping

Beat 2 Output

Three HTML files, all in the client's brand system:

1. [client]-change-communication-plan-[mon]-[yyyy].html
2. [client]-sponsor-activation-brief-[mon]-[yyyy].html
3. [client]-communication-playbook-[mon]-[yyyy].html

File naming follows the client's naming convention (lowercase, hyphens, client name first, mon-yyyy for deliverables).

Quick Reference — Build Order

Beat 1 (at project scaffolding):

1. Apply team filter
2. Map affected team
3. Establish ownership mapping
4. Build skeleton communication sequence
5. Identify likely resistance patterns from constraint matrix
6. Add communication items to project plan
7. Run Beat 1 gate

Beat 2 (when first build enters Implement):

1. Read all inputs including Beat 1 skeleton
2. Identify the communication gap
3. Update communication sequence with evidence and dates
4. Identify resistance scenarios from actual evidence
5. Confirm ownership color mapping against brand system
6. Build Change Communication Plan
7. Build Sponsor Activation Brief
8. Build Team Communication Playbook
9. Run brand QC
10. Run content rule compliance
11. Run ownership mapping verification
12. Run sequence logic verification
13. Run voice authenticity check