Update to BuyerTwin

{
  "description": "Use when the user asks to prepare for a sales conversation with one or more buyers using canonical BuyerTwin intelligence plus any user-provided prospect context.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 468
    },
    {
      "relative_path": "references/sales-conversation-methodology.md",
      "size_in_bytes": 7074
    }
  ],
  "name": "prepare-sales-conversation",
  "skill_md_contents": "---\nname: prepare-sales-conversation\ndescription: Use when the user asks to prepare for a sales conversation with one or more buyers using canonical BuyerTwin intelligence plus any user-provided prospect context.\n---\n\nUse this skill when the user asks for practical preparation before a discovery, demo, qualification, proposal, executive, follow-up, or related sales conversation.\n\nDo not use this as the primary workflow for:\n- pure buyer-reaction simulation\n- canonical buyer-comparison requests\n- supplied-message diagnosis\n- net-new content generation requests\n- buyer knowledge mutation\n\nCore workflow:\n1. Resolve BuyerTwin scope deterministically.\n2. Identify user-provided prospect, account, offering, meeting objective, and stage context.\n3. Retrieve only BuyerTwin intelligence materially relevant to this conversation.\n4. Separate BuyerTwin patterns from prospect-specific facts and unknowns to validate.\n5. Prepare likely priorities, triggers/context, desired outcomes, decision criteria, objections/concerns, proof areas, discovery questions, listening cues, framing guidance, and stakeholder differences where relevant.\n6. Use ask_buyer selectively for rehearsal/reaction testing when useful.\n7. Do not convert BuyerTwin patterns into asserted facts about the specific prospect.\n\nProspect-vs-BuyerTwin boundary:\n- BuyerTwin intelligence describes buyer-type patterns.\n- User-provided prospect context describes the actual person/account/opportunity.\n- AI synthesis provides preparation recommendations.\n- Do not claim BuyerTwin knows specific prospect beliefs unless the user supplied that prospect-specific evidence.\n\nBuyer scope rules:\n- One named BuyerTwin means that buyer.\n- Multiple named BuyerTwins means all named buyers.\n- Explicit segment/subset means that subset.\n- \"All buyers\" means all accessible buyers in scope.\n- \"My buyers\" without narrowing defaults to all accessible buyers in scope.\n- Do not silently choose buyers by model-defined relevance.\n- If prospect-role mapping to BuyerTwin is ambiguous, surface the ambiguity instead of assuming an exact match.\n\nAuthority by domain:\n- BuyerTwin Knowledge is authoritative for what BuyerTwin canonically knows about buyer type and buyer context patterns.\n- User-provided prospect/opportunity facts are authoritative for the specific person, account, and meeting.\n- BuyerTwin Simulation (ask_buyer) is optional reasoning and authoritative for neither domain.\n- AI Synthesis provides preparation recommendations.\n- BuyerTwin describes the buyer pattern. Prospect evidence describes this prospect.\n- If BuyerTwin patterns and prospect facts differ, do not treat this as a global contradiction where one source overrides all others.\n- Use prospect-specific facts for this meeting while retaining relevant BuyerTwin context as broader hypothesis/background where appropriate.\n\nSales-prep guardrails:\n- Do not assume CRM, email, call-recording, account-intelligence, or private prospect-history access unless user provides it.\n- Do not invent product capabilities, customer outcomes, ROI values, or certifications.\n- Do not invent certainty scores such as close probability or deal-risk percentages.\n- If stage is unknown, provide useful general preparation without inventing a stage.\n\nFor detailed sales-prep methodology and edge-case handling, consult:\n- references/sales-conversation-methodology.md\n"
}