mcpbeat

Messaging

vercel-labs/messaging

Use when turning settled positioning into the lines other people will reuse: the message hierarchy, value propositions per audience, objection handling, and the proof behind each claim.

2k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
359
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/vercel-labs/marketing-team-eve-template --skill messaging

What comes with it

4 134 bytes besides the instruction
references/hierarchy.md

The instruction itself

7 sections, as written by the author

Messaging

Messaging is positioning made reusable. The test of a good messaging set is not whether it reads well but whether someone else can write a page from it without asking you a question.

Positioning has to be settled first. Writing messaging on unsettled positioning produces lines that contradict each other, and nobody can tell why.

The hierarchy

Three levels, each derived from the one above:

  • The core message. One sentence on what the product does and for whom. Everything else has to be consistent with it. This is what a customer should be able to repeat after one visit.
  • Three or four pillars. The reasons the core message is true. Each pillar is a benefit, not a feature, and each is separable: if two pillars could be merged, you have too many.
  • Proof under each pillar. The feature that delivers it, and the evidence that it works.

Three or four pillars, not seven. A pillar nobody can recall isn't doing any work, and past four they stop being distinct.

Writing a claim

Every claim carries a benefit, the mechanism, and proof. Drop the mechanism and it's a boast; drop the proof and it's unfalsifiable.

  • Weak: "Dramatically faster reporting."
  • Better: "Reports run in seconds because the query hits a materialized view rather than the live table."
  • With proof: "...which took one customer's month-end report from four minutes to nine seconds."

Grade every claim before it ships. proven means there's a named customer, a measured number, or a public doc behind it. plausible means it follows from how the product works but nothing external confirms it. assumption means you believe it and can't show it. Write the grade down. The specialists downstream will assert whatever you hand them, so an ungraded assumption becomes a published claim.

Value propositions per audience

One core message, several audiences. The message doesn't change; the benefit you lead with does, because different people are buying different things.

For each audience, write down what they're accountable for, what they lose today, the pillar that matters most to them, and the objection they raise. An economic buyer and a hands-on user get different leads even when the product is identical.

Use their words rather than yours. A phrase lifted from a customer interview or a review consistently beats one written internally, and customer-research is how you get them.

Objections

Every real objection deserves a written answer, including the ones where the honest answer is that the product isn't a fit. A messaging set with no uncomfortable objections in it hasn't been near a customer.

For each: what they actually say, what's underneath it, the honest response, and the proof. When the objection is correct, say who should not buy. That's more persuasive than a deflection and it stops the sales conversations you'd lose anyway.

What good output looks like

Structured enough that a writer can pull from it: the core message, the pillars with their proof and grade, a value proposition per audience, the objections with answers, and the words to use and avoid. references/hierarchy.md has the formats.

Include the anti-list. Naming the phrases that are off-limits, the competitor comparisons you won't make, and the claims you can't yet support saves more downstream trouble than any amount of approved copy.

Handing off

The other specialists write the deliverables. Give them the lines, the proof, and the grades; don't draft their pages. When a claim is graded assumption, say so in the handoff, because the difference between "we're faster" and "we believe we're faster and haven't measured it" decides whether a writer hedges.

How to use it

Copy the folder

Take vercel-labs/messaging from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.