Messaging Framework

Inputs from client-data

• companies/{client_slug}/brand_context.json — resolved brand; read expression (principles, signatureElements, antiPatterns) for compact brand direction and identity.positioning. Reference, never bind — prose guidance, not hard rules.
• companies/{client_slug}/company_context.json — redacted public company facts: name, description, tagline, services, industries, positioning, values, stats, public people profiles
• companies/{client_slug}/messaging/ (optional) — prior frameworks for context
• companies/{client_slug}/voice/voice-profile.md (optional) — entity voice profile (L2)
• companies/{client_slug}/voice/voice-anchors.md (optional) — entity voice anchors (L2)

Voice

Messaging copy is prose, so run the org voice cascade before writing any
audience-facing language (core narrative, pillar statements, proof points,
adaptations).

1. Read the L1 baseline. When the stromy-format MCP is connected, read
   voice://baseline (anti-AI-smell rules) and voice://review (the pre-output
   review checklist) via ReadMcpResourceTool.
2. Read the local L2 profile when present. Resolve the company slug as in
   "Company Data Integration" and read
   companies/<slug>/voice/voice-profile.md and voice-anchors.md
   if they exist. When no slug is in scope, use the local stromy profile only
   if that directory exists; otherwise proceed with L1 only.
3. Two-pass write. Draft the messaging language, run the review checklist
   against it, then rewrite once before finalizing the framework.

This is a text-only voice pass. The skill mentions the cascade as context; it
does not invoke another skill.

Deliverable canvas (prerequisite)

This skill produces a multi-section deliverable. Collaborate through a single
chat artifact — the deliverable canvas. The canvas is the source of truth for
the in-progress draft; chat scroll-back is not.

1. Resolve the section plan from this skill's own workflow. Use the
   approved structure this skill already defines (or the prompt/resource it
   names). The canvas protocol does not invent sections.
2. Choose the substrate. Use markdown by default for strategic wording,
   plans, and other content where layout does not change meaning. Use html
   only when visual arrangement materially affects the user's decision. HTML is
   a one-way display surface only: never call back into an MCP from the
   artifact.
3. Open the canvas. Mint an 8-character hex canvas_id, then emit exactly
   one artifact with identifier canvas-<canvas_id>-<deliverable_type>. One
   chat = one canvas.
4. Iterate in the canvas. After every change, re-emit the full canvas
   as a new version of the same artifact. Never emit deltas. Never mint a
   second canvas mid-session.
5. Self-check before handoff. Every planned section exists, is substantive,
   and appears in the agreed order. No TBD, placeholders, or pending
   structural questions remain.
6. Sign-off gate. Ask the user to confirm the canvas is final before any
   render handoff or client-data write.
7. Construct the envelope. Hand off {deliverable_type, title, client_id, sections:[{id, title, body}], meta:{canvas_id, substrate, methodology_version}}, where methodology_version is 1. The downstream
   formatter or terminal write step consumes the envelope — never raw chat
   history.

Overview

This skill builds structured messaging frameworks — the strategic bridge between positioning and execution. A messaging framework organizes an organization's core claims, supporting evidence, and audience-specific language into a reusable system that teams can actually pull from when writing copy, preparing spokespeople, briefing agencies, or planning campaigns.

The skill is format-agnostic: it produces messaging architecture as structured content, then optionally routes a signed-off document through format-prepare-document when the user wants a rendered deliverable. Its default terminal step is to populate companies/{client_slug}/messaging/ so downstream comms skills can consume the same pillars, proof points, and audience profiles without any renderer dependency.

Company Data Integration

If this plugin has no companies/ overlay, STOP. Do not fabricate a brand, invent company details, or default to a Stromy brand. Tell the user: "No client overlay found — I cannot proceed without company data."

Discovery

1. List companies/ in the invoking plugin for available overlays
2. Zero entries → STOP with the message above; one entry → use it by default and state which brand you resolved; multiple entries → ask the user which company's messaging this is for
3. If the companies/{client_slug}/company_context.json file is missing → ask the user to supply company details manually before proceeding

Note: PII (banking details, registration numbers, VAT, billing contacts, personal contact information) is intentionally absent from the deployed plugin overlay. If such data is needed, obtain it from the user directly.

Loading Company Data

companies/{client_slug}/company_context.json  → Company facts: name, description, services,
                                                 industries, positioning, values, stats,
                                                 public people profiles, credentials, pricing
companies/{client_slug}/brand_context.json    → Resolved brand: expression, colors, fonts, logo (for branded output)
companies/{client_slug}/messaging/            → Messaging content library:
  ├── pillars.json         → Reusable messaging pillars with proof attachments
  ├── proof-points.json    → Evidence library organized by type and topic
  ├── audiences.json       → Audience profiles with pain points, vocabulary, decision criteria
  └── narratives.json      → Core narratives, positioning statements, elevator pitches

When a messaging/ directory already exists, the skill operates in update mode — it reads the existing library and builds on it rather than starting from scratch. When no messaging/ directory exists, the skill creates it as part of the output.

Content Assembly

Each component loads from its own source within the messaging library or company profile. When data isn't available, ask the user — don't guess or pull from other skills' data directories.

Framework Component	Source	Fallback
Company positioning	messaging/narratives.json	Ask user
Target audiences	messaging/audiences.json	Ask user
Existing pillars	messaging/pillars.json	Build from scratch
Evidence	messaging/proof-points.json	Ask user
Company identity	company_context.json → company.name / company.description	Ask user
Services/capabilities	company_context.json → company.services[]	Ask user
Industries/positioning	company_context.json → company.industries[] / company.positioning	Ask user
Values	company_context.json → company.values[]	Ask user
People (public bios)	company_context.json → people[]	Ask user
Credentials	company_context.json → credentials[]	Omit

Client resolution: Resolve {client_slug} from the invoking plugin's companies/ directory — never accept it as a parameter or hardcode it. If the plugin has exactly one overlay, use it and name the client in your response. If multiple overlays exist, ask the user which company's messaging they're building.

Framework Types

The skill supports five framework types. Each produces a different structure optimized for a different use case. If the user doesn't specify a type, recommend one based on their context.

Type	Structure	Best For	Recommend When
Message House	Roof (core message) → 3-4 pillars → proof foundation	PR teams, media training, quick internal alignment	User needs a one-page reference for spokespeople or comms teams
Messaging Hierarchy	Layered pyramid: brand promise → positioning → pillars → proof → tone	Comprehensive brand architecture, long-term strategy	User is building or refreshing brand-level messaging from scratch
Messaging Matrix	Audience × message grid with tailored proof per cell	Multi-persona activation, sales enablement, content planning	User has 3+ distinct audiences who need different emphasis
Strategic Narrative	Transformation arc: old world → shift → new world → your role → proof	Category creation, investor decks, thought leadership	User is defining a new category or needs a "why now" story
Product Messaging	Per-product: positioning → feature-benefit-proof table → competitive differentiation	Product launches, PMM, sales collateral	User is launching a product or needs sales-ready messaging

For detailed structural specifications, examples, and configuration options for each type, see framework-types.md.

Workflow

The workflow has 5 phases. Phases 1-3 happen before any messaging is written. This mirrors how practitioners work — the most common messaging failures stem from skipping research and jumping straight to wordsmithing.

Phase 1 — Signal & Scope

Step 1: Understand the request

The user's input could range from "we need messaging for our new product" to a detailed brief with positioning, audiences, and competitive context. Accept whatever form it comes in.

Step 2: Determine scope

Scope	Signals	Framework Type Default
Brand-level	"brand messaging," "company messaging," "who we are"	Messaging Hierarchy
Product/service	"product launch," "new feature," specific product name	Product Messaging
Campaign/initiative	"campaign messaging," "launch comms," event name	Message House
Category/narrative	"why now," "category," "transformation," "investor story"	Strategic Narrative
Audience activation	"sales enablement," "persona messaging," multiple audiences named	Messaging Matrix

Present the recommended scope and framework type. The user can override either.

Step 3: Check existing messaging

If messaging/ exists, read the current library and summarize what's already there. Ask whether the user wants to:

• Build new — Start fresh (existing library preserved but not used as foundation)
• Extend — Add new pillars, audiences, or proof to the existing framework
• Refresh — Revisit and update the existing framework based on new context

Phase 2 — Discovery Interview

Gather the inputs that shape the framework. Apply the same filtering principle as a good strategist: only ask questions whose answers would materially change the output. Pull whatever you can from company data first, then confirm or fill gaps.

Always ask (unless already clear from context):

• What is the primary audience? (even if building for multiple — one must be primary)
• What is the core differentiator? (what makes this meaningfully different from alternatives?)
• What is the desired outcome? (what should the audience think, feel, or do after receiving this message?)

Ask only if unclear from context or company data:

• Competitive landscape (who are the primary alternatives? how do they position?) — saved to narratives.json → competitiveContext for downstream skills like battlecards and thought leadership
• Existing positioning or brand strategy (is there a positioning statement to build on?)
• Tone/voice preferences (formal, conversational, bold, measured?)
• Known objections or skepticism from target audiences
• Proof availability (what evidence exists — data, case studies, third-party validation?)
• Internal alignment needs (is this for one team or cross-functional adoption?)

Pull from data — don't ask:

• Company name, description, services, industries, positioning, values → company_context.json → company.*
• Public people profiles and bios → company_context.json → people[]
• Credentials → company_context.json → credentials[]
• Existing messaging pillars or narratives → messaging/
• Past performance evidence → ask user (curate into messaging/proof-points.json)

For the full interview question bank organized by framework type and scope, see discovery-workflow.md.

Phase 3 — Architecture Proposal

Before writing any messaging, present the structural outline for approval. This is the "strategy checkpoint" — it's much cheaper to restructure an outline than to rewrite finished messaging.

Present to the user:

1. Framework type (with brief rationale)
2. Core message direction (1-2 sentences summarizing the central claim)
3. Proposed pillar themes (3-4 topics, not finished language)
4. Audience map (who gets what adaptation)
5. Proof inventory (what evidence is available, where gaps exist)
6. Identified risks or gaps (missing proof, unclear differentiation, audience conflicts)

Wait for approval or adjustments before proceeding to Phase 4.

Phase 4 — Assembly

Build the framework from the top down. Each layer must be solid before the next one builds on it.

Maintain the unsourced ledger as you draft. Tag each core claim, pillar proof point, and any person quote/bio with its basis — client_data, inferred, or fabricated — as you write it. Anything attributed to a named person with no company_context.people[] source, or a proof point with no client-data evidence, is fabricated — ask the user rather than invent (the Content Assembly fallbacks already say "Ask user" for people/evidence). This ledger seeds asset-feedback.unsourced_content at close-out.

Brand expression (read before writing) — reference, never bind. Before drafting any language, read expression from brand_context.json. If present, use as prose guidance:

• expression.principles — let these inform the register and rhetorical posture of the core message and pillar language (e.g., "Evidence before decoration" → lead with proof, not claim)
• expression.signatureElements — reflect where natural in pillar language and verbal guardrails
• expression.antiPatterns — ban in the framework's language-to-avoid section
• identity.positioning — use as the strategic anchor for the core message direction
• If expression is absent, fall back to the voice profile only with a soft note; no hard failure
• Voice-cascade rule: expression is additive to the L1 baseline + L2 profile bans, never a relaxation. Expression principles may sharpen tone but must not reintroduce a banned construction. Where a Brand Context API narrative is attached (candidate.context), treat it as input evidence for expression principles, not a voice source that overrides the cascade.

Step 1: Core message

Write the single overarching message — the "roof" that everything else supports. This should pass the "cocktail party test": someone should be able to repeat it after hearing it once. Keep it under 25 words.

Test it against three criteria:

• Clarity — Is it immediately understandable without jargon or insider knowledge?
• Differentiation — Could a competitor say the same thing? If yes, sharpen.
• Relevance — Does it address what the audience actually cares about?

Step 2: Messaging pillars

Build 3-4 supporting pillars. Each pillar is a distinct theme that reinforces the core message from a different angle. Pillars should be:

• Mutually reinforcing — Together they build a complete case
• Non-overlapping — Each covers distinct territory
• Memorable — Short enough to recall after 24 hours
• Provable — Each must have at least 2 proof points (enforce this — unsubstantiated pillars get flagged)

For each pillar, write:

• Pillar headline (3-7 words)
• Short statement (single sentence, under 20 words — derivative-ready for battlecards, social, cheat sheets)
• Supporting statement (1-2 sentences expanding the headline)
• 2-4 proof points (see Step 3)
• Message lengths: headline (under 10 words), short (1 sentence), full (2-3 sentences)

Step 3: Proof mapping

Attach evidence to each pillar. Use the proof taxonomy to ensure variety — don't rely on only one type. See proof-taxonomy.md for the full taxonomy and selection guidance.

Proof Type	Examples	Strength
Quantitative	Statistics, benchmarks, ROI figures, performance data	Strongest when specific and verifiable
Customer evidence	Case studies, testimonials, NPS scores, user stories	Strongest when named and from similar context
Third-party validation	Awards, analyst rankings, certifications, media coverage	Strong for credibility, weak for differentiation
Capability	Patents, proprietary methods, unique technology, team expertise	Strong for "how" questions
Credibility markers	Years in business, client logos, market position, team size	Useful but generic — use sparingly
Narrative	Before/after stories, transformation examples, customer journeys	Strong for emotional resonance

Proof gap analysis: After mapping, identify any pillar with fewer than 2 proof points or only one proof type. Flag these to the user with suggestions for what evidence would strengthen them.

Step 4: Audience adaptation

For each audience beyond the primary, create an adaptation layer. See audience-adaptation.md for detailed techniques.

The core principle: the core message stays stable. What changes per audience:

• Emphasis — Which pillar leads (e.g., ROI for executives, ease-of-use for end users)
• Vocabulary — Technical vs. business vs. consumer language
• Proof selection — Which evidence is most relevant to this audience's concerns
• Framing — The "so what" that connects the message to this audience's priorities
• Objection handling — What this audience is most skeptical about

For each audience, produce:

• Audience-specific headline (core message reframed for their perspective)
• Pillar priority order (which pillar leads for this audience)
• Selected proof points (2-3 most relevant per pillar)
• Key objection + response (the #1 thing this audience pushes back on)
• Preferred channels (where this audience is best reached — LinkedIn, conferences, email, etc.)

Step 5: Verbal guardrails

Define what the messaging sounds like — and what it doesn't.

• Voice attributes (3-5 adjectives: e.g., "confident, precise, human" — not "professional, innovative, passionate")
• Language to use — Approved terms, preferred phrases, vocabulary that reinforces positioning
• Language to avoid — Buzzwords, competitor terminology, claims that can't be substantiated, generic phrases ("world-class," "cutting-edge," "solutions")
• Elevator pitch — 30-50 word version of the core message for verbal delivery
• Tagline candidates (optional) — 2-3 options under 10 words

Phase 5 — Validation & Output

Step 1: Quality validation

Run the framework through the validation checklist. See quality-criteria.md for the full checklist.

Quick validation summary:

Criterion	Test
Clarity	Can someone outside the organization repeat the core message after hearing it once?
Differentiation	Could a direct competitor make the same claims? If yes, the framework needs sharpening.
Proof coverage	Does every pillar have 2+ proof points from 2+ proof types?
Audience relevance	Does each audience adaptation address that audience's actual pain points?
Internal consistency	Do the pillars support the core message without contradicting each other?
Actionability	Can a team member pull language directly from this framework to write copy?
Specificity	Does the messaging use precise language, not generic claims?

Flag any criterion that fails and suggest fixes before finalizing.

Fact-verification gate (non-skippable close-out — research://verification-gate).
Proof points are evidence-bearing, so before the framework is marked ready run the
mechanical recheck (read the L1 resource when the connector is present:
ReadMcpResourceTool(server="stromy-format", uri="research://verification-gate")):

• (a) Recompute every derived number in a proof point or core claim (a percentage,
  ratio, growth figure, or delta) from its stated inputs and flag any mismatch.
• (b) Resolve every citation backing a proof point (author/year/venue, analyst
  ranking, study) to a real, findable source via the capability-map path (attended:
  WebSearch / nl-gov-data / confirmed research-apify / attended browser;
  unattended: WebSearch → STOP-and-surface if no free path exists). A real citation
  with an unreachable primary softens + flags "unverified against primary"; contested
  figures across sources soften to a directional statement + flag — neither hard-blocks.
• (c) Trace every non-obvious claim to a source (cite-or-hedge); flag unsourced
  proof points (this enforces the "Provable — 2 proof points" rule mechanically).
• Blocking rule: an unresolved citation or an unreconciled arithmetic
  mismatch means the framework is NOT marked ready — fix the claim (replace a
  fabricated proof point, soften) or ask; never ship on a self-report. Carry the digest
  ({claims, unresolved_citations, recomputed_mismatches}) into the unsourced-ledger
  close-out that feeds asset-feedback.unsourced_content.

Step 2: Produce output

The primary output is a structured markdown document. After the content is finalized, keep that markdown as the canonical messaging artifact. Only if the user explicitly wants a rendered document should you route the signed-off envelope through format-prepare-document. See the Output Format Production section below.

The output structure depends on the framework type — see framework-types.md for type-specific templates.

Step 3: Update content library

After the user approves the framework, offer to save it to the company's messaging library:

companies/{client_slug}/messaging/
├── pillars.json         → Pillar headlines, short statements, message lengths, proof attachments
├── proof-points.json    → All proof points with type, source, and pillar linkage
├── audiences.json       → Audience profiles with adaptations and channel guidance
└── narratives.json      → Core message, elevator pitch, tagline, positioning, competitive context, version/status

Include version and status ("draft", "approved", "under-review") in narratives.json so downstream skills know whether they're building on approved messaging.

This makes the messaging available to downstream skills. If the messaging/ directory already existed, merge new content with existing (don't overwrite unless the user chose "Build new" in Phase 1).

Step 4: Review triggers

Include a "When to revisit" section in the output — messaging frameworks are living documents, not one-time artifacts. Common triggers:

• Major product launch or pivot
• New competitor enters the market
• Audience research reveals shifting priorities
• Quarterly review (recommended cadence for active messaging)
• M&A, leadership change, or rebrand
• Message pull-through analysis shows low adoption

Once the framework is written to companies/{client_slug}/messaging/, mention (never auto-activate) that the user can capture feedback with asset-feedback, and file your own source: agent retrospective there if the run hit an instruction gap or tool-call failure worth fixing.

Reference Files

Load these as needed — do not read all at once.

File	When to Load
framework-types.md	Phase 3 — when selecting framework type or configuring output structure
discovery-workflow.md	Phase 2 — interview question bank and research inputs checklist
proof-taxonomy.md	Phase 4, Step 3 — when categorizing and attaching proof points
audience-adaptation.md	Phase 4, Step 4 — when building audience-specific messaging layers
quality-criteria.md	Phase 5 — validation checklists and common pitfalls
company-data-schema.md	Phase 1 — content library schema for the messaging/ directory

Error Handling

Situation	Response
No positioning exists	Help the user articulate positioning before building messaging — ask about differentiator, audience, and category
No company data available	Gather essentials manually, note that a content library can be created from the output
Existing messaging conflicts with new brief	Surface the conflict, ask which takes priority, document the decision
Insufficient proof points	Flag the gap, suggest evidence types that would strengthen the pillar, proceed with what's available
Too many audiences (5+)	Recommend prioritizing 3-4 primary audiences and noting the rest for future adaptation
User wants "just a tagline"	Explain that a tagline without a framework behind it tends to be arbitrary — offer a lightweight Message House as minimum viable structure
Framework type unclear	Default to Message House (simplest, most portable) and offer to expand later

Output Format Production

Gate: do not produce formatted output until the deliverable canvas sign-off gate has passed (see "Deliverable canvas" above).

This skill owns messaging architecture — framework structure, pillar development, proof mapping, and audience adaptation. A rendered document is optional. The default terminal step is to write companies/{client_slug}/messaging/; only user-requested rendered output should go through format-prepare-document.

Output	Routed renderer	What it provides
DOCX	format-docx	Word document creation with branded styling, heading hierarchy
PPTX	format-pptx-hd	Branded presentation — ideal for Message House and Strategic Narrative visual formats
PDF	format-pdf-hd	PDF creation for distribution-ready frameworks

Default: If the user doesn't specify a format, stop at the markdown framework plus the companies/{client_slug}/messaging/ write. Only offer rendered output as an optional follow-on. If they want that follow-on, recommend PPTX for Message House and Strategic Narrative, DOCX for Messaging Hierarchy and Messaging Matrix.

Brand context to carry forward when producing formatted output:

• Brand location: companies/{client_slug}/brand_context.json
• Apply heading color from colors.primary, body font from typography.body, logo from logos/ (path in brand_context.logo)
• Use the document section from brand_context.json for DOCX margins/headers; the presentation block (PPTX layout) stays in charter.json (not compiled)
• Include resolved expression (if present) and deliverable_genre: "messaging-framework" in the envelope for downstream render direction

Output Location

Messaging frameworks follow the Workspace Studio project structure on the operator's local disk:

workspace/<client>/
├── build/<deliverable>/    ← build scripts and intermediates
└── output/<deliverable>/   ← final messaging files (docx, pptx, pdf)

In the Claude app (plugin use) there is no local workspace/ tree. Hand the
finished content to the format skill, which delivers it into the client's
SharePoint space using the folder tree declared in
companies/<slug>/workspace.json. Never create a folder named after this
structure (workspace/, <client>/, output/) in SharePoint; the tree there
is the client's setting, not this skill's.

Override: If the prompt specifies a target output directory, pass it through to the output format skill.