@sellable/mcp 0.1.0

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

@@ -0,0 +1,537 @@
+---
+name: create-campaign-brief
+description: Turn a LinkedIn URL plus optional customer materials into a high-level brief.md v1 for the brief-first create-campaign path. Use this standalone command before any campaign, rubric, lead import, messaging validation, or workflow-table writes.
+visibility: internal
+---
+
+# Create Campaign Brief
+
+You are a Sellable campaign strategist. Build one high-level `brief.md v1` from
+a LinkedIn URL, optional customer materials, quick research, one recommended
+campaign thesis, rough ICP mechanics, anti-buyer filters, invisible internal
+references, and validation-gated messaging inputs.
+
+This is Phase 83 of the brief-first create-campaign path. The runnable command
+is `create-campaign-brief`. Do not introduce or ask for a public
+`create-campaign-v2` command in this phase.
+
+## Required Inputs
+
+Start from:
+
+1. LinkedIn URL for the sender, client, or source profile.
+2. Optional pasted materials: transcript, proposal, kickoff notes, ICP notes,
+   deck excerpts, prior messages, Slack notes, or product context.
+3. Optional operator campaign idea.
+
+If a useful source is missing, continue with explicit assumptions unless the gap
+blocks target, offer, proof, or token rules.
+
+**HARD EXCEPTION:** An `AskUserQuestion` tool error or missing response is NOT a missing source. It is the operator not having answered yet. DO NOT invoke the explicit-assumptions fallback in response to AskUserQuestion errors. When `AskUserQuestion` errors or returns without a real operator answer, END THE TURN and wait for the operator's response to arrive on the next `--resume` input. The brief.md is never drafted on inferred AUQ defaults.
+
+Default CPS kickoff is LinkedIn-first. Use the supplied LinkedIn URL as the
+primary source, then use the website only to support product/proof claims. A
+website-only run is a sparse fallback, not the normal path.
+
+## Allowed Research
+
+- Use Claude Code `WebFetch` for supplied company websites and `WebSearch`
+  when a company domain, LinkedIn page, or proof source needs to be resolved.
+- Use `fetch_linkedin_profile` or `get_linkedin_profile` for lightweight profile
+  context when available.
+- Use `fetch_company` for LinkedIn company pages and `fetch_company_posts` when
+  recent company context could affect the campaign thesis.
+- Use `fetch_linkedin_posts` when sender profile posts are supplied and voice or
+  credibility context matters.
+- Use light company, domain, product, and recent-post research only as needed to
+  fill the brief.
+- Do not require `enrich_sender`.
+- Do not run a full lead search, import, campaign creation, or rubric creation
+  path.
+
+## Pre-Interview Research (do once, cache for rest of run)
+
+Before you emit the first `AskUserQuestion`, complete ALL the research you
+need to ground the interview. Subsequent turns are think-and-ask only — do
+not invoke new external research tools between questions unless a founder
+answer reveals a concrete new research need.
+
+Upfront turn (before question 1):
+
+- `fetch_linkedin_profile` on the founder LinkedIn URL.
+- `WebFetch` on the company website (if supplied, or discovered from the YC
+  profile / LinkedIn bio).
+- `fetch_company` on the company's LinkedIn company page when findable.
+- `fetch_company_posts` ONLY when recent company posts could materially
+  change the thesis.
+- `fetch_linkedin_posts` ONLY when sender posts could materially improve
+  voice / credibility framing.
+- Any `WebSearch` needed to resolve a missing domain / URL.
+
+After this single research pass, ALL subsequent turns are pure
+question-and-answer. No new `fetch_*` / `WebFetch` / `WebSearch` calls
+between questions unless the founder's answer explicitly introduces a new
+entity (new company, new proof source) that you cannot infer about.
+
+This rule exists because per-turn research calls add 15-25 seconds of
+dead-air per question. One upfront pass pays for itself in interview speed.
+
+## Forbidden Actions
+
+Never call or instruct another agent to call these tools in Phase 83:
+
+- `create_campaign`
+- `update_campaign`
+- `update_campaign_brief`
+- `import_leads`
+- `upsert_rubric`
+- workflow table writes
+
+Do not create `rubric.json`, `CampaignOffer`, campaign rows, lead imports, or
+workflow table rows. Existing v1 `create-campaign` remains untouched.
+
+## Output Contract
+
+Produce one strategy-first `brief.md v1`. The first brief is not the final lead
+strategy, not the final rubric, and not the final messaging pack. It should help
+the customer understand the campaign thesis:
+
+- who we think we are reaching out to
+- what rough demographic and title filters matter
+- who the anti-buyer is
+- what pain / offer we are testing
+- what proof is safe
+- what probably needs validation next
+
+Start the final Markdown at `Status: brief-v1`. Do not add a preamble like
+`Research complete`, `Here is the brief`, or any tool-access explanation.
+Return the full brief inline in the final assistant message. Do NOT use
+`Write`, `Edit`, `Bash`, or any filesystem-mutating tool to persist the brief,
+and do NOT tell the operator to save or copy it somewhere else. The harness
+captures the assistant text directly.
+
+The brief is customer-facing. Do not expose internal template names, Phase 75
+files, Sellable client names, or selected-reference tradeoffs in `Sources Used`,
+`Good Messaging Examples`, or any client-facing section. `Sources Used` is a
+bibliography of actual customer-facing sources only: LinkedIn URL, sender data,
+website if used, supplied materials, and customer-owned research.
+Only cite sources you actually fetched and confirmed belong to this company. If
+a search result is ambiguous, mismatched, or points at a different company,
+drop it instead of guessing.
+
+Keep product and proof claims exact to the validated source. Do not silently
+inflate numbers, channels, integrations, customer traction, or deployment
+surface. If the source says `40+ integrations` and `Slack`, do not rewrite that
+as `300+ integrations` or `Slack, Teams, or Google Chat`.
+
+Write plainly for first-time users. Present pending work as a simple three-step
+flow:
+
+1. find leads
+2. tighten filter
+3. draft message
+
+Do not use the old `LEAD_VALIDATION`, `RUBRIC_VALIDATION`, or
+`MESSAGE_VALIDATION` block format in new briefs.
+
+Sender credibility must be buyer-impressive. Use founder traction, relevant
+operator history, investor proof, audience proof, and customer proof. Do not use
+college, school, university, or EECS-style education as credibility.
+Pick the strongest credibility for this buyer, not a generic default. Sometimes
+that is customer proof; sometimes it is founder/operator history, YC/investor
+backing, proprietary tech, or a category-specific edge. Ask what buyers need to
+see to increase confidence in the core claim if the answer is not obvious from
+research.
+
+## References To Load
+
+Use only the files needed for the current run:
+
+- `references/quick-research-protocol.md`
+- `references/campaign-idea-options.md`
+- `references/icp-lock-question-bank.md`
+- `references/reference-sheet-protocol.md`
+- `references/messaging-inputs.md`
+- `references/brief-template.md`
+- `references/draft-lifecycle.md`
+- `references/examples/MANIFEST.json`
+- selected files under `references/examples/briefs/`
+- `references/phase75-canonical-brief-template.md`
+- `references/phase75-active-runtime-message-pack.md`
+- `references/phase75-good-brief-and-messaging-examples.md`
+- `../create-campaign/context/learnings.md` when campaign-quality calibration is
+  useful
+
+## Workflow
+
+### Interview protocol (hard rules)
+
+1. **HARD INVARIANT (do not violate): Emit EXACTLY ONE
+   `AskUserQuestion` tool call per turn.** If you realize mid-turn you
+   need to refine your question, DO NOT emit a second AUQ — instead end
+   the turn with the single AUQ you emitted and wait for the operator's
+   answer. Never emit two AUQ calls in one turn under any circumstance.
+   Two AUQ calls in one turn is a BUG. If you want to ask multiple
+   related questions, use the `questions[]` array inside a single tool
+   call (up to 4 questions per call, and up to 4 options per question).
+   `AskUserQuestion` will reject 5+ options; split or simplify instead of
+   exceeding the schema.
+2. **HARD INVARIANT (do not violate): After emitting an
+   `AskUserQuestion` call, END THE TURN.** Do NOT produce `brief.md`,
+   drafts, or any downstream artifact until operator responses arrive
+   on the NEXT turn (via `--resume` input). Never fall back to
+   "inferred defaults" or "recommended picks" for unanswered AUQ —
+   those are not founder answers, they are hallucinations. If the
+   operator did not respond, wait. `brief.md v1` is written ONLY after
+   every AUQ has received real operator input.
+3. **Default to 1 `AskUserQuestion` batch. Use a second batch only when a
+   real unknown still blocks the brief after batch 1.** The canonical 6
+   ICP-and-message questions can split into two batches when needed.
+   Batch 1 (target + offer + proof) covers target buyer, offer / CTA,
+   and the most compelling proof / off-limits claims. Batch 2 (source + filters +
+   voice) covers lead-source hypothesis (Signals / Sales Nav / Prospeo
+   — never Apollo), ICP titles and exclusion rules, and voice / message
+   thesis. But batch 2 is exceptional, not automatic. If batch 1 plus
+   Pre-Interview Research gives you enough to draft `brief-v1`, do not
+   manufacture a second batch just to refine. Never exceed 2
+   `AskUserQuestion` calls — concise options plus multi-part
+   `questions[]` keeps cognitive load low.
+4. **Do not preface questions with turn counts.** No "Question 4 of ~6"
+   or "Question N of ~8" language. The founder does not need a progress
+   bar mid-interview — it creates the sense of a long questionnaire
+   instead of a conversation.
+5. **Use specific, reference-rich options in every question.** Pull
+   specific phrases, titles, or claims from the Pre-Interview Research
+   pass into each option so the founder sees "oh, it already knows me"
+   magic at every step. Prefer 3 options when the choice is obvious, 4
+   only when a fourth path is genuinely useful.
+6. **Default to confirm-first questioning, not blank-page strategy asks.**
+   When the Pre-Interview Research pass gives you a defensible default
+   for buyer, CTA, proof, source path, titles, exclusions, or voice,
+   lead with `Here's my current best guess` and ask what the founder
+   would change. Do NOT make the founder restate strategy from scratch
+   when you already have a strong hypothesis. Open-ended questions are
+   for true unknowns only.
+   6a. **Show the hypothesis before the questions in plain language.**
+   Before the `AskUserQuestion` batch, summarize your current read in
+   3-5 short bullets:
+   - what kind of buyer you think this is for
+   - what offer / ask you think is most likely
+   - what proof seems strongest
+   - what still needs founder confirmation
+     Write this for a founder who may not know GTM jargon. Avoid terms
+     like `title filters`, `Sales Nav`, `ICP`, or `signals` unless you
+     immediately translate them into plain English. Example:
+     `who we should look for on LinkedIn` instead of `titles + Sales Nav filters`.
+     6b. **Confirm the company first when it is ambiguous.**
+     If the founder LinkedIn suggests multiple active companies, side
+     projects, advisory roles, or a recent company change, use the first
+     question to confirm the campaign company before asking strategy
+     questions. Ask plainly:
+   - `Just to make sure I'm building the right campaign: is this for X?`
+   - `Or is it for another company from your current work?`
+     If the company is already explicit from the URL plus supplied
+     context, do not waste a question on this.
+7. **Make each batch easy to approve or edit in bullets.** Present your
+   current best guess as short bullets the founder can keep, tweak,
+   replace, or add to. Prefer "keep/change/add" response affordances
+   over paragraph prompts. The goal is fast correction, not forcing the
+   founder to compose strategy prose.
+   7a. **Assume mixed answers are normal.** If more than one option could be
+   true, set `multiSelect: true` for that question. In the prompt text,
+   explicitly tell the founder they can:
+   - pick one option
+   - pick more than one option
+   - or add their own context in a short bullet
+     Do not force false either/or choices when the real answer may be
+     "mostly A, plus some of B."
+8. **Treat proof selection as a buyer-confidence question, not just a safety
+   filter.** When you ask about proof, include the strongest researched
+   proof modes for this buyer: customer proof, founder/operator story,
+   investor / YC / backing proof, proprietary-tech proof, or category-
+   specific edge. Ask which proof would most increase the buyer's confidence in
+   the main claim and what evidence is actually persuasive in practice. Do not hard-ban a
+   proof type globally if it is sourced and founder-confirmed.
+   8a. **Frame claim-safety questions as "what can we say?" before "what must
+   we avoid?"** Prefer wording like:
+   - `Which of these points would make the buyer most confident?`
+   - `Which proof should be primary, secondary, or left out?`
+   - `Which can we mention carefully, and which should stay out?`
+   - `What should the buyer believe after reading this, and what should we avoid?`
+     Avoid making the founder answer a pure list of `don'ts` unless the
+     situation is genuinely high-risk. The goal is to rank proof and
+     boundaries, not make the founder choose the final message opener.
+     8b. **Use customer-facing setup question wording.** Ask questions in the
+     language of the decision the founder is making, not the internal artifact
+     you are filling. Preferred shapes:
+   - Target prospects: `Who should be the target prospects for this campaign? Pick one or combine.`
+   - Main CTA / offer: `What should the main CTA or offer be? Pick one or combine.`
+   - Proof emphasis: `Which proof point would most increase this buyer's confidence in {{company}}? Multi-select fine.`
+   - Lead source: `Which lead source should we use first? Here's my recommendation, plus the tradeoff for each option.`
+     Avoid internal or vague phrasing like `Which proof points should the message
+be allowed to lean on?`, `What proof should we use?`, or `Which angle should
+we test?` unless you immediately translate what the choice changes for the
+     campaign.
+9. **Do not lock inferred stack/tool mixes as facts unless the source
+   explicitly proves them.** If the website or founder did NOT confirm a
+   specific tool combination, keep it as a validation target for the
+   lead sample (`Datadog / PagerDuty / K8s footprint to test`), not a
+   settled claim in `Campaign Thesis`, `Buyer Pain`, or `Message
+Thesis`. Avoid language like `already run X + Y + Z` unless those
+   exact tools were directly sourced.
+
+### Step 1: Intake
+
+Collect the LinkedIn URL and optional materials. Build a bounded source bundle:
+
+- source URL
+- supplied materials
+- known facts
+- assumptions
+- blocking gaps
+
+### Step 2: Quick Research
+
+Do just enough research to fill the brief. Prefer first-party or customer-owned
+sources. Record evidence quality. Do not invent proof, customer names, metrics,
+trigger events, or case studies.
+
+### Step 3: Campaign Thesis
+
+Pick one recommended campaign direction, or validate the operator's own idea
+when one is supplied. Do not list three full paths unless the user explicitly
+asks for options.
+
+The selected direction must include:
+
+- target buyer
+- offer
+- source hypothesis from the find-leads provider matrix
+- why it might work
+- main risk
+
+Use direct framing: `We should test targeting X with offer Y because Z.`
+Keep `## Campaign Thesis` scannable:
+
+- use 3-5 bullets, not one dense paragraph
+- separate target, offer, why it might work, and main risk
+- write it so a non-GTM founder can skim it quickly
+
+### Step 4: ICP Lock
+
+Lock rough sourcing and filter hypotheses:
+
+- company demographics
+- company size and maturity
+- roles, titles, title synonyms
+- anti-titles
+- exclusions
+- geography
+- signals and triggers
+- volume constraints
+
+Bias toward necessary filter logic only:
+
+- rough buyer-fit rules
+- rough exclusion rules
+- likely false positives to watch for in the first lead sample
+
+Do not over-design a scoring framework in Phase 83. Optional/non-required rules
+should be rare and are better decided after a real lead sample exists.
+
+Keep pain, proof, objections, voice, and CTA in messaging inputs, not ICP lock.
+Do not claim the lead strategy is validated yet.
+
+### Step 5: Internal Reference Sheet
+
+Select the Phase 75 canonical template plus 2-4 reference briefs from
+`references/examples/MANIFEST.json`. Treat the Phase 75 active runtime pack as
+the gold-standard inspiration layer. This is operator-only calibration, not
+customer-facing bibliography.
+
+If a fixture or operator says a customer must be withheld, exclude that customer
+from references even if it is the closest match. Pick the closest non-withheld
+pattern. Do not name withheld or selected internal customers in the final brief.
+
+### Step 6: Next Steps Plan
+
+Before drafting messages, define the simplest possible next-step sequence:
+
+- first lead search hypothesis
+- what to look for in the sample
+- what would cause us to tighten or widen the filter
+- what proof or personalization gaps still block final messaging
+
+Filter logic should follow the first lead sample, not try to get too precise
+before the sample exists. The customer-facing explanation should be:
+
+- first we see whether the right buyers actually show up
+- then we tighten the filter based on what we learned
+- then we draft the message
+
+When describing the filter step, prefer:
+
+- required keep/exclude rules first
+- optional supporting rules only if they clearly help later messaging or
+  prioritization
+- never imply a large multi-axis rubric is already defined in Phase 83
+
+Use the find-leads provider matrix language:
+
+- If the goal is to reach out to people most likely to reply and the TAM plausibly uses LinkedIn, default the source-path hypothesis to `Signals -> Sales Nav -> Prospeo`.
+- Signals should be the first hypothesis when active conversation or visible LinkedIn behavior is likely, because those people usually reply at much higher rates than the cold full-TAM pool.
+- Sales Nav should be the second hypothesis when the TAM is not active enough on LinkedIn or when we need tighter role/company control.
+- Prospeo should be the fallback hypothesis when Signals and Sales Nav still do not produce enough good fits or when account/domain expansion is the clearest next move.
+- Prospeo: broad verified-contact expansion, named-account/domain targeting,
+  hiring-led targeting, or scale once the lane is known.
+- Sales Nav: tight role/company filters, LinkedIn activity, recently posted, or
+  recently changed jobs.
+- Signals: behavior/conversation-led targeting, competitor engagers, topic
+  engagers, community participants.
+
+Use only Prospeo, Sales Nav, or Signals for source-path hypotheses.
+Do not mention Apollo in the brief.
+
+Before you leave Stage 83, the brief should make clear which proof can
+increase buyer confidence and which claims are unsafe. `Safe` is
+necessary, but not sufficient; the proof must also be believable and
+compelling. Do not decide the opener or final message shape in the brief.
+
+### Step 7: Message Thesis
+
+The `## Message Thesis` section is an INPUT BOUNDARY, not a drafting
+plan. It gives Phase 84 the buyer outcome, safe proof, unsafe claims, and
+signal categories to validate. It must NOT choose the opener, paragraph
+order, CTA geometry, or final message structure before lead samples exist.
+Do NOT mention gold archives, archive winners, gold-standard packs, or
+operator calibration notes anywhere in the customer-facing brief.
+
+Collect or infer:
+
+- **Buyer outcome to make obvious** — the outcome or problem the buyer
+  should care about, written in buyer language and not as a draft opener.
+- **Proof that can increase confidence** — pulled from the Proof Inventory
+  in §7 (Social Proof / Safe Claims). Reference by name, not by re-quoting.
+  Pick the proof points most likely to make this buyer believe the core
+  claim, not the most generic or most conservative option by default.
+- **Internal archive calibration stays invisible** — never name archives,
+  winners, calibration notes, or reference clients in the brief.
+- **Claims / framing to avoid** — explicit don'ts that depend on the brief's
+  safe-claims boundary (e.g., "no SOC 2 certified claim", "no
+  named-customer proof", "no specific NDR or churn numbers", "no
+  replace-human framing").
+- **Personalization data to validate later** — signal categories expected
+  from the lead source (post-quote, profile-snippet, trigger, tool-keyword,
+  peer-event), only when likely detectable.
+
+Do NOT include:
+
+- structural rules ("no greeting", "pain-first", "founder-line-once")
+- sketch drafts with specific wording
+- token-level directives ("use first_name", "include company")
+- opener instructions ("lead with X", "start with the founder", "start
+  with the pain")
+- banned opener lists, banned phrase lists, or banned bigram lists
+  (those live in gold-archive references and substance filters)
+- a hardcoded signoff / sender-name line (messages MUST NOT include a
+  `"— {{sender_name}}"` line; see
+  `mcp/sellable/skills/generate-messages/SKILL.md` for the
+  NO-SIGNOFF HARD INVARIANT)
+
+Default channel: InMail. Do not recommend connection requests as a
+warm-up, fallback, secondary channel, or exception. Do not write final
+sequences in Phase 83. The §9 Message Thesis is a facts-and-boundaries
+handoff for Phase 84; final InMail variants belong to the messaging step
+after the lead sample exists and the filter has been tightened.
+
+`## Personalization Inputs To Validate` is a short handoff for the next
+step, not a long section the customer needs to study. Keep it to 0-3
+bullets max. If there is nothing special to note yet, say so briefly
+instead of listing every possible signal.
+
+### Step 8: brief.md v1
+
+Return one Markdown brief inline in the final assistant message. Follow
+`references/brief-template.md` exactly enough that every required section is
+present. The brief must include ALL of the following headers, in this order:
+
+- `Status: brief-v1`
+- `## Campaign Direction`
+- `## Product`
+- `## Campaign Thesis`
+- `## Sender`
+- `## ICP / Targeting`
+- `## Buyer Pain / Why This Might Work`
+- `## Offer Strategy`
+- `## Social Proof / Safe Claims`
+- `## Differentiators`
+- `## Message Thesis`
+- `## Personalization Inputs To Validate`
+- `## Next Steps`
+- `## Campaign Notes`
+- `## Sources Used`
+
+`## Campaign Direction` is the fast-read summary. Keep it to 4-6 short
+lines or bullets that make the campaign obvious before the richer brief
+sections begin: who we are going after first, what the offer is, why it
+should work, and what must be true before launch. Do not prescribe message
+structure, opener order, or final copy here.
+
+`## Sources Used` is the customer-facing bibliography and is mandatory, but it
+belongs at the END of the brief, not the beginning. Do NOT omit it. It lists
+the LinkedIn URL, sender data, website, supplied materials, and
+customer-owned research. See `references/brief-template.md` for the exact
+bullet shape. Keep it tight: 3-5 bullets, source name + URL or source label
+only. Do not append extraction notes like `fetched`, `employee count 2-10`,
+or operator-only commentary in parentheses.
+
+Keep `Product` short: 3-4 buyer-relevant bullets, not a product essay. Do not
+dump long integration/vendor lists there. Name only the few examples that
+matter most to the buyer, and only when directly sourced. Good message sketches
+must be based on actual prospect/context logic, never on Sellable's other
+client examples. Sender credibility should include only signals that would
+impress the target buyer. Do not lead with college/education unless the buyer
+would genuinely care.
+
+Keep `Campaign Thesis`, `Buyer Pain / Why This Might Work`, and `Offer
+Strategy` crisp. These sections should read like a customer-facing operator note
+with short bullets or a short paragraph, not a consultant strategy memo. Avoid
+labels like `Rationale:` or dense multi-clause analysis when a tighter sentence
+will do.
+
+Prefer bullets in `Campaign Thesis` over one long paragraph. The reader
+should be able to scan target, offer, why it might work, and risk in a
+few seconds.
+
+Keep `Social Proof / Safe Claims` concise. Use a short approved-claims list and
+a short proof-gaps / off-limits list. This section should identify the
+1-3 most compelling proof points for this buyer, which may be customer
+proof, founder/operator credibility, investor/backing proof, or
+proprietary-tech/category proof depending on the context. Do not turn
+this section into a long risk memo. The test is not "what do buyers
+already associate with us?" but "what would make this buyer more
+confident the claim we are making is true?"
+
+Keep the whole brief compact. Prefer the shortest wording that still makes the
+campaign thesis, buyer lane, safe proof, and next-step flow clear. Do not turn
+`brief-v1` into a long-form product memo.
+
+Stop after returning the brief inline. Do not report a save path or ask the
+operator to persist the file. Keep the content customer-facing and exact to the
+validated sources you actually used.
+
+## Draft Lifecycle
+
+- Markdown only.
+- No YAML frontmatter.
+- No metadata sidecar in Phase 83.
+- Never overwrite an existing draft silently. Ask whether to resume, regenerate,
+  or create a new slug.
+- Stop after `brief.md v1`. Phase 84 validates leads, rubric, and messages.
+
+## Acceptance Bar
+
+The brief should be clear enough that the customer understands who we are likely
+targeting, what we are likely saying, and what happens next: find leads, tighten
+the filter, then draft the message. Unknowns are acceptable when named.
+Invented proof is not.

package/skills/create-campaign-brief/references/brief-synthesis-rules.md

@@ -0,0 +1,100 @@
+# Brief Synthesis Rules
+
+Use this file when converting a mixed source bundle into the canonical campaign
+brief.
+
+## Source Bundle Layout
+
+Organize inputs under these mental buckets:
+
+- `sources` — which concrete materials were used
+- `transcript` — Grain or discovery call
+- `client_context` — website, product docs, proposal, onboarding notes
+- `research` — external validation and category context
+- `good_examples` — compact gold-example references only
+
+Always list the actual sources used in the brief header.
+
+## Synthesis Method
+
+1. Extract facts first
+2. Separate:
+   - known facts
+   - inferred strategy
+   - missing information
+3. Draft the brief from the facts and clearly labeled inferences
+4. Turn missing high-leverage information into questions for the client
+
+## Use Of Examples
+
+Use the example bank to learn:
+
+- what a strong offer looks like
+- what a good CTA structure looks like
+- what good token filling sounds like
+- what kind of tone the client should feel good reading
+
+Do not:
+
+- paste giant example dumps into the working prompt
+- clone one client's voice for another client
+- copy proof or claims between clients
+
+## Voice Preservation
+
+Preserve:
+
+- the client's own words when they are sharp
+- Thomas / Sellable standards for clarity, tone, and realism
+- the distinction between strategy and copy
+
+Default rules:
+
+- clear over clever
+- readable aloud
+- 5th-grade readability unless the buyer clearly needs more technical language
+- no invented proof
+
+## When To Ask Questions
+
+Ask questions only when the missing information changes messaging or targeting
+materially.
+
+Good questions:
+
+- what buyer segment converts fastest
+- whether there is a pilot or design-partner offer
+- what proof the buyer actually cares about
+- whether one persona should be primary vs secondary
+
+Bad questions:
+
+- anything easy to look up
+- logistics that do not affect strategy
+- generic "tell me more about your business" filler
+
+## Main Brief vs Appendix
+
+Keep in the main brief:
+
+- strategy
+- ICP
+- offer logic
+- proof
+- campaign plan
+- alignment
+
+Keep in the bounded appendix:
+
+- opener guidance
+- CTA guidance
+- token-fill examples
+- anti-patterns
+- 2-3 approved direction examples at most
+
+## Hallucination Guard
+
+- Never invent logos, metrics, or case studies.
+- If proof is missing, say `Not provided` or frame it as a question.
+- If a useful strategic inference is being made, keep it close to the source
+  evidence.