@sellable/mcp 0.1.0

package/skills/create-campaign-brief/README.md

@@ -0,0 +1,176 @@
+# Create Campaign Brief
+
+Standalone Sellable MCP command for Phase 83: create the initial high-level
+`brief.md v1` for the brief-first campaign path.
+
+## Host Parity Contract
+
+The command is loaded through the normal Sellable prompt-discovery path:
+
+- `list_subskill_prompts`
+- `search_subskill_prompts`
+- `get_subskill_prompt({ subskillName: "create-campaign-brief" })`
+
+Phase 83 does not require a public `create-campaign-v2` prompt. The command
+name is `create-campaign-brief`.
+
+## Source Bundle Contract
+
+Start from a LinkedIn URL plus optional pasted materials:
+
+- transcript
+- proposal or kickoff notes
+- ICP notes
+- deck excerpts
+- prior messages
+- product or website notes
+- operator-provided campaign idea
+
+The command should still work with sparse input. It must separate known facts,
+assumptions, and blocking gaps instead of inventing proof. Default kickoff is
+LinkedIn-first; website-only is a sparse fallback.
+
+## Workflow Contract
+
+1. Intake a LinkedIn URL and optional materials.
+2. Run quick research only as needed.
+3. Propose 1-3 campaign direction options, or validate the user's idea.
+4. Lock ICP sourcing/filter mechanics.
+5. Confirm an operator-only reference sheet from the example bank.
+6. Define the simple next-step plan: find leads, tighten filter, draft message.
+7. Draft compact messaging inputs and claim boundaries, not final sequences or opener instructions.
+8. Return `brief.md v1` inline and stop.
+
+Interview expectations:
+
+- Default to one `AskUserQuestion` batch.
+- Use a second batch only if a real unknown still blocks `brief-v1`.
+- Ask up to 4 questions per batch and up to 4 options per question.
+- If the company is ambiguous, confirm the company first.
+- Before the question batch, state the current best guess in plain English.
+- Avoid GTM shorthand like `Sales Nav` or `title filters` unless translated.
+- Let founders pick one, pick many, or add their own context when needed.
+- Frame proof/safety questions as "what can we safely say?" not only "what are the don'ts?"
+- A strong default is: `Which of these points would make the buyer most confident?`
+- Keep `Campaign Thesis` in bullets, not a dense paragraph.
+- Keep `Personalization Inputs To Validate` very short; it is mainly a handoff to the next step.
+- Keep archive calibration invisible in the final brief.
+- Keep inferred stack/tool mixes as validation targets unless directly sourced.
+- Treat proof selection as buyer-relative: ask which proof would most increase
+  confidence in the claim, not just which claims are safe.
+
+## Output Contract
+
+Return one Markdown brief inline in the final assistant message. The output is
+`Status: brief-v1`. Immediately after the status, include a short
+`Campaign Direction` summary that makes the campaign obvious fast. Its
+`Sources Used` section is customer-facing
+bibliography only: LinkedIn URL, sender data, website if used, supplied
+materials, and customer-owned research. It must not expose Phase 75 files,
+Sellable client examples, or internal reference names.
+
+Keep `Sources Used` compact: 3-5 bullets with source name + URL or source
+label only. Do not append extraction notes, fetch-status notes, or operator
+commentary there. Put `Sources Used` at the end of the brief so provenance is
+available without leading the reading flow.
+
+Keep `Product` and `Social Proof / Safe Claims` tight. Do not dump long vendor
+lists or turn safe-claims notes into a long risk memo. The brief should read
+like a crisp customer-facing operator note, not a strategy document.
+Choose the most compelling proof for the buyer. That may be customer proof,
+founder/operator credibility, investor/YC backing, or proprietary tech if the
+founder confirms that is what makes the claim more credible.
+
+Do not use `Write`, `Edit`, `Bash`, or any filesystem-mutating tool to persist
+the brief. Do not preface the brief with permission/tool chatter, and do not
+tell the operator to save/copy it somewhere. Only cite sources that were
+actually fetched and confirmed to belong to the customer. Keep product and
+proof claims exact to validated sources; do not inflate channels, integration
+counts, or traction.
+
+It contains concise product bullets, rough demographic/title filters,
+anti-buyer filters, one recommended campaign thesis, a compact InMail-first
+message thesis, and one plain-language `Next Steps` section that walks through:
+
+- `Find Leads`
+- `Tighten Filter`
+- `Draft Message`
+
+Use only `Prospeo`, `Sales Nav`, or `Signals` when describing likely lead-source
+paths. Do not mention Apollo in the brief.
+
+If the campaign goal is really `people likely to reply`, the brief should
+usually carry this source-path hypothesis:
+
+- `Signals` first when the TAM plausibly posts, comments, or engages on LinkedIn
+- `Sales Nav` second when we need tighter role/company filters or the TAM is not active enough on LinkedIn
+- `Prospeo` fallback when LinkedIn-native lanes still cannot produce enough good fits or when domain/account expansion is the clearest next move
+
+Keep that explanation plain-English in the brief. The founder should understand
+why we would start with active LinkedIn behavior before broader cold outreach.
+
+The handoff to Phase 84 should frame `Tighten Filter` as:
+
+- required keep/exclude rules first
+- sample-driven cleanup of false positives
+- optional supporting rules only when clearly useful later
+
+It does not create a campaign, update a campaign brief row, import leads, write
+a rubric, write final message variants, or write workflow-table data.
+
+## Reference Bank
+
+Phase 83 uses the Phase 75 corpus as compact references:
+
+- `references/phase75-canonical-brief-template.md` as the gold-standard template and instructions
+- `references/phase75-active-runtime-message-pack.md` as the narrow runtime inspiration pack
+- `references/phase75-good-brief-and-messaging-examples.md` as the curated gold examples
+- selected client brief archives
+- holdout-aware manifest at `references/examples/MANIFEST.json`
+
+Primary runtime clients:
+
+- `sellable.dev`
+- `Hey Digital`
+- `Galley`
+- `Clover`
+- `Persona`
+- `Superpower`
+
+Secondary / conditional only:
+
+- `Gelee` — proof-stack reference only; do not use as primary runtime because
+  the visible example lacks a strong CTA
+- `Revvix` — event/logistics reference only; do not use as broad runtime because
+  the CTA is too soft
+- `superposition` — exact hiring-template reference only; do not use as broad
+  runtime because it can over-teach sender-first proof stacking
+- `westpark villas`
+
+`Amplify Security` remains an acceptance fixture, not runtime gold.
+
+## Validation
+
+Run:
+
+```bash
+npm run test tests/mcp/sellable-create-campaign-brief-contract.test.ts
+npm run test tests/scripts/run-create-campaign-brief-vps-uat.test.ts
+```
+
+Hosted UAT is run on `sellable-web-mcp`:
+
+```bash
+scripts/run-create-campaign-brief-vps-uat.sh
+```
+
+Single-fixture smoke for a sparse YC-company website run:
+
+```bash
+SELLABLE_CREATE_CAMPAIGN_BRIEF_UAT_FIXTURE_DIR="$PWD/tests/fixtures/create-campaign-brief/smoke" \
+SELLABLE_CREATE_CAMPAIGN_BRIEF_UAT_FIXTURES="surfacelabs" \
+scripts/run-create-campaign-brief-vps-uat.sh
+```
+
+The hosted runner saves Claude Code stream artifacts under
+`.planning/artifacts/uat/83-create-campaign-brief/`.