@sellable/mcp 0.1.0

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

@@ -0,0 +1,212 @@
+# Gold-Standard Message Validation Example
+
+A fully worked `message-validation.md` that shows what "good" looks like when
+the dry-mode chain runs end to end. Use it as a quality reference for the
+document shape, the Finalizer Pass reasoning, and the voice of the candidate
+messages — not as a template to copy.
+
+The brief behind this example is a fictional event-led security motion for a
+company called `Threshold Defense` attending `BlackHat 2026`. The motion is
+close to Example 1 (Revvix / Spektion) but the sentences are written fresh
+from the fictional brief.
+
+---
+
+```md
+# Message Validation
+
+Status: confirmed
+Mode: DRY MODE (no DB mutation)
+Template Used: event-led canonical template
+Primary Example: Example 1 — Revvix / Spektion Event-Led Security
+Secondary Influence: Example 7 — Useful CTA Shapes (binary option)
+Lead Sample Basis: 3 validated leads (Dana Patel — VP Security Eng at Arco;
+Mariko Stein — Head of AppSec at Fernway; Ben Oduya — Director, Vuln Mgmt
+at Plantform)
+
+## Proof Inventory
+
+- Mechanism: rank 1 — "shows which CVEs are actually reachable at runtime on
+  your endpoints, including unsigned scripts that scanners miss"
+- Credibility / Social Proof: rank 2 — "three Fortune 500 security teams
+  piloting now" (in brief safe-claims)
+- Outcome Proof: none — the brief does not contain a safe outcome number yet
+- Deployment / Simplicity Proof: rank 4 — "runs in read-only mode for the
+  first two weeks, no agent rollout"
+- Founder / Backing / Prior-Work Proof: rank 5 — "built by the team that ran
+  runtime detection at Okta" (in brief safe-claims)
+
+Winner proof pick: rank 1 in the body, rank 5 moved into a short `PS` so the
+body stays event-relevant and the credibility lands without bloating the
+message.
+
+## Token Fill Rules
+
+| Token          | Source Field     | Allowed Transformation | Fallback         |
+| -------------- | ---------------- | ---------------------- | ---------------- |
+| {{first_name}} | lead.firstName   | first token only       | omit token       |
+| {{team_type}}  | lead.titleFamily | plain noun phrase      | "security teams" |
+| {{event}}      | brief.eventName  | literal                | no fallback      |
+
+No other tokens are allowed in this campaign.
+
+## Token Adherence Table
+
+| Sample | Supported Tokens Only | All Tokens Resolved | Proof Safe | Personalization Grounded | Thomas Filters | Result |
+| ------ | --------------------- | ------------------- | ---------- | ------------------------ | -------------- | ------ |
+| Dana   | yes                   | yes                 | yes        | yes                      | pass           | pass   |
+| Mariko | yes                   | yes                 | yes        | yes                      | pass           | pass   |
+| Ben    | yes                   | yes                 | yes        | yes                      | pass           | pass   |
+
+## Candidate Messages
+
+### Candidate A (motion-aligned)
+
+- Why this candidate exists: closest to the Revvix/Spektion rhythm — event
+  hook first, one pain, one mechanism, low-pressure CTA.
+- Message:
+
+  Subject: BlackHat next week
+
+  Hey Dana,
+
+  Saw you'll be at BlackHat and wanted to reach out before the week fills up.
+
+  Most security teams we talk to are watching "critical" CVE counts balloon
+  while reachability stays a guessing game.
+
+  Threshold Defense shows which CVEs are actually reachable at runtime on
+  your endpoints, including unsigned scripts that scanners miss.
+
+  We'll be at booth #4412 all week if you want to grab coffee or just say hi.
+
+  Let me know if worth a few minutes.
+
+### Candidate B (proof-forward)
+
+- Why this candidate exists: leads with the strongest safe proof element
+  (rank 5 founder/backing) to test whether credibility carries the event.
+- Message:
+
+  Subject: BlackHat next week
+
+  Hey Dana,
+
+  Quick one before BlackHat gets busy.
+
+  We built Threshold Defense to fix the reachability guesswork your team
+  probably runs into every week — the CVE list is long but the actually-
+  exploitable set is small and scanners don't show it.
+
+  Three Fortune 500 security teams are piloting now, built by folks who ran
+  runtime detection at Okta.
+
+  Happy to grab coffee at booth #4412 or send a 2-min overview first.
+
+### Candidate C (inbox-distinct opener)
+
+- Why this candidate exists: sharpest opener inside the same motion — uses
+  the buyer's actual daily pain in one line instead of the event as the
+  opener.
+- Message:
+
+  Subject: reachability at BlackHat
+
+  Hey Dana,
+
+  Your scanner queue is probably 4x what it needs to be this week. Most of
+  those "critical" CVEs aren't reachable at runtime.
+
+  Threshold Defense shows which ones actually are on your endpoints,
+  including the unsigned-script path scanners miss.
+
+  We're at booth #4412 all week. Happy to grab coffee or send a short
+  overview first.
+
+## Finalizer Pass
+
+- Best opener: **Candidate C** — "Your scanner queue is probably 4x what it
+  needs to be this week" is sharper than the event-first opener and keeps
+  the event hook intact via the subject line.
+- Best proof sentence: **Candidate A** — "shows which CVEs are actually
+  reachable at runtime on your endpoints, including unsigned scripts that
+  scanners miss" is the cleanest rank-1 mechanism line. B's body line is
+  similar but softer; C's is close to A but slightly less specific.
+- Best bridge: **Candidate A** — single-line transition from pain to
+  mechanism without editorializing.
+- Best CTA: **Candidate C** — "Happy to grab coffee or send a short
+  overview first" is the binary option from Example 7 and matches the
+  low-pressure event motion better than A's open-ended close.
+- Assembly note: clean combination — opener from C, bridge + mechanism from
+  A, CTA from C, plus a new short `PS` carrying the rank-5 founder proof
+  that none of the candidates placed well.
+
+## Selected Winner
+
+- Winner: finalizer-remix
+- Why it won: sharper inbox-distinct opener (distinctiveness) + cleanest
+  mechanism (proof) + low-pressure binary CTA (coherence). No single
+  candidate held all three pieces.
+- Lead: Dana Patel — VP Security Eng at Arco
+- Signals Used: BlackHat attendee (validated in lead-sample.json), runtime
+  security titleFamily
+- Tokens Used: {{first_name}}, {{event}}
+- Message:
+
+  Subject: reachability at BlackHat
+
+  Hi Dana,
+
+  Your scanner queue is probably 4x what you need this week.
+
+  Most of those "critical" CVEs will never actually run on your endpoints.
+
+  Threshold Defense shows you which ones do.
+
+  That includes the unsigned scripts your scanners miss.
+
+  We'll be at booth #4412 all week.
+
+  Want to grab coffee, or should I send a short overview first?
+
+  PS - our team came out of runtime detection at Okta, which is why we
+  started with the reachability problem first instead of more scanner noise.
+
+## Findings
+
+- Event hook is strong enough to carry the message; rank-1 mechanism is
+  clean in the body and rank-5 founder proof fits cleanly in a final-line
+  `PS`.
+- Candidate C's opener beat the event-first opener on distinctiveness
+  without losing the event relevance (it lives in the subject line now).
+- No unsupported tokens, no invented metrics, no fabricated customer names.
+- Sample set reads like three siblings from one campaign, not three
+  experiments — the subject varies but the rhythm and tone match.
+
+## Recommendation
+
+- proceed
+```
+
+---
+
+## What this example demonstrates
+
+- The Primary Example is named explicitly (Example 1), and the winner
+  **matches the quality bar without copying the wording** — the sentences
+  are fresh from the fictional brief but the rhythm is recognizable.
+- The Finalizer Pass actually _combines_ pieces from three candidates into
+  a winner no single candidate produced. Opener from C, bridge and
+  mechanism from A, CTA from C, new `PS` for rank-5 proof.
+- Proof ranks (1 in body, 5 in PS) line up with
+  `gold-standard-message-patterns.md` — the model didn't settle for "one
+  generic credibility sentence."
+- Token fill rules are declared once, with source fields and fallbacks, and
+  the adherence table reports pass/fail per lead.
+- The "What Good Looks Like" bar in `thomas-revision-filters.md` is met:
+  sharp voice, grounded personalization, motion-aligned structure, useful
+  CTA proportional to signal.
+
+Use this example when dry-mode output needs a concrete target for
+reasoning shape and finalizer discipline. Do not copy the Threshold Defense
+sentences into real briefs — it is a fictional motion reference.

package/skills/create-campaign-v2/references/lead-validation-preview.md

@@ -0,0 +1,172 @@
+# Lead Validation Preview
+
+This reference defines the Phase 84 `find leads` output contract.
+
+## Inputs
+
+- `brief.md`
+- optional `lead-source-intake.json`
+- the existing `find-leads` capability in campaignless preview mode
+
+## Output Files
+
+```text
+lead-review.md
+lead-sample.json
+lead-source-intake.json   # only when the user intentionally supplied a source
+```
+
+## Tooling Rules
+
+Preview only:
+
+- use `find-leads` without `campaignOfferId`
+- do not call `import_leads`
+- do not set `selectedLeadListId`
+- do not call `confirm_lead_list`
+- do not create workflow rows or campaign rows
+- do not call `save_domain_filters`
+
+Supplied-source preview:
+
+- `normal-discovery` is the default when the user does not already know the
+  people/accounts.
+- `supplied-linkedin-profiles` uses `load_csv_linkedin_leads` before approval
+  only as preview. Pre-approval calls must omit `confirmed: true`,
+  `campaignOfferId`, `currentStep`, `leadListId`, `sourceLeadListId`, and
+  provider-import parameters.
+- `supplied-domains` uses `load_csv_domains`. Pre-approval confirmation is
+  allowed only to create a standalone `domainFilterId` and must omit
+  `campaignOfferId` and `currentStep`. Use that `domainFilterId` for a
+  campaignless account-constrained people sample.
+  In other words, pre-approval domain CSV confirmation must omit
+  `campaignOfferId` and `currentStep`.
+- `existing-lead-list` samples from the existing Sellable lead list before
+  approval and does not clone/import it until after approval.
+
+`lead-source-intake.json` records:
+
+```json
+{
+  "sourceType": "normal-discovery | supplied-linkedin-profiles | supplied-domains | existing-lead-list",
+  "sourceInputMode": "file | paste | existingLeadList",
+  "filePath": "/absolute/path/to/source.csv",
+  "existingLeadListId": "lead_list_...",
+  "selectedColumns": ["linkedin_url", "title", "company"],
+  "confirmationToken": "preview-token",
+  "normalizedCounts": {
+    "sourceRows": 100,
+    "validRows": 98,
+    "duplicateRows": 1,
+    "invalidRows": 1
+  },
+  "domainFilterId": "domain_filter_..."
+}
+```
+
+## `lead-review.md` Shape
+
+Use a compact markdown report with these sections:
+
+```md
+# Lead Review
+
+## Result
+
+- Status: confirmed | rejected | unclear
+- Confidence: low | medium | high
+- Provider Path: {provider or provider sequence}
+- Source Type: normal-discovery | supplied-linkedin-profiles | supplied-domains | existing-lead-list
+- Source Counts: {rows/accounts supplied, valid, duplicate, invalid}
+- Sample Method: {provider preview, supplied-row sample, existing-list sample, domain-constrained people sample}
+- Preview Count: {n}
+- ICP Match Rate: {x/y or % if supportable}
+- Volume Comparison: above target | in range | below target
+- Expected LinkedIn Funnel: connection acceptance {range}, reply {range}, estimate basis {sample-backed | historical | founder-supplied | directional}
+
+## Source Decision
+
+- Best Path: {provider or provider sequence}
+- Why It Won: {volume + reply-likelihood + fit rationale}
+
+## Expected LinkedIn Funnel
+
+- Source Volume: {n or range}
+- Expected Usable Leads After Filtering: {n or range}
+- Likely Connection Acceptance: {range}
+- Likely Reply Rate: {range}
+- Estimate Basis: sample-backed | historical | founder-supplied | directional
+
+## Pros
+
+- ...
+
+## Tradeoffs
+
+- ...
+
+## Discarded Paths
+
+- ...
+
+## What Matched
+
+- ...
+
+## What Was Noisy
+
+- ...
+
+## Sample Notes
+
+| Name | Title | Company | Why it matched / why it was noisy |
+| ---- | ----- | ------- | --------------------------------- |
+
+## Next Action
+
+- proceed to filter leads
+- revise leads
+- halt for provider/auth issue
+```
+
+## `lead-sample.json` Shape
+
+Write a machine-readable object:
+
+```json
+{
+  "status": "confirmed",
+  "providerPath": ["prospeo"],
+  "previewCount": 25,
+  "icpMatchRate": {
+    "matched": 18,
+    "sampled": 25
+  },
+  "volumeComparison": "in-range",
+  "falsePositivePatterns": ["agencies", "junior SDR titles"],
+  "leads": [
+    {
+      "name": "Jane Doe",
+      "title": "Director of Marketing Operations",
+      "company": "Example SaaS",
+      "linkedinUrl": "https://www.linkedin.com/in/janedoe/",
+      "provider": "prospeo",
+      "signals": ["HubSpot", "hiring demand gen"]
+    }
+  ]
+}
+```
+
+The sample does not need every available provider field. It does need enough
+structure for the next step to decide:
+
+- keep
+- exclude
+- optional supporting signal
+
+For supplied LinkedIn profile CSVs and existing lead lists, avoid generic TAM
+language and provider-discovery framing. For supplied domain/account lists,
+state that domains are account constraints and include actual sampled people
+from those accounts. If the constrained people sample returns zero or too few
+usable rows, write that evidence and route to `revise-leads` or
+`confirm-with-user`; do not remove the `domainFilterId` silently.