@sellable/mcp 0.1.0

package/skills/create-campaign-v2/references/gold-standard-message-examples.md

@@ -0,0 +1,394 @@
+# Gold-Standard Message Examples
+
+These are the archive winners. Treat them as the **quality bar and motion
+reference**, not a paste source. Your job is to write a new message that could
+plausibly belong in this archive for the motion you're validating — not to
+recolor an existing one.
+
+When to preserve word-for-word:
+
+- the archived winner is the **same company** you're drafting for (e.g.,
+  Superposition drafting for Superposition). Keep casing, spacing, CTA shape,
+  and proof ordering; swap only documented tokens.
+
+Every other case: match the quality bar, match the motion's skeleton (opener
+rhythm, proof placement, CTA tone), but write the sentences fresh from the
+validated brief + sample.
+
+Each example ends with a **Proof ranks used** line so retrieval can line up
+with the proof inventory in `gold-standard-message-patterns.md`.
+
+Do not put active validation fixtures in this file as exact company-specific
+examples. The library should teach transferable winning motions, not leak the
+fixture answer into Phase 84.
+
+## Example 1: Revvix / Spektion Event-Led Security
+
+Use when the brief has:
+
+- a real security event
+- booth or logistics detail
+- a low-pressure coffee / demo ask
+
+Template shape:
+
+```text
+Subject: RSAC next week
+
+Hey {{first_name}},
+
+So I noticed you'll be at RSAC and wanted to reach out before the week gets crazy.
+
+Most {{team_type}} we chat with are sending thousands of "critical" CVEs to IT, and it's getting harder to prioritize the ones that matter most.
+
+We show what's actually exploitable on your endpoints based on runtime activity, including AI tools that scanners might miss.
+
+We'll be at the Spektion booth ESE #7 all week, happy to grab a coffee or just say hi.
+
+Let me know if this sounds interesting.
+```
+
+Why it works:
+
+- concrete, time-bound trigger first
+- one pain statement
+- one mechanism
+- one low-pressure event CTA
+- no extra proof laundry list
+
+**Proof ranks used:** rank 1 (mechanism — "actually exploitable on endpoints based on runtime activity"). Event hook carries relevance; proof is intentionally light.
+
+If the brief has an event motion but the lead sample does not validate attendee
+proof, do not fake the event hook. Borrow the brevity and single-pain structure
+instead of the explicit event claim.
+
+Preferred non-attendee variant:
+
+```text
+Subject: RSAC next week
+
+Hey {{first_name}},
+
+RSAC is next week so reaching out before things get hectic.
+
+Most {{team_type}} we chat with are sending thousands of "critical" CVEs to IT, and it's getting harder to prioritize the ones that matter most.
+
+We show what's actually exploitable on your endpoints based on runtime activity, including AI tools that scanners might miss.
+
+Happy to grab a coffee at the Spektion booth or send a short overview first.
+```
+
+## Example 2: Stack-Replacement Operator Diagnostic
+
+Use when the brief has:
+
+- HubSpot / Salesforce / form-routing workflow pain
+- inbound or paid traffic leakage
+- a lightweight overlay / no-migration promise
+- credible social proof, backing, founder-proof, or a concrete diagnostic that
+  is strong enough to make the buyer care
+
+Preferred expanded InMail shape:
+
+```text
+Curious how you're handling the current stack between HubSpot/Salesforce, form routing, scheduling, and follow-up today. Most teams end up duct-taping 3-4 tools together and good leads die somewhere in that handoff.
+
+[Product] replaces that whole chain with one lightweight AI layer. Capture, qualify, route, and book without asking the team to rip out the CRM.
+
+[Use the strongest true thing available from the brief here: a named customer
+result, a concrete diagnostic, a founder/builder credibility point, a proof
+asset, or a specific offer. Do not add a PS just because the template has one.]
+```
+
+Why it works:
+
+- names the exact workflow/tool
+- names the current stack, not just the abstract category
+- says what is wrong with the stack in buyer-language terms
+- identifies the loss clearly
+- positions the product as a lightweight fix
+- uses the strongest true proof or offer available, wherever it belongs
+- sounds like one operator typed it, not like a framework assembled it
+
+**Proof ranks used:** rank 1 (mechanism — "lightweight overlay / AI layer
+replacing the stack") in body, then the strongest safe proof available from the
+brief. Do not reserve proof for a PS by default. If the strongest proof is a
+customer result, it can sit in the body. If the strongest asset is a teardown,
+audit, report, video, or diagnostic, it should usually become the CTA. If the
+strongest credibility is founder/backing/prior-company proof, a short PS can
+work, but only when it makes the message more believable instead of more
+templated.
+
+**This is also the default proof-led specialist fallback exemplar.** When the
+brief has no event, no active signal, and no hiring hook, default to this
+decision process even if the category isn't stack-replacement: observed
+current-state → what breaks → product-name-first mechanism → strongest true
+proof / offer / asset. The point is not to fill a shape; it is to surface the
+best reason a real buyer should reply.
+
+For dry mode, use only the safe proof available in `brief.md`. Preserve the
+logic even when the exact proof number is unavailable. Never invent a metric to
+make the shape work.
+
+## Example 3: Superposition Exact Job-Post Template
+
+Use when the brief has:
+
+- founder / CEO buyer
+- active hiring signal
+- exact proof stack already validated
+
+Template shape:
+
+```text
+Hey {{firstName}},
+
+Saw you posted for {{a role}} — I'm sure every recruiter on LinkedIn is already in your DMs.
+
+But..
+
+I placed the first engineering hire at Brex.
+
+Then built an agent that helps early startups make hires they didn't think were possible.
+
+We've placed candidates from Fortune 500 companies, SpaceX, and Apple at startups with 4-person teams.
+
+13 founding engineer roles filled at early startups, including:
+- Newton (YC24)
+- Vitable Health (YC20)
+- Plastic Labs
+
+The whole thing is outcome-based, so you only pay when someone actually starts.
+
+Two quick options:
+
+a) 15-min call — find the uncommonly specific {{role}} who's the exact right fit for your team
+
+b) see why Vince at Plastic Labs calls Superposition "a no-brainer" - we scanned 43,802 candidates to find 15 that matched traits no resume would show
+
+superposition.ai/case-studies/how-plastic-labs-hired-founding-engineer
+```
+
+Why it works:
+
+- exact ordering matters
+- proof compounds line by line
+- the CTA is part of the mechanism, not a generic ask
+- freestyling makes it worse
+- this is a good example of proof as stacked credibility, not just product
+  explanation
+
+**Proof ranks used:** rank 5 (founder proof — "first engineering hire at Brex"), rank 2 (named social proof — Newton, Vitable, Plastic Labs, Vince quote), rank 3 (concrete outcome — "43,802 candidates to find 15"). This is proof _stacking_, only valid when every line is verifiable.
+
+**Word-for-word preservation applies here only when the brief is Superposition
+itself.** For other job-post motions, match the rhythm (acknowledge the
+recruiter DMs → founder credibility → specific client proof → outcome-based
+CTA) but write fresh sentences from the brief's actual proof.
+
+## Example 4: Galley Event / Pass / Demo
+
+Use when the brief has:
+
+- real event
+- free pass or attendance hook
+- concrete booth demo
+- tactile operational pain
+
+Template shape:
+
+```text
+Subject: catersource booth 1517
+
+Hey {{first_name}},
+
+not sure if catersource is on your radar next week, but we're at a booth and I've got some free attendance passes if you want one (code: PARTNER2026).
+
+Wanted to reach out though as we just built an AI that reads the messiest BEOs and turns them into production-ready plans in minutes. recipes, purchasing, prep, nutrition, all mapped automatically.
+
+The part where your team spends hours rebuilding every event order by hand, that's what this replaces.. And a bit more
+
+We're doing live demos at the booth. With the free pass you can join the conference and bring a BEO, we'll run it through right there.
+
+So if you're around LA march 3-5, would love to have you stop by. first-look slots are filling up though so lmk if you want me to hold one.
+```
+
+Why it works:
+
+- pass + booth + BEO are concrete objects
+- tactile pain beats abstract ops language
+- casual tone matters
+
+**Proof ranks used:** rank 1 (mechanism — "AI that reads the messiest BEOs and turns them into production-ready plans in minutes"), rank 4 (deployment / speed — "in minutes" + "we'll run it through right there"). No social proof; the concrete asset (pass + booth + BEO walk-through) carries the weight.
+
+## Example 5: Superpower Signal-Led Benefits
+
+Use when the brief has:
+
+- signal-led topic engagement
+- benefits / rewards / wellness buyers
+- proof-heavy preventive-health positioning
+
+Template shape:
+
+```text
+hey {{first name}},
+
+saw you were active around some {{topic}} stuff recently and figured this might actually be relevant
+
+any chance you're exploring early detection or preventive health programs at {{company}}?
+
+we screen for 1,000+ conditions from a single blood draw and surface risks before they ever become claims.
+
+basically your team gets to see what's coming instead of just reacting to it
+
+can I send over some more info?
+```
+
+Alternative proof-led variant:
+
+```text
+hey {{first name}},
+
+saw you were active in some {{topic}} conversations recently and wanted to run something by you
+
+most annual physicals test 15 biomarkers max.
+
+there's over 100 that actually matter and the gap between those two numbers is where the expensive claims tend to sit
+
+teams like Lyft and Notion are already exploring this. one draw, 1,000+ conditions, $199 a person.
+
+if your claims costs have been going up and you're not sure where it's coming from... that gap may be a good place to start looking
+
+can I send over some more info?
+```
+
+Why it works:
+
+- signal comes first
+- all lowercase matters
+- the CTA stays tiny
+- this should not get polished into generic benefits copy
+- the proof sentence does real work; it is not optional filler
+
+**Proof ranks used:** rank 1 (mechanism — "1,000+ conditions from a single blood draw"), rank 3 (concrete outcome — "15 biomarkers vs 100 that matter" + "$199 a person"), rank 2 (named social proof — Lyft, Notion). Lowercase tone is load-bearing; polishing it kills the signal-led voice.
+
+## Example 6: Signal-Led Honest Operator
+
+Use when the brief has:
+
+- a real content or topic-engagement signal
+- a founder/operator sender voice
+- a product that can be explained simply in one or two lines
+- a motion where "two options" feels natural
+
+Template shape:
+
+```text
+hey {{first_name}},
+
+reaching out because it looked like you were active around some {{signal_topic}} recently.
+
+figured this might actually be relevant.
+
+[product] does [simple one-line mechanism].
+
+two options:
+
+a) [useful working-session / direct conversation option]
+
+b) [short overview / lightweight alternate only if the brief supports it]
+
+p.s. [short proof line]
+```
+
+Why it works:
+
+- the signal is first and easy to understand
+- the "figured this might actually be relevant" line feels honest without
+  over-explaining
+- the product is framed simply
+- "two options" makes the CTA easy to scan
+- the proof stays short and sits in the `PS`
+
+Important constraint:
+
+- borrow the honesty and option structure from `sellable.dev`, but do not copy
+  the exact Claude-terminal gimmick unless the brief explicitly supports it
+  and the product can really carry that move
+
+**Proof ranks used:** rank 1 (mechanism) in the one-line product sentence, rank 2 or 5 (social proof or founder/backing) in the PS. "Two options" is the CTA shape; proof stays small and honest.
+
+## Example 7: Useful CTA Shapes
+
+Use when the brief supports a useful next step but not a hard meeting ask.
+
+From Gelee:
+
+```text
+is this worth a look or should i send a short overview first?
+```
+
+From Galley:
+
+```text
+easiest way to see if it's worth a look is to try it with one of your actual menus. happy to set that up or I can send a 2-min video instead.
+```
+
+Use these patterns to avoid generic asks like:
+
+- worth a conversation?
+- open to a call?
+- worth a look?
+
+Prefer a binary or useful CTA when the brief supports it.
+
+CTA decision rule:
+
+- generate single-ask and A/B options before deciding
+- use A/B only when both choices are genuinely useful and supported
+- for unfamiliar categories, the CTA should name the buyer-specific preview in
+  one short phrase, not list every screen or workflow
+- do not use abstract artifact words like "setup link", "overview", or
+  "walkthrough" unless the message has already made what the buyer will see
+  concrete
+- for new categories, make the CTA object the buyer-specific preview or
+  outcome, not the artifact itself
+
+PS decision rule:
+
+- PS is optional and rare
+- use it only as a natural final aside that lowers commitment, makes a
+  new-category preview easier to picture, verifies the core claim with a wink,
+  or carries one short customer/result proof
+- do not use PS to explain why the pitch is credible, add a second unrelated
+  offer, or patch weak body copy
+
+Proof decision rule:
+
+- metrics, interaction counts, usage counts, time-window claims, and revenue
+  math must pass the "so what?" test
+- if the buyer can immediately understand why the number is impressive and
+  relevant, it can work
+- if the number only proves "this is live" or "we are using it," translate it,
+  test a different placement, or keep it internal
+
+## Hard Rules From The Examples
+
+- keep the opener to one observation or one pain, not both stacked together
+- keep the body to 3 short paragraphs max
+- keep proof to one tight sentence unless the canonical template clearly needs
+  more (Superposition is the only archive winner that stacks proof)
+- when the brief supports stronger proof, choose one compelling proof element
+  rather than a bland generic credibility sentence
+- avoid "X means you're likely..." framing; it reads synthesized
+- avoid "at your stage" and "in a setup like yours"; they sound inferred rather
+  than observed
+- prefer product-name-first mechanism lines over "We built..." when both say
+  the same thing
+- do not use em dashes unless the chosen Primary Example already uses one
+- samples in one set should feel like siblings, not three rhetorical styles
+- **word-for-word preservation only when the archived winner is the same
+  company as the brief.** For every other case, match the quality bar and
+  motion shape without recoloring the exemplar's wording
+- use the full archive for retrieval, but choose one primary example and at
+  most one narrow secondary influence when drafting the final message

package/skills/create-campaign-v2/references/gold-standard-message-patterns.md

@@ -0,0 +1,314 @@
+# Gold-Standard Message Patterns
+
+Use these patterns when validating or drafting messages for `create-campaign-v2`.
+
+The priority is not "write generally good outbound." The priority is:
+
+1. match the quality bar of the real campaign motion
+2. sound like a human operator
+3. make the offer feel specifically relevant to the buyer
+
+## Gold Examples Are a Quality Bar, Not a Paste Source
+
+Treat the archived examples as the quality bar and motion reference. Your
+job is to write a new message that could plausibly belong in the archive for
+the motion you're validating — not to recolor an existing one.
+
+**Exact-template preservation applies only when the archived winner is the
+same company as the brief** (e.g., Superposition drafting for Superposition).
+For every other case, match the skeleton (opener rhythm, proof placement,
+CTA tone) but write fresh sentences from the validated brief + sample.
+
+## Template Synthesis Rule
+
+The brief usually will not hand you a full message template. So before drafting:
+
+1. retrieve the closest 2-4 archived winners for the motion
+2. choose one primary example to anchor the skeleton
+3. optionally borrow one narrow secondary influence for CTA shape, proof
+   compression, or opener rhythm
+4. extract the minimal skeleton that makes the primary example work
+5. adapt that skeleton to the validated brief and safe proof
+6. draft 3 candidates, then run the Finalizer Pass
+
+Do not wait for the brief to contain a perfect appendix.
+Do not average multiple campaign motions together.
+Use the gold set to derive the skeleton, not to spot the nearest lookalike.
+
+## Candidates and the Finalizer Pass
+
+Explore three candidates internally, then **combine the best pieces across
+them** into the final winner. The winner does not have to match any single
+candidate.
+
+Draft shape:
+
+- Candidate A: closest motion-aligned version — match the Primary Example's
+  quality bar without copying its wording
+- Candidate B: strongest proof-forward version — lead with the highest-rank
+  proof the brief safely supports
+- Candidate C: sharpest inbox-distinct opener within the same motion
+
+Finalizer Pass:
+
+1. Best opener across A/B/C (most specific, most observed, least synthesized)
+2. Best proof sentence (highest rank, fully supported by the brief)
+3. Best bridge line (shortest, most buyer-native)
+4. Best CTA (useful next step, proportional to signal strength)
+5. Assemble the winner from those parts inside the chosen motion's skeleton
+6. If stitching stacks two ideas awkwardly, cut to the stronger one
+
+If one candidate already holds the best version of every piece, the winner
+may equal that candidate — name it and declare the winning axis (relevance,
+distinctiveness, proof strength, coherence, inbox readability). Otherwise
+name which candidate each borrowed part came from.
+
+If the assembled winner feels overbuilt, simplify back toward the Primary
+Example's skeleton.
+
+## Proof Inventory Rule
+
+Before drafting, build a proof inventory from the brief and sample.
+
+Rank usable proof in this order:
+
+1. exact differentiated mechanism
+2. named credibility proof or strongest safe social proof
+3. concrete outcome proof
+4. deployment simplicity or speed-to-value proof
+5. founder, backing, prior-company, capital-raised-for-motion, or
+   category-first proof
+
+`founder/backing proof` can include:
+
+- worked at meaningful companies
+- backed by notable operators or investors
+- raised credible capital for this motion
+- first-to-do-X or technically novel proof
+
+Use at least one compelling proof element when the brief supports it.
+Do not leave the message with mechanism only if a stronger safe proof exists.
+
+## Token Fill Rule
+
+Before drafting the winner, explicitly decide:
+
+- token name
+- exact source field
+- allowed transformation
+- fallback rule
+
+Do not improvise tokens inside the copy itself.
+
+## Strategy Order
+
+Choose the highest-specificity validated strategy available:
+
+1. `event-led`
+2. `signal-led`
+3. `job-post-led`
+4. `proof-led specialist fallback`
+
+Do not drop to a lower-specificity strategy unless the stronger one is genuinely
+unsupported by the brief and sample.
+
+## Pattern 1: Event-Led
+
+Use when the brief has a real event motion, real logistics, or a real
+time-sensitive reason to reach out.
+
+Shape:
+
+- concrete event hook first
+- why it is relevant now
+- concrete asset or logistic
+- low-pressure CTA
+
+When attendee proof is missing but the sender-side event motion is real:
+
+- keep the event subject line
+- use a sender-side line like "RSAC is next week so reaching out before things
+  get hectic"
+- do not pretend the prospect is attending
+
+## Pattern 2: Signal-Led
+
+Use when the brief or sample has a real signal:
+
+- post engagement
+- topic engagement
+- visible conversation
+- recent initiative that is already validated
+
+Shape:
+
+- mention the signal plainly
+- explain why it makes this message relevant
+- bring the strongest proof
+- give a low-friction next step
+
+### Pattern 2A: Signal-Led Honest Operator
+
+Use this subpattern when the signal is real, the sender can sound direct and
+slightly unusual, and the best message should feel typed by a sharp operator
+rather than polished by a sales team.
+
+Shape:
+
+- plain signal mention first
+- one line that makes the relevance feel honest
+- simple product framing
+- binary options
+- optional short `PS` with proof as the final line
+
+Prefer:
+
+- lowercase or casual casing when the motion supports it
+- an honest line like "figured this might actually be relevant"
+- two clean options instead of a long CTA paragraph
+- direct wording over polished marketing language
+
+Avoid:
+
+- copying a gimmick like "from a claude code terminal" unless the brief
+  explicitly supports that exact move
+- turning the honest-operator tone into a novelty act
+- adding extra explanation before the signal
+
+## Pattern 3: Job-Post-Led
+
+Use when hiring is the validated hook.
+
+Shape:
+
+- use the hiring observation directly
+- bridge to the exact differentiated proof
+- preserve the canonical template tightly
+
+If the archived winner is already exact, preserve it line-by-line with only the
+documented token substitutions.
+
+## Pattern 4: Proof-Led Specialist Fallback
+
+Use only when event, signal, and hiring hooks are unavailable.
+
+This is the fallback most likely to drift into bland copy, so keep it tight.
+
+**Exemplar:** Example 2 in `gold-standard-message-examples.md` (Stack-Replacement
+Operator Diagnostic). It is the default proof-led fallback exemplar. Its
+rhythm — observed current-state → what breaks → product-name-first mechanism →
+PS for credibility — generalizes across proof-led fallbacks even when the
+category isn't literally stack-replacement.
+
+Shape:
+
+- specialist intro anchored in buyer-language workflow
+- when the motion is stack-replacement, name the current tools or workflow
+  pieces explicitly if the brief supports them
+- state what breaks in that stack in plain buyer-language
+- concrete mechanism (product-name-first when the product can carry it)
+- strongest proof (ideally one compelling element, not a generic credibility
+  sentence)
+- specific low-friction deliverable or fit-check CTA
+
+### Pattern 4A: Stack-Replacement Operator Diagnostic
+
+Use this subpattern when the buyer owns an operational workflow and the
+product replaces a brittle chain of tools, handoffs, or manual glue.
+
+Shape:
+
+- direct workflow question first
+- name the current stack pieces when the brief supports them
+- say what breaks in the handoff in plain buyer-language
+- product-name-first mechanism
+- one simple operational outcome
+- optional short `PS` with proof
+- direct working-session CTA
+
+Prefer:
+
+- buyer-language workflow words from the brief
+- explicit current-stack nouns like CRM, forms, routing, scheduling, follow-up,
+  enrichment, or point-tool names when the brief supports them
+- a concrete "what's wrong with the stack" line
+- concrete mechanism
+- strongest safe proof, ideally one compelling proof element rather than a flat
+  generic proof sentence
+- a useful next step
+- a direct conversational CTA unless the brief explicitly says there is a real
+  asset, report, brief, teardown, video, or other lead magnet to lead with
+- a compact opener that sounds typed, not synthesized
+- product-name-first mechanism lines when the product can be named cleanly
+- a short `PS` for social proof, backing, prior-company proof, or category-first
+  proof when that proof is real and would otherwise bloat the main body
+- if a `PS` is used, keep it to the final line of the message
+- short words and plain sentences a busy buyer can scan fast
+- one sentence per line in the final draft when the channel is InMail or email
+
+Avoid:
+
+- opening with "most teams..." or "scaling X usually means..." when nothing
+  specific follows
+- leaning on one recycled metaphor across every sample
+- abstract noun subjects when a more buyer-native subject exists
+- vague CTA like "worth a look?" when the brief supports a more specific ask
+- synthesized management-speak like "at your stage", "in a setup like yours",
+  or "running X means..." when the buyer has not explicitly signaled that
+- "we built X to..." when "X does Y..." is sharper and more campaign-native
+- leaving out stronger safe proof like founder/backing/first-to-do-X when the
+  brief clearly supports it
+- naming tools that are not actually supported by the brief or lead sample
+- using a `PS` in the middle of the message or before the CTA
+- long multi-clause sentences that make the note hard to scan
+- dense paragraphs with 2-3 sentences packed together on one line
+
+## Subject Line Rules
+
+Prefer:
+
+- event or asset name
+- buyer-language workflow
+- concrete offer
+- concrete relevant object
+
+Avoid:
+
+- abstract category nouns
+- jargon that could fit any campaign
+
+## Deliverable Rules
+
+When the offer is conversational, make the conversation useful.
+Do not default to a lead magnet.
+Lead magnets are opt-in, not default.
+
+Prefer:
+
+- "map your current form-to-CRM flow"
+- "show you what we're seeing"
+- "share a short overview first"
+- "walk through where qualified leads are leaking"
+
+Avoid:
+
+- inventing a report, brief, teardown, video, or asset the brief never
+  mentioned
+- leading with "can I send it over?" unless the brief explicitly says that
+  asset exists and should be the primary offer
+- naked meeting asks with no value
+- "worth a look?" when the brief supports a more concrete next step
+
+## Language Rules
+
+- no em dashes unless the winning template clearly uses them
+- if a `PS` is used, it should generally be the last line
+- be precious with metaphors
+- if one phrase appears in every sample, vary it or remove it
+- copy should feel typed by a person, not assembled by framework
+- if using an archived event-led template, preserve the winning wording tightly
+  unless the brief gives a concrete reason to change it
+- prefer 70-110 words for straightforward InMail motions unless the archived
+  winner is clearly longer
+- if using an archived exact-template winner, preserve its casing, spacing, CTA
+  shape, and proof ordering