@sellable/mcp 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/plugin.json +12 -0
- package/.mcp.json +9 -0
- package/README.md +355 -0
- package/dist/api.d.ts +21 -0
- package/dist/api.js +73 -0
- package/dist/auth.d.ts +60 -0
- package/dist/auth.js +246 -0
- package/dist/engage-memory.d.ts +63 -0
- package/dist/engage-memory.js +354 -0
- package/dist/index-dev.d.ts +2 -0
- package/dist/index-dev.js +17 -0
- package/dist/index.d.ts +7 -0
- package/dist/index.js +8 -0
- package/dist/server.d.ts +1 -0
- package/dist/server.js +499 -0
- package/dist/skills.d.ts +11 -0
- package/dist/skills.js +97 -0
- package/dist/tools/auth.d.ts +30 -0
- package/dist/tools/auth.js +124 -0
- package/dist/tools/blueprint-commit.d.ts +174 -0
- package/dist/tools/blueprint-commit.js +286 -0
- package/dist/tools/bootstrap.d.ts +64 -0
- package/dist/tools/bootstrap.js +246 -0
- package/dist/tools/campaigns.d.ts +589 -0
- package/dist/tools/campaigns.js +892 -0
- package/dist/tools/cells.d.ts +58 -0
- package/dist/tools/cells.js +48 -0
- package/dist/tools/context.d.ts +88 -0
- package/dist/tools/context.js +271 -0
- package/dist/tools/csv-domains.d.ts +73 -0
- package/dist/tools/csv-domains.js +464 -0
- package/dist/tools/csv-linkedin.d.ts +102 -0
- package/dist/tools/csv-linkedin.js +712 -0
- package/dist/tools/direct-campaigns.d.ts +240 -0
- package/dist/tools/direct-campaigns.js +250 -0
- package/dist/tools/engage-bootstrap.d.ts +94 -0
- package/dist/tools/engage-bootstrap.js +205 -0
- package/dist/tools/engage-discovery.d.ts +78 -0
- package/dist/tools/engage-discovery.js +150 -0
- package/dist/tools/engage-memory.d.ts +181 -0
- package/dist/tools/engage-memory.js +143 -0
- package/dist/tools/engage-state.d.ts +72 -0
- package/dist/tools/engage-state.js +62 -0
- package/dist/tools/enrichment.d.ts +167 -0
- package/dist/tools/enrichment.js +174 -0
- package/dist/tools/flow-preflight.d.ts +68 -0
- package/dist/tools/flow-preflight.js +138 -0
- package/dist/tools/framework.d.ts +44 -0
- package/dist/tools/framework.js +153 -0
- package/dist/tools/interaction-mode.d.ts +27 -0
- package/dist/tools/interaction-mode.js +102 -0
- package/dist/tools/leads.d.ts +2417 -0
- package/dist/tools/leads.js +2307 -0
- package/dist/tools/linkedin.d.ts +210 -0
- package/dist/tools/linkedin.js +229 -0
- package/dist/tools/navigation.d.ts +91 -0
- package/dist/tools/navigation.js +381 -0
- package/dist/tools/one-off.d.ts +229 -0
- package/dist/tools/one-off.js +273 -0
- package/dist/tools/processing.d.ts +70 -0
- package/dist/tools/processing.js +56 -0
- package/dist/tools/prompts.d.ts +211 -0
- package/dist/tools/prompts.js +210 -0
- package/dist/tools/provider-preflight.d.ts +21 -0
- package/dist/tools/provider-preflight.js +59 -0
- package/dist/tools/readiness.d.ts +261 -0
- package/dist/tools/readiness.js +510 -0
- package/dist/tools/rows.d.ts +126 -0
- package/dist/tools/rows.js +105 -0
- package/dist/tools/rubrics.d.ts +497 -0
- package/dist/tools/rubrics.js +681 -0
- package/dist/tools/senders.d.ts +44 -0
- package/dist/tools/senders.js +69 -0
- package/dist/tools/sequencer.d.ts +127 -0
- package/dist/tools/sequencer.js +194 -0
- package/dist/tools/tables.d.ts +35 -0
- package/dist/tools/tables.js +36 -0
- package/dist/tools/verify-row.d.ts +36 -0
- package/dist/tools/verify-row.js +38 -0
- package/dist/tools/workspaces.d.ts +140 -0
- package/dist/tools/workspaces.js +139 -0
- package/dist/utils/workspace-root.d.ts +1 -0
- package/dist/utils/workspace-root.js +39 -0
- package/package.json +46 -0
- package/skills/building-gtm-tables/SKILL.md +216 -0
- package/skills/building-gtm-tables/core/auto-execute.yaml +19 -0
- package/skills/building-gtm-tables/core/blueprint-schema.json +72 -0
- package/skills/building-gtm-tables/references/brief-to-blueprint.md +334 -0
- package/skills/building-gtm-tables/references/column-type-catalog.md +318 -0
- package/skills/building-gtm-tables/references/common-blueprints.fixtures.ts +199 -0
- package/skills/building-gtm-tables/references/common-blueprints.md +44 -0
- package/skills/building-gtm-tables/references/failure-taxonomy.md +197 -0
- package/skills/building-gtm-tables/references/uat-seed-prompts.md +37 -0
- package/skills/building-gtm-tables/references/verify-loop.md +74 -0
- package/skills/campaign-messages/SKILL.md +173 -0
- package/skills/campaign-messages/flow.v1.json +75 -0
- package/skills/craft-message/SKILL.md +401 -0
- package/skills/create-campaign/ARCHITECTURE.md +232 -0
- package/skills/create-campaign/DISCUSS.md +296 -0
- package/skills/create-campaign/FLOW_ASCII.md +240 -0
- package/skills/create-campaign/HOST-PARITY-CHECKLIST.md +49 -0
- package/skills/create-campaign/README.md +142 -0
- package/skills/create-campaign/SKILL.md +286 -0
- package/skills/create-campaign/context/README.md +67 -0
- package/skills/create-campaign/context/_TEMPLATE.md +12 -0
- package/skills/create-campaign/context/context.md +35 -0
- package/skills/create-campaign/context/learnings.md +16 -0
- package/skills/create-campaign/context/registry.json +19 -0
- package/skills/create-campaign/core/flow.v1.json +217 -0
- package/skills/create-campaign/core/policy.md +191 -0
- package/skills/create-campaign/core/providers/apollo.json +35 -0
- package/skills/create-campaign/core/providers/prospeo.json +34 -0
- package/skills/create-campaign/core/providers/registry.json +31 -0
- package/skills/create-campaign/core/providers/sales-nav.json +37 -0
- package/skills/create-campaign/core/providers/signal-discovery.json +42 -0
- package/skills/create-campaign/references/brief-template.md +64 -0
- package/skills/create-campaign/references/campaign-quality.md +84 -0
- package/skills/create-campaign/references/copy-calibration-examples.md +120 -0
- package/skills/create-campaign/references/offer-patterns.md +108 -0
- package/skills/create-campaign/references/provider-selection-strategy.md +212 -0
- package/skills/create-campaign/references/question-examples.md +167 -0
- package/skills/create-campaign/references/token-fill-examples.md +81 -0
- package/skills/create-campaign-brief/ARCHITECTURE.md +72 -0
- package/skills/create-campaign-brief/DISCUSS.md +64 -0
- package/skills/create-campaign-brief/README.md +176 -0
- package/skills/create-campaign-brief/SKILL.md +537 -0
- package/skills/create-campaign-brief/references/brief-synthesis-rules.md +100 -0
- package/skills/create-campaign-brief/references/brief-template.md +220 -0
- package/skills/create-campaign-brief/references/campaign-idea-options.md +30 -0
- package/skills/create-campaign-brief/references/copy-appendix-template.md +62 -0
- package/skills/create-campaign-brief/references/draft-lifecycle.md +23 -0
- package/skills/create-campaign-brief/references/examples/MANIFEST.json +89 -0
- package/skills/create-campaign-brief/references/examples/briefs/clover.md +223 -0
- package/skills/create-campaign-brief/references/examples/briefs/galley.md +222 -0
- package/skills/create-campaign-brief/references/examples/briefs/gelee.md +220 -0
- package/skills/create-campaign-brief/references/examples/briefs/hey-digital.md +234 -0
- package/skills/create-campaign-brief/references/examples/briefs/persona.md +231 -0
- package/skills/create-campaign-brief/references/examples/briefs/revvix.md +220 -0
- package/skills/create-campaign-brief/references/examples/briefs/sellable-dev.md +220 -0
- package/skills/create-campaign-brief/references/examples/briefs/superposition.md +233 -0
- package/skills/create-campaign-brief/references/examples/briefs/superpower.md +219 -0
- package/skills/create-campaign-brief/references/examples/briefs/westpark-villas.md +220 -0
- package/skills/create-campaign-brief/references/icp-lock-question-bank.md +43 -0
- package/skills/create-campaign-brief/references/messaging-inputs.md +58 -0
- package/skills/create-campaign-brief/references/output-acceptance-rubric.md +62 -0
- package/skills/create-campaign-brief/references/phase75-active-runtime-message-pack.md +248 -0
- package/skills/create-campaign-brief/references/phase75-canonical-brief-template.md +319 -0
- package/skills/create-campaign-brief/references/phase75-good-brief-and-messaging-examples.md +445 -0
- package/skills/create-campaign-brief/references/quick-research-protocol.md +39 -0
- package/skills/create-campaign-brief/references/reference-sheet-protocol.md +60 -0
- package/skills/create-campaign-brief/references/zero-shot-iteration-rules.md +66 -0
- package/skills/create-campaign-v2/SKILL.md +1619 -0
- package/skills/create-campaign-v2/core/auto-execute.README.md +219 -0
- package/skills/create-campaign-v2/core/auto-execute.yaml +121 -0
- package/skills/create-campaign-v2/core/flow.v2.json +1643 -0
- package/skills/create-campaign-v2/core/policy.md +82 -0
- package/skills/create-campaign-v2/references/ai-tells.md +253 -0
- package/skills/create-campaign-v2/references/approval-gate-framing.md +346 -0
- package/skills/create-campaign-v2/references/draft-lifecycle.md +110 -0
- package/skills/create-campaign-v2/references/escalation-ladder.md +119 -0
- package/skills/create-campaign-v2/references/filter-leads.md +495 -0
- package/skills/create-campaign-v2/references/final-handoff-contract.md +176 -0
- package/skills/create-campaign-v2/references/gold-standard-message-examples.md +394 -0
- package/skills/create-campaign-v2/references/gold-standard-message-patterns.md +314 -0
- package/skills/create-campaign-v2/references/gold-standard-message-validation-example.md +212 -0
- package/skills/create-campaign-v2/references/lead-validation-preview.md +172 -0
- package/skills/create-campaign-v2/references/parallel-critique-protocol.md +368 -0
- package/skills/create-campaign-v2/references/sample-validation-loop.md +289 -0
- package/skills/create-campaign-v2/references/step-13-import-leads.md +151 -0
- package/skills/create-campaign-v2/references/step-15-re-cascade.md +90 -0
- package/skills/create-campaign-v2/references/thomas-revision-filters.md +521 -0
- package/skills/create-campaign-v2/references/thomas-variant-selection.md +202 -0
- package/skills/create-campaign-v2/references/tier-routing-matrix.md +66 -0
- package/skills/create-campaign-v2/references/validation-criteria.md +367 -0
- package/skills/create-campaign-v2/references/watch-link-handoff.md +106 -0
- package/skills/create-campaign-v2-validation/SKILL.md +296 -0
- package/skills/create-post/SKILL.md +1308 -0
- package/skills/create-rubric/SKILL.md +251 -0
- package/skills/engage/SKILL.md +549 -0
- package/skills/engage/core/README.md +23 -0
- package/skills/engage/core/proven-searches.json +11 -0
- package/skills/engage/core/style-guide.template.md +47 -0
- package/skills/engage/core/tracked-people.json +10 -0
- package/skills/enrich-prospects/SKILL.md +97 -0
- package/skills/find-leads/SKILL.md +467 -0
- package/skills/generate-messages/SKILL.md +2361 -0
- package/skills/interview/SKILL.md +132 -0
- package/skills/interview/core/ENGAGE_STYLE_GUIDE.template.md +54 -0
- package/skills/interview/core/ICP.template.md +54 -0
- package/skills/interview/core/VOICE_PROFILE.template.md +101 -0
- package/skills/providers/apollo.md +520 -0
- package/skills/providers/prospeo.md +398 -0
- package/skills/providers/sales-nav.md +372 -0
- package/skills/providers/signal-discovery.md +495 -0
- package/skills/research/SKILL.md +258 -0
- package/skills/research/config.json +9 -0
- package/skills/research/override.md +13 -0
- package/skills/research-prospect/SKILL.md +99 -0
- package/skills/research-sender/SKILL.md +158 -0
- package/skills/workflow-sequences/SKILL.md +85 -0
|
@@ -0,0 +1,445 @@
|
|
|
1
|
+
# Phase 75 Live Brief + Messaging Example Bank
|
|
2
|
+
|
|
3
|
+
Source of truth: [75-LIVE-CAMPAIGN-CORPUS.json](/Users/christianreyes/dev/dittto-fresh/web/.planning/phases/75-canonical-campaign-brief-and-copy-calibration/75-LIVE-CAMPAIGN-CORPUS.json)
|
|
4
|
+
|
|
5
|
+
Full archive of client campaign briefs: [75-ALL-CLIENT-CAMPAIGN-CORPUS.json](/Users/christianreyes/dev/dittto-fresh/web/.planning/phases/75-canonical-campaign-brief-and-copy-calibration/75-ALL-CLIENT-CAMPAIGN-CORPUS.json)
|
|
6
|
+
|
|
7
|
+
Direct copied archive of full campaign brief content + rubrics: [brief-rubric-archive/INDEX.md](/Users/christianreyes/dev/dittto-fresh/web/.planning/phases/75-canonical-campaign-brief-and-copy-calibration/brief-rubric-archive/INDEX.md)
|
|
8
|
+
|
|
9
|
+
This file distills the strongest live campaign briefs currently stored in production. The runtime gold set should stay narrow: active clients only, plus the one Hey Digital campaign that clearly performed and still teaches useful structure. The goal is not to preserve every brief shape forever. The goal is to preserve the patterns that consistently show up in the briefs that are actually usable, persuasive, and close to what Sellable has been shipping manually for clients.
|
|
10
|
+
|
|
11
|
+
Important note:
|
|
12
|
+
|
|
13
|
+
- Use the campaign brief markdown as the message source of truth.
|
|
14
|
+
- Do not use old `MessagingExample` records as the gold source for Phase 75.
|
|
15
|
+
- `Amplify Security` is not part of this live example bank yet because there is no production brief-backed campaign in the corpus. It remains the acceptance fixture for the new command.
|
|
16
|
+
- `sellable.dev` has a very large archive. Only a handful are true gold examples. Do not treat every internal brief as equally strong.
|
|
17
|
+
- Remove weak, speculative, or needlessly adversarial lines from the gold runtime pack before generation.
|
|
18
|
+
- If a flawed example is still useful as a teaching artifact, keep it only inside an explicitly labeled `Bad vs Better` section.
|
|
19
|
+
- Old-client archive material can stay in the raw archive, but it should not be part of the runtime gold pack.
|
|
20
|
+
|
|
21
|
+
Runtime gold pack:
|
|
22
|
+
|
|
23
|
+
- [75-ACTIVE-RUNTIME-MESSAGE-PACK.md](/Users/christianreyes/dev/dittto-fresh/web/.planning/phases/75-canonical-campaign-brief-and-copy-calibration/75-ACTIVE-RUNTIME-MESSAGE-PACK.md)
|
|
24
|
+
|
|
25
|
+
## Winning Campaigns In Scope
|
|
26
|
+
|
|
27
|
+
- `sellable.dev`:
|
|
28
|
+
- `Design Partner Access for Outbound/GTM Leaders` — chosen gold example
|
|
29
|
+
- `Hey Digital`:
|
|
30
|
+
- `Predictable Paid Growth for B2B SaaS Leaders` — chosen gold example
|
|
31
|
+
- `Galley`:
|
|
32
|
+
- `Menu-to-Operations Tool for Multi-Site Foodservice` — chosen gold example
|
|
33
|
+
- `Clover`:
|
|
34
|
+
- `Red Rover — Signal Discovery (Campaign 1)` — chosen gold example
|
|
35
|
+
- `Gelee`:
|
|
36
|
+
- `LinkedIn Agent for Exited Founders - Q1 2026` — chosen gold example
|
|
37
|
+
- `Persona`:
|
|
38
|
+
- `V2 - Content Roadmap for B2B SaaS/Tech Founders` — chosen gold example
|
|
39
|
+
- `Revvix`:
|
|
40
|
+
- `RSAC 2026 Speaker Outreach - Michelle/Daniel V2` — chosen gold example
|
|
41
|
+
- `Superpower`:
|
|
42
|
+
- `Early Detection for Self-Insured Employers` — chosen gold example
|
|
43
|
+
- `Superposition`:
|
|
44
|
+
- `Brex Playbook + Named Proof — YC Job Board Founders` — chosen gold example
|
|
45
|
+
|
|
46
|
+
## What The Best Live Briefs Actually Have
|
|
47
|
+
|
|
48
|
+
- They include message copy inside the brief, not in a separate forgotten place.
|
|
49
|
+
- They explain the offer, then show exactly how the offer becomes message copy.
|
|
50
|
+
- They constrain token filling and personalization instead of trusting the model to improvise.
|
|
51
|
+
- Most do not need a large variant set. One approved message is usually enough unless the ICP is broad or segmented.
|
|
52
|
+
- They include at least one of:
|
|
53
|
+
- exact template lock
|
|
54
|
+
- approved variants
|
|
55
|
+
- bad vs better examples
|
|
56
|
+
- interpolation rules
|
|
57
|
+
- do / don't lists
|
|
58
|
+
- They clarify why the offer is attractive and what specific pain it resolves.
|
|
59
|
+
- They preserve proof discipline. Strong briefs name what proof is safe to use and what must never be fabricated.
|
|
60
|
+
|
|
61
|
+
## Repeating Brief Shapes
|
|
62
|
+
|
|
63
|
+
### 1. Strategy Brief + Copy Pack
|
|
64
|
+
|
|
65
|
+
Used by: `Galley`, `Gelee`, `Persona`, `Superpower`
|
|
66
|
+
|
|
67
|
+
Common structure:
|
|
68
|
+
|
|
69
|
+
- Campaign Objective
|
|
70
|
+
- ICP
|
|
71
|
+
- Meeting Value / Offer
|
|
72
|
+
- Social Proof
|
|
73
|
+
- Messaging Templates or Message Variants
|
|
74
|
+
- Interpolation / token rules
|
|
75
|
+
- DOs / DON'Ts
|
|
76
|
+
- Examples
|
|
77
|
+
|
|
78
|
+
Why it works:
|
|
79
|
+
|
|
80
|
+
- Good balance between strategy and operator-ready execution.
|
|
81
|
+
- Strong for campaigns where multiple variants or levels of personalization are needed.
|
|
82
|
+
- Best default shape for the new `create-campaign-brief` command.
|
|
83
|
+
|
|
84
|
+
### 2. Tight Narrative Brief + Exact Message Lock
|
|
85
|
+
|
|
86
|
+
Used by: `sellable.dev`, `Superposition`
|
|
87
|
+
|
|
88
|
+
Common structure:
|
|
89
|
+
|
|
90
|
+
- Sender
|
|
91
|
+
- ICP
|
|
92
|
+
- Core narrative or message template
|
|
93
|
+
- Exact hook / product line / personalization line
|
|
94
|
+
- A/B offer block
|
|
95
|
+
- Voice rules / anti-patterns
|
|
96
|
+
- Example output
|
|
97
|
+
|
|
98
|
+
Why it works:
|
|
99
|
+
|
|
100
|
+
- Best when the winning message is fragile and should not drift.
|
|
101
|
+
- Prevents the model from “improving” the highest-performing copy into something worse.
|
|
102
|
+
|
|
103
|
+
### 3. Event / Moment-Based Brief
|
|
104
|
+
|
|
105
|
+
Used by: `Galley Catersource`, `Revvix RSAC`
|
|
106
|
+
|
|
107
|
+
Common structure:
|
|
108
|
+
|
|
109
|
+
- Event context
|
|
110
|
+
- Target
|
|
111
|
+
- Pain
|
|
112
|
+
- Offer
|
|
113
|
+
- Hook
|
|
114
|
+
- Proof
|
|
115
|
+
- Message variants
|
|
116
|
+
- Booth / logistics / timing rules
|
|
117
|
+
|
|
118
|
+
Why it works:
|
|
119
|
+
|
|
120
|
+
- Natural urgency does most of the work.
|
|
121
|
+
- The message can stay simple because the event context is already a reason to reply.
|
|
122
|
+
|
|
123
|
+
### 4. Angle Library Brief
|
|
124
|
+
|
|
125
|
+
Used by: `Hey Digital`
|
|
126
|
+
|
|
127
|
+
Common structure:
|
|
128
|
+
|
|
129
|
+
- Offer
|
|
130
|
+
- Target buyer
|
|
131
|
+
- Emotional context
|
|
132
|
+
- Scenario-based angles
|
|
133
|
+
- Messaging rules
|
|
134
|
+
- Readability grade-level rule
|
|
135
|
+
- Message pattern
|
|
136
|
+
- Differentiator list
|
|
137
|
+
- A/B CTA style
|
|
138
|
+
- Logo matching guide
|
|
139
|
+
|
|
140
|
+
Why it works:
|
|
141
|
+
|
|
142
|
+
- Gives the model decision logic, not just copy.
|
|
143
|
+
- Strong when the same offer needs multiple scenario-specific entries.
|
|
144
|
+
|
|
145
|
+
## Workspace Lessons
|
|
146
|
+
|
|
147
|
+
### sellable.dev
|
|
148
|
+
|
|
149
|
+
What to preserve:
|
|
150
|
+
|
|
151
|
+
- Self-aware hook that feels human, not polished.
|
|
152
|
+
- Bold product line with a strong category claim.
|
|
153
|
+
- A/B CTA where option B is a meta demo, not a generic “send info.”
|
|
154
|
+
- The `P.S.` meta-verification line when that exact motion is used.
|
|
155
|
+
- Formatting rules that actively shape how the model writes.
|
|
156
|
+
|
|
157
|
+
Why it is strong:
|
|
158
|
+
|
|
159
|
+
- The offer is concrete and novel: design partner access to a Claude Code-native GTM product.
|
|
160
|
+
- The A/B structure lowers friction without weakening the ask.
|
|
161
|
+
- The brief teaches not just what to say, but how the copy should feel.
|
|
162
|
+
|
|
163
|
+
Reusable patterns:
|
|
164
|
+
|
|
165
|
+
- Require a `Hook`, `Product Line`, `Personalization Line`, and `Offer (A/B Format)` breakdown.
|
|
166
|
+
- Include “research their ICP” guidance directly in the brief.
|
|
167
|
+
- Add a required `P.S.` line only if it is part of the actual proven message.
|
|
168
|
+
|
|
169
|
+
Rubric pattern:
|
|
170
|
+
|
|
171
|
+
- role fit
|
|
172
|
+
- B2B company fit
|
|
173
|
+
- non-competitor
|
|
174
|
+
- budget / affordability
|
|
175
|
+
- geography
|
|
176
|
+
|
|
177
|
+
### Hey Digital
|
|
178
|
+
|
|
179
|
+
What to preserve:
|
|
180
|
+
|
|
181
|
+
- Emotional context section.
|
|
182
|
+
- Scenario-based angle library.
|
|
183
|
+
- Explicit 5th grade language rule.
|
|
184
|
+
- Message pattern section.
|
|
185
|
+
- Differentiator drop list.
|
|
186
|
+
- A/B CTA with a call plus a high-value resource option.
|
|
187
|
+
|
|
188
|
+
Why it is strong:
|
|
189
|
+
|
|
190
|
+
- It treats message creation as decisioning, not just writing.
|
|
191
|
+
- It adapts by scenario: not running paid yet, using the wrong agency, under-trusting paid, and so on.
|
|
192
|
+
- It gives the model a clean structure for picking the right proof and CTA.
|
|
193
|
+
|
|
194
|
+
Reusable patterns:
|
|
195
|
+
|
|
196
|
+
- Include `Emotional Context`.
|
|
197
|
+
- Include `Scenario-Based Angles`.
|
|
198
|
+
- Include a `Message Pattern` section that explains the order of operations.
|
|
199
|
+
- Include a specific non-call asset for option B when appropriate.
|
|
200
|
+
|
|
201
|
+
Rubric pattern:
|
|
202
|
+
|
|
203
|
+
- geography gate
|
|
204
|
+
- marketing leadership gate
|
|
205
|
+
- B2B SaaS gate
|
|
206
|
+
- no fractional / consultant titles
|
|
207
|
+
- optional company size, stage, and ownership checks
|
|
208
|
+
|
|
209
|
+
### Galley
|
|
210
|
+
|
|
211
|
+
What to preserve:
|
|
212
|
+
|
|
213
|
+
- Concrete offer phrasing.
|
|
214
|
+
- Strong event hook in the Catersource brief.
|
|
215
|
+
- Variants with clear tradeoffs: preferred, adapted, shorter.
|
|
216
|
+
- Evergreen brief with approved variants, examples, tone guidance, and campaign notes.
|
|
217
|
+
|
|
218
|
+
Why it is strong:
|
|
219
|
+
|
|
220
|
+
- The offer is tangible. The prospect can imagine exactly what they get.
|
|
221
|
+
- The best Galley briefs are explicit about why the offer works and where the urgency comes from.
|
|
222
|
+
- The better evergreen brief makes token filling and tone constraints very clear.
|
|
223
|
+
|
|
224
|
+
Reusable patterns:
|
|
225
|
+
|
|
226
|
+
- Include `Campaign Notes` with why the offer works and how social proof should be used.
|
|
227
|
+
- Include approved example fills.
|
|
228
|
+
- When an offer is operational, state the output artifact explicitly.
|
|
229
|
+
|
|
230
|
+
Rubric pattern:
|
|
231
|
+
|
|
232
|
+
- current employment
|
|
233
|
+
- company/operator fit
|
|
234
|
+
- geography
|
|
235
|
+
- leadership role fit
|
|
236
|
+
- multi-site complexity
|
|
237
|
+
- exclusion of adjacent but wrong subsegments
|
|
238
|
+
|
|
239
|
+
### Clover
|
|
240
|
+
|
|
241
|
+
What to preserve:
|
|
242
|
+
|
|
243
|
+
- `Overview / ICP / Offer / Credibility` shape.
|
|
244
|
+
- Message template plus filled-in message examples.
|
|
245
|
+
- Reply handling section for what happens after the prospect says yes.
|
|
246
|
+
- Follow-up sequence living inside the same brief.
|
|
247
|
+
- Keyword selection logic for category phrasing.
|
|
248
|
+
|
|
249
|
+
Why it is strong:
|
|
250
|
+
|
|
251
|
+
- The brief treats the outbound message and the positive-reply handoff as one system.
|
|
252
|
+
- The report is the productized asset, so the brief teaches the operator how to sell the report, share the report, and reply once interest appears.
|
|
253
|
+
- It is one of the clearest examples of a brief that includes both outbound copy and downstream conversion handling.
|
|
254
|
+
|
|
255
|
+
Reusable patterns:
|
|
256
|
+
|
|
257
|
+
- Add `Reply Handling` when the campaign depends on sending an asset after the first response.
|
|
258
|
+
- Include `Keyword Selection Logic` when the category phrasing is critical to message quality.
|
|
259
|
+
- Include `Follow-Up Sequence` in the brief when the conversation path is part of the offer design.
|
|
260
|
+
|
|
261
|
+
Rubric pattern:
|
|
262
|
+
|
|
263
|
+
- PLG or self-serve motion
|
|
264
|
+
- right company type
|
|
265
|
+
- decision-maker or adjacent growth title
|
|
266
|
+
- company size band
|
|
267
|
+
- traffic / website reality check
|
|
268
|
+
|
|
269
|
+
### Gelee
|
|
270
|
+
|
|
271
|
+
What to preserve:
|
|
272
|
+
|
|
273
|
+
- Three levels of personalization in one brief.
|
|
274
|
+
- Interpolation guidance for each token.
|
|
275
|
+
- Clear proof stack.
|
|
276
|
+
- Refund / guarantee language guarded inside the brief.
|
|
277
|
+
|
|
278
|
+
Why it is strong:
|
|
279
|
+
|
|
280
|
+
- It degrades gracefully from deep personalization to zero personalization.
|
|
281
|
+
- It keeps the same core promise intact across all variants.
|
|
282
|
+
- It uses proof early without turning into a landing page.
|
|
283
|
+
|
|
284
|
+
Reusable patterns:
|
|
285
|
+
|
|
286
|
+
- Include variant ladder: deep personalization, signal-only, ICP-only.
|
|
287
|
+
- Add interpolation notes for every token, not just example placeholders.
|
|
288
|
+
- Use the brief to define what proof must remain constant across all variants.
|
|
289
|
+
|
|
290
|
+
Rubric pattern:
|
|
291
|
+
|
|
292
|
+
- founder / executive role
|
|
293
|
+
- venture-backed / scale-up fit
|
|
294
|
+
- geography
|
|
295
|
+
- ticket-size qualifier
|
|
296
|
+
- exit / seniority signal
|
|
297
|
+
- digital-first industry
|
|
298
|
+
|
|
299
|
+
### Persona
|
|
300
|
+
|
|
301
|
+
What to preserve:
|
|
302
|
+
|
|
303
|
+
- Explicit messaging guidelines.
|
|
304
|
+
- Industry-personalization guardrails.
|
|
305
|
+
- bad vs better examples from real messages.
|
|
306
|
+
- Template variable examples and proof guidance.
|
|
307
|
+
|
|
308
|
+
Why it is strong:
|
|
309
|
+
|
|
310
|
+
- It teaches the model what not to do with token filling.
|
|
311
|
+
- It locks in the real differentiator: ICP-aligned impressions, not vanity virality.
|
|
312
|
+
- It protects against over-personalizing into weird, narrow niche phrasing.
|
|
313
|
+
|
|
314
|
+
Reusable patterns:
|
|
315
|
+
|
|
316
|
+
- Include `Bad vs Better Examples`.
|
|
317
|
+
- Include `Allowed` and `Never Use` token guidance.
|
|
318
|
+
- Include both a high-touch and low-friction variant.
|
|
319
|
+
|
|
320
|
+
Rubric pattern:
|
|
321
|
+
|
|
322
|
+
- executive title
|
|
323
|
+
- B2B SaaS / tech company fit
|
|
324
|
+
- tier 1 geography
|
|
325
|
+
- exclude direct service competitors
|
|
326
|
+
- bespoke exclusion list when needed
|
|
327
|
+
|
|
328
|
+
### Revvix
|
|
329
|
+
|
|
330
|
+
What to preserve:
|
|
331
|
+
|
|
332
|
+
- Event-led simplicity.
|
|
333
|
+
- One clear message template.
|
|
334
|
+
- Exact interpolation rules for team-type placeholders.
|
|
335
|
+
- Strong do / don’t list around tone and booth details.
|
|
336
|
+
|
|
337
|
+
Why it is strong:
|
|
338
|
+
|
|
339
|
+
- It does not overcomplicate a campaign that already has event urgency.
|
|
340
|
+
- The low-pressure coffee / booth invitation is the right ask for this moment.
|
|
341
|
+
- It keeps the message narrow enough that the model is unlikely to wander.
|
|
342
|
+
|
|
343
|
+
Reusable patterns:
|
|
344
|
+
|
|
345
|
+
- Use a narrow template when event context already provides urgency.
|
|
346
|
+
- Force exact event logistics in the brief.
|
|
347
|
+
- Keep the CTA low-pressure if the primary goal is in-person conversations.
|
|
348
|
+
|
|
349
|
+
Rubric pattern:
|
|
350
|
+
|
|
351
|
+
- security title / practitioner fit
|
|
352
|
+
- exclude academics / hosts / media
|
|
353
|
+
- exclude direct competitors
|
|
354
|
+
|
|
355
|
+
### Superpower
|
|
356
|
+
|
|
357
|
+
What to preserve:
|
|
358
|
+
|
|
359
|
+
- Very simple language.
|
|
360
|
+
- Benefit-led framing around claims risk and early detection.
|
|
361
|
+
- Two variants built around different pain entry points.
|
|
362
|
+
|
|
363
|
+
Why it is strong:
|
|
364
|
+
|
|
365
|
+
- The best parts are clear and easy to read.
|
|
366
|
+
- It avoids jargon and keeps the health / claims gap understandable.
|
|
367
|
+
- It uses signal discovery without getting too abstract.
|
|
368
|
+
|
|
369
|
+
Reusable patterns:
|
|
370
|
+
|
|
371
|
+
- If the domain is complex, force grade-level simplicity in the brief.
|
|
372
|
+
- Keep variants built around different pains, not different writing styles.
|
|
373
|
+
|
|
374
|
+
Rubric pattern:
|
|
375
|
+
|
|
376
|
+
- manager+ seniority
|
|
377
|
+
- benefits / wellness role
|
|
378
|
+
- employer size band
|
|
379
|
+
- exclude brokers / agencies / vendors
|
|
380
|
+
- industry filter when needed
|
|
381
|
+
|
|
382
|
+
### Superposition
|
|
383
|
+
|
|
384
|
+
What to preserve:
|
|
385
|
+
|
|
386
|
+
- Sender narrative.
|
|
387
|
+
- proof points with hard “never fabricate” rules.
|
|
388
|
+
- voice rules and anti-patterns.
|
|
389
|
+
- exact template lock for the main winner.
|
|
390
|
+
|
|
391
|
+
Why it is strong:
|
|
392
|
+
|
|
393
|
+
- This is one of the clearest examples of a brief that protects a message from creative drift.
|
|
394
|
+
- It captures the founder’s actual voice and story, not generic recruiting language.
|
|
395
|
+
- It uses named proof and concrete case-study language instead of vague claims.
|
|
396
|
+
|
|
397
|
+
Reusable patterns:
|
|
398
|
+
|
|
399
|
+
- Use an exact template lock when the winning copy is fragile.
|
|
400
|
+
- Include `Voice Rules`, `Anti-Patterns`, and `Example Output`.
|
|
401
|
+
- Write the brief so the operator cannot accidentally paraphrase the strongest proof.
|
|
402
|
+
|
|
403
|
+
Rubric pattern:
|
|
404
|
+
|
|
405
|
+
- active company / hiring presence
|
|
406
|
+
- founder or senior decision-maker
|
|
407
|
+
- active role status
|
|
408
|
+
- exclude recruiting competitors
|
|
409
|
+
- exclude VCs / accelerators / studios
|
|
410
|
+
|
|
411
|
+
## Cross-Campaign Rules To Canonize
|
|
412
|
+
|
|
413
|
+
- A good campaign brief is not only strategy. It is strategy plus operator-ready copy.
|
|
414
|
+
- The offer must be concrete enough that a prospect can picture the output before replying.
|
|
415
|
+
- A/B CTAs are one of the strongest recurring patterns. Option A is higher commitment. Option B is a lower-friction asset, audit, video, or proof path.
|
|
416
|
+
- Not every campaign needs an A/B CTA. Use it when the second path is genuinely good, low-friction, and worth saying yes to.
|
|
417
|
+
- If there is an easy case study link or proof asset that is genuinely strong, option B should often be “I can send that over.”
|
|
418
|
+
- Do not force a case-study CTA just because the format looks nice. Only use it when the linked proof is real, relevant, and easy to consume.
|
|
419
|
+
- Not every campaign needs multiple message variants. Default to one approved message unless the ICP or sender setup creates real branching.
|
|
420
|
+
- Good briefs explain how to personalize. Great briefs explain how not to personalize.
|
|
421
|
+
- “Bad vs better” examples are high leverage. Persona is the clearest proof.
|
|
422
|
+
- Signal-based campaigns need a clear rule for how the signal gets mentioned and how stale signals are handled.
|
|
423
|
+
- Event-based campaigns should stay simple. Do not over-engineer them.
|
|
424
|
+
- Some campaigns need variant choice. Some need exact-template lock. The brief should choose one intentionally.
|
|
425
|
+
- Social proof must be governed. Named proof, anonymous proof, and semi-anonymous proof should be treated differently.
|
|
426
|
+
- Tone rules should be explicit. If lowercase, say lowercase. If no dashes, say no dashes. If 5th grade language, say 5th grade language.
|
|
427
|
+
|
|
428
|
+
## Canonical Requirements For Future Example Selection
|
|
429
|
+
|
|
430
|
+
Use future campaigns as example-bank candidates only if they have:
|
|
431
|
+
|
|
432
|
+
- a real stored campaign brief
|
|
433
|
+
- message variants or an exact template inside the brief
|
|
434
|
+
- clear offer framing
|
|
435
|
+
- proof rules
|
|
436
|
+
- token-fill or interpolation guidance
|
|
437
|
+
- rubric coverage
|
|
438
|
+
- enough campaign volume to be directionally trustworthy
|
|
439
|
+
|
|
440
|
+
Exclude or de-prioritize campaigns that:
|
|
441
|
+
|
|
442
|
+
- only have high-level strategy with no copy pack
|
|
443
|
+
- rely on old message-example tables instead of the brief
|
|
444
|
+
- have no rubric or no targeting logic
|
|
445
|
+
- only “look smart” but do not show usable operator guidance
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Quick Research Protocol
|
|
2
|
+
|
|
3
|
+
Use quick research only enough to produce a trustworthy `brief.md v1`.
|
|
4
|
+
|
|
5
|
+
## Allowed Inputs
|
|
6
|
+
|
|
7
|
+
- LinkedIn URL supplied by the operator.
|
|
8
|
+
- Optional transcript, proposal, kickoff notes, deck excerpts, ICP notes, prior
|
|
9
|
+
messages, or product notes.
|
|
10
|
+
- Website/domain content from Claude Code `WebFetch` and discovery from
|
|
11
|
+
`WebSearch` when a supplied URL or proof source needs to be checked.
|
|
12
|
+
- Lightweight profile context from `fetch_linkedin_profile` or
|
|
13
|
+
`get_linkedin_profile`.
|
|
14
|
+
- LinkedIn company context from `fetch_company` and recent company posts from
|
|
15
|
+
`fetch_company_posts` when available.
|
|
16
|
+
- Sender post context from `fetch_linkedin_posts` when it materially improves
|
|
17
|
+
credibility, voice, or offer framing.
|
|
18
|
+
- Light company, domain, product, and recent-post research when it materially
|
|
19
|
+
improves target, offer, proof, or voice.
|
|
20
|
+
|
|
21
|
+
## Rules
|
|
22
|
+
|
|
23
|
+
- Do not require `enrich_sender`.
|
|
24
|
+
- Do not run lead sourcing or enrichment.
|
|
25
|
+
- Do not invent proof, customer names, metrics, trigger events, or case studies.
|
|
26
|
+
- If evidence is thin, mark assumptions and ask only blocking questions.
|
|
27
|
+
- Keep a source bundle with facts, inferences, and gaps.
|
|
28
|
+
|
|
29
|
+
## Output
|
|
30
|
+
|
|
31
|
+
Return a research snapshot with:
|
|
32
|
+
|
|
33
|
+
- product facts
|
|
34
|
+
- buyer facts
|
|
35
|
+
- offer clues
|
|
36
|
+
- proof and proof gaps
|
|
37
|
+
- voice clues
|
|
38
|
+
- campaign constraints
|
|
39
|
+
- open questions
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Reference Sheet Protocol
|
|
2
|
+
|
|
3
|
+
Use references explicitly in the operator/runtime context. The operator should
|
|
4
|
+
be able to see and swap the inspiration set before the brief is written.
|
|
5
|
+
|
|
6
|
+
Do not expose this reference sheet in the customer-facing `brief.md`. Internal
|
|
7
|
+
references are calibration inputs, not bibliography.
|
|
8
|
+
|
|
9
|
+
## Default Reference Set
|
|
10
|
+
|
|
11
|
+
Always include:
|
|
12
|
+
|
|
13
|
+
- `phase75-canonical-brief-template.md`
|
|
14
|
+
- `phase75-active-runtime-message-pack.md`
|
|
15
|
+
- 2-4 selected examples from `references/examples/MANIFEST.json`
|
|
16
|
+
|
|
17
|
+
## Selection Rules
|
|
18
|
+
|
|
19
|
+
- Event or moment campaign: prefer `Galley`. Use `Revvix` only when the motion is
|
|
20
|
+
explicitly event/logistics-led and the CTA can be made stronger than "let me
|
|
21
|
+
know if this sounds interesting."
|
|
22
|
+
- Exact narrative or proof discipline: prefer `sellable.dev` and
|
|
23
|
+
`Persona`, unless withheld. Use `superposition` only for job-post /
|
|
24
|
+
founder-hiring motions where the exact proof stack is safe and desired.
|
|
25
|
+
- Plain pain-first benefit framing: prefer `Superpower`, unless withheld.
|
|
26
|
+
- Scenario or angle library: prefer `Hey Digital` and `Persona`.
|
|
27
|
+
- Asset or report-led offer: prefer `Clover`.
|
|
28
|
+
- Personalization ladder: prefer `Persona` or `sellable.dev`. Use `Gelee` only
|
|
29
|
+
for proof-stack reference after adding a clear CTA.
|
|
30
|
+
|
|
31
|
+
Before selecting any reference, ask: what is the strongest true thing we can
|
|
32
|
+
say to this buyer? Pick the reference that best teaches that proof/offer
|
|
33
|
+
mechanic, not the reference with the closest surface format.
|
|
34
|
+
|
|
35
|
+
When the strongest matching reference is withheld, choose the closest
|
|
36
|
+
non-withheld pattern and record the tradeoff.
|
|
37
|
+
|
|
38
|
+
## Holdout Hygiene
|
|
39
|
+
|
|
40
|
+
Withhold the fixture customer's own reference bank entries whenever a holdout
|
|
41
|
+
fixture names a forbidden customer.
|
|
42
|
+
|
|
43
|
+
If the fixture or operator says a customer is forbidden, remove every reference
|
|
44
|
+
from that client for the run. Do not quote, paraphrase, or use that customer's
|
|
45
|
+
brief as inspiration.
|
|
46
|
+
|
|
47
|
+
## Operator-Only Output
|
|
48
|
+
|
|
49
|
+
The reference sheet must include:
|
|
50
|
+
|
|
51
|
+
- selected client
|
|
52
|
+
- file path
|
|
53
|
+
- reference mode
|
|
54
|
+
- why selected
|
|
55
|
+
- known tradeoff
|
|
56
|
+
|
|
57
|
+
The final brief may use the selected references for structure, judgment, and
|
|
58
|
+
quality bar, but it must not name Sellable clients, Phase 75 files, or internal
|
|
59
|
+
brief archives in `Sources Used`, `Good Messaging Examples`, or any
|
|
60
|
+
customer-facing section.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
# Zero-Shot Iteration Rules
|
|
2
|
+
|
|
3
|
+
This file explains how to improve the standalone brief command without turning
|
|
4
|
+
it into an overfit prompt monster. The goal is better zero-shot quality, not a
|
|
5
|
+
larger prompt.
|
|
6
|
+
|
|
7
|
+
## Goal
|
|
8
|
+
|
|
9
|
+
The first-pass output should already be strong enough that the team is polishing
|
|
10
|
+
and calibrating, not rescuing the brief from generic output.
|
|
11
|
+
|
|
12
|
+
## First Named Acceptance Case
|
|
13
|
+
|
|
14
|
+
Use Amplify Security as the first proving run.
|
|
15
|
+
|
|
16
|
+
Acceptance materials:
|
|
17
|
+
|
|
18
|
+
- `tests/fixtures/sellable/brief-generation/amplify-security-grain-call.md`
|
|
19
|
+
- `tests/fixtures/sellable/brief-generation/amplify-security-expected-shape.md`
|
|
20
|
+
|
|
21
|
+
## How To Iterate
|
|
22
|
+
|
|
23
|
+
When the output is weak, diagnose the failure precisely:
|
|
24
|
+
|
|
25
|
+
- ICP too broad
|
|
26
|
+
- offer too generic
|
|
27
|
+
- tone too AI-clean
|
|
28
|
+
- missing client language
|
|
29
|
+
- appendix too bloated
|
|
30
|
+
- questions too weak
|
|
31
|
+
|
|
32
|
+
Then change the smallest useful prompt asset:
|
|
33
|
+
|
|
34
|
+
- brief template
|
|
35
|
+
- synthesis rules
|
|
36
|
+
- example bank
|
|
37
|
+
- appendix template
|
|
38
|
+
- acceptance rubric
|
|
39
|
+
|
|
40
|
+
Do not respond to weak output by dumping more examples into the prompt.
|
|
41
|
+
|
|
42
|
+
## Gold Example Usage
|
|
43
|
+
|
|
44
|
+
Use the gold set to teach contrast:
|
|
45
|
+
|
|
46
|
+
- Sellable.dev
|
|
47
|
+
- Galley
|
|
48
|
+
- Gelee
|
|
49
|
+
- HeyDigital
|
|
50
|
+
- Revvix / Spektion
|
|
51
|
+
- Superposition
|
|
52
|
+
- Persona Digital
|
|
53
|
+
|
|
54
|
+
The model should learn patterns from them, not imitate them line-for-line.
|
|
55
|
+
|
|
56
|
+
## Common Failure Modes
|
|
57
|
+
|
|
58
|
+
- polished but generic
|
|
59
|
+
- too much strategy jargon
|
|
60
|
+
- weak offer differentiation
|
|
61
|
+
- proof used as fluff
|
|
62
|
+
- appendix becoming a copy dump
|
|
63
|
+
|
|
64
|
+
## Success Signal
|
|
65
|
+
|
|
66
|
+
The brief feels like recent manual client work on first pass.
|