BuyerTwin

View saved version →

---
name: ask-buyers
description: Use when the user wants to know how one or more target buyers are likely to think, react, question, prioritize, object to, or respond to something, grounded in BuyerTwin intelligence.
---

Use this skill when the user asks for buyer perspective simulation, such as what one or more buyers would think, feel, say, question, object to, prioritize, believe, doubt, or how they would react.

Do not use this as the primary workflow for:
- pure stored-intelligence comparison
- content creation
- sales-preparation workflow generation
- buyer knowledge mutation

Core workflow:
1. Resolve buyers using BuyerTwin tools before simulation.
2. Use ask_buyer as the simulation mechanism.
3. For multiple buyers, call ask_buyer separately for each buyer.
4. Retrieve additional canonical BuyerTwin intelligence only when it directly answers the question or materially improves grounding.
5. Synthesize only after per-buyer responses exist.
6. Surface agreement, disagreement, and outliers without forcing consensus.

Canonical-first routing:
- If the request is directly answerable from canonical BuyerTwin knowledge, answer canonically instead of generating unnecessary simulation.
- Use simulation primarily for reaction, perspective, and "what would they think" questions.

Buyer resolution rules:
- Never invent buyers.
- If the user names one buyer, resolve that buyer.
- If the user names several buyers, resolve all named buyers.
- If the user specifies a segment or other explicit subset, use that subset.
- If the user explicitly asks for "all buyers," use all accessible buyers in the applicable workspace/scope.
- If the user says "my buyers" without further narrowing, default to all accessible buyers in scope.
- Do not silently select a subset based on model-defined relevance.
- Do not silently omit a buyer because a response seems redundant.
- If technical limits prevent using the entire requested set, disclose that limitation.
- If a buyer reference is ambiguous and cannot be resolved, ask a clarifying question instead of guessing.

Evidence discipline:
- Keep BuyerTwin Knowledge (retrieved canonical data), BuyerTwin Simulation (ask_buyer outputs), and AI Synthesis (assistant conclusions) distinct.
- Canonical BuyerTwin Knowledge has factual authority over BuyerTwin Simulation.
- If canonical knowledge and simulation conflict, use canonical knowledge for factual claims, treat simulation as contextual reasoning, and surface material inconsistencies.
- Do not present simulated output as literal statements from real customers/prospects.
- Do not present synthesis as stored BuyerTwin fact.
- Prefer probabilistic language for simulation (for example: likely, may, would probably, appears likely, simulation suggests).
- First-person buyer voice is allowed only when explicitly requested (for example, "answer as the buyer") and must still be identified as simulated.

Guardrails:
- Do not collapse multi-buyer requests to one buyer.
- Do not hide meaningful disagreement.
- Do not convert a majority view into universal consensus.
- Do not use propose_buyer_knowledge_update or apply_buyer_knowledge_update.
- Do not claim website/page Alignment, Pull/Hold, or belief/trust/clarity/risk scoring unless exposed MCP tools actually provide those outputs.

For detailed BuyerTwin methodology, boundary handling, and synthesis rules, consult:
- references/methodology.md

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: compare-buyers
description: Use when the user asks for similarities, differences, patterns, or implications across two or more buyers based on canonical BuyerTwin intelligence.
---

Use this skill when the user asks to compare buyers, such as shared pains, differing triggers, contrasting objections, universal themes, buyer-specific priorities, or where messaging should be universal vs personalized.

Do not use this as the primary workflow for:
- simulated buyer reactions to a new idea or change
- role-play in buyer voice
- content generation
- messaging evaluation workflows
- buyer knowledge mutation

Core workflow:
1. Resolve requested buyer scope deterministically before comparison.
2. Retrieve canonical BuyerTwin intelligence relevant to the user question.
3. Compare evidence across at least two buyers.
4. Distinguish universal, majority, buyer-specific evidence, contrasting, and missing/unknown patterns only when evidence supports each label.
5. Provide implications as AI synthesis while preserving evidence boundaries.

Buyer scope rules:
- Named buyer means resolve that specific buyer.
- Multiple named buyers means resolve all named buyers.
- Explicit segment or subset means compare that exact subset.
- "All buyers" means all accessible buyers in scope.
- "My buyers" without narrowing defaults to all accessible buyers in scope.
- Do not silently narrow scope by model-defined relevance.
- Do not silently omit buyers because they appear redundant.
- If technical limits prevent full requested scope, disclose the limitation.
- If fewer than two buyers are available, explain that reliable comparison is not possible.

Canonical-first comparison rules:
- Use canonical BuyerTwin intelligence as the evidence base.
- Do not use ask_buyer as the normal comparison mechanism.
- If canonical intelligence can answer directly, do not generate simulation-based restatements.
- If evidence is missing, state what is missing instead of fabricating differences.

Evidence hierarchy:
- BuyerTwin Knowledge is authoritative for factual claims.
- AI Synthesis may infer implications from that knowledge.
- Do not present synthesis as a stored BuyerTwin fact.
- Do not treat missing evidence as negative evidence.
- Do not equate frequency with formal priority unless ranking evidence exists.

For detailed methodology and edge-case handling, consult:
- references/comparison-methodology.md

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: create-buyer-content
description: Use when the user asks to create buyer-facing content or a content brief grounded in canonical BuyerTwin intelligence for one or more target buyers.
---

Use this skill when the user asks to create content strategy/briefs or finished content for specific buyers, buyer segments, or all buyers in scope.

Do not use this as the primary workflow for:
- buyer reaction simulation requests
- stored buyer comparison requests
- supplied-message evaluation requests
- sales-call preparation workflows
- buyer knowledge mutation

Core workflow:
1. Resolve buyer scope deterministically.
2. Establish buyer grounding before drafting: situation, objective movement, relevant tensions, likely questions, objections, proof needs, and useful terminology.
3. Retrieve only the canonical BuyerTwin intelligence needed for the requested artifact.
4. Determine whether the user asked for brief mode or finished-content mode.
5. For multi-buyer requests, identify shared versus buyer-specific intelligence before writing.
6. Create strategy and/or content grounded in evidence, preserving meaningful differences.
7. Use ask_buyer selectively only when reaction testing materially improves strategy.

Buyer scope rules:
- One named buyer means that buyer.
- Multiple named buyers means all named buyers.
- Explicit segment/subset means that subset.
- "All buyers" means all accessible buyers in scope.
- "My buyers" without narrowing defaults to all accessible buyers in scope.
- Do not silently choose a relevance-based subset.

Evidence hierarchy:
- BuyerTwin Knowledge is authoritative for buyer facts.
- BuyerTwin Simulation (ask_buyer) is optional and selective.
- AI Synthesis covers strategy, structure, and generated content.
- Generated content is not canonical BuyerTwin knowledge.
- BuyerTwin establishes buyer relevance, buyer context, and buyer perspective; it does not establish factual truth of company, product, competitor, customer, or market claims.

Content guardrails:
- Do not invent company/product/market facts, proof, statistics, quotes, case-study outcomes, or competitor claims.
- If evidence is needed but unavailable, request it or use explicit placeholder guidance.
- Do not start with generic copy and then append persona keywords.
- Adapt depth to artifact type and message purpose.
- If buyers are too different for one artifact, recommend variants rather than forcing an artificial average.
- Do not claim Website Alignment analysis unless exposed MCP tools provide those outputs.

For detailed buyer-content strategy methodology, consult:
- references/buyer-content-methodology.md

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: evaluate-messaging
description: Use when the user asks how well supplied messaging aligns with what BuyerTwin knows about one or more buyers, including what works, what is missing, and what should change.
---

Use this skill when the user asks to evaluate a supplied message against buyer intelligence, such as a headline, value proposition, positioning statement, CTA, paragraph, email, ad copy, campaign concept, sales message, or product description.

Do not use this as the primary workflow for:
- pure buyer-reaction simulation without message evaluation
- stored buyer comparison without evaluating a supplied message
- net-new content generation
- sales call preparation
- buyer knowledge mutation

Core workflow:
1. Resolve buyer scope deterministically.
2. Determine the apparent purpose of the supplied message artifact (for example headline, value proposition, CTA, positioning statement, short ad, email opener, objection-handling paragraph, or sales message).
3. Retrieve canonical BuyerTwin intelligence relevant to the supplied message, purpose, and question.
4. Evaluate message-to-evidence alignment (what works, what is missing, what mismatches, what needs substantiation, and what remains unknown).
5. Preserve buyer-specific differences and tradeoffs for multi-buyer evaluations.
6. Recommend targeted improvements grounded in evidence and clearly labeled AI synthesis.
7. Use ask_buyer selectively only when simulated reaction materially deepens evaluation.

Buyer scope rules:
- One named buyer means evaluate for that buyer.
- Multiple named buyers means evaluate for all named buyers.
- Explicit segment/subset means evaluate that subset.
- "All buyers" means all accessible buyers in scope.
- "My buyers" without narrowing defaults to all accessible buyers in scope.
- Do not silently select a subset by model-defined relevance.

Evidence hierarchy:
- BuyerTwin Knowledge is authoritative for factual claims.
- BuyerTwin Simulation (ask_buyer) is optional and cannot override canonical knowledge.
- AI Synthesis provides diagnosis and recommendations.
- Do not present synthesis as stored BuyerTwin fact.

Evaluation guardrails:
- Do not invent numeric alignment scores or proprietary scoring dimensions unless an exposed MCP tool returns them.
- Do not claim Website Alignment or page-level analysis outputs unless exposed MCP tools provide them.
- Treat missing evidence as unknown, not automatically negative.
- "Missing" means BuyerTwin contains intelligence materially relevant to this message objective and omitting it weakens the message; it does not mean every known buyer priority must appear in every message.
- Evaluate messages relative to what that artifact can reasonably accomplish; do not penalize short artifacts (for example headlines) for not containing every objection, proof point, or criterion.
- If message purpose is uncertain, limit confidence and conclusions rather than inventing a purpose.
- Avoid using ask_buyer to replace available canonical evidence.

If the user explicitly asks to improve or rewrite after evaluation, diagnose first, then provide concise revisions grounded in diagnosed buyer issues.

For detailed messaging-evaluation methodology and edge-case handling, consult:
- references/messaging-evaluation-methodology.md

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: prepare-sales-conversation
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.
---

Use this skill when the user asks for practical preparation before a discovery, demo, qualification, proposal, executive, follow-up, or related sales conversation.

Do not use this as the primary workflow for:
- pure buyer-reaction simulation
- canonical buyer-comparison requests
- supplied-message diagnosis
- net-new content generation requests
- buyer knowledge mutation

Core workflow:
1. Resolve BuyerTwin scope deterministically.
2. Identify user-provided prospect, account, offering, meeting objective, and stage context.
3. Retrieve only BuyerTwin intelligence materially relevant to this conversation.
4. Separate BuyerTwin patterns from prospect-specific facts and unknowns to validate.
5. Prepare likely priorities, triggers/context, desired outcomes, decision criteria, objections/concerns, proof areas, discovery questions, listening cues, framing guidance, and stakeholder differences where relevant.
6. Use ask_buyer selectively for rehearsal/reaction testing when useful.
7. Do not convert BuyerTwin patterns into asserted facts about the specific prospect.

Prospect-vs-BuyerTwin boundary:
- BuyerTwin intelligence describes buyer-type patterns.
- User-provided prospect context describes the actual person/account/opportunity.
- AI synthesis provides preparation recommendations.
- Do not claim BuyerTwin knows specific prospect beliefs unless the user supplied that prospect-specific evidence.

Buyer scope rules:
- One named BuyerTwin means that buyer.
- Multiple named BuyerTwins means all named buyers.
- Explicit segment/subset means that subset.
- "All buyers" means all accessible buyers in scope.
- "My buyers" without narrowing defaults to all accessible buyers in scope.
- Do not silently choose buyers by model-defined relevance.
- If prospect-role mapping to BuyerTwin is ambiguous, surface the ambiguity instead of assuming an exact match.

Authority by domain:
- BuyerTwin Knowledge is authoritative for what BuyerTwin canonically knows about buyer type and buyer context patterns.
- User-provided prospect/opportunity facts are authoritative for the specific person, account, and meeting.
- BuyerTwin Simulation (ask_buyer) is optional reasoning and authoritative for neither domain.
- AI Synthesis provides preparation recommendations.
- BuyerTwin describes the buyer pattern. Prospect evidence describes this prospect.
- If BuyerTwin patterns and prospect facts differ, do not treat this as a global contradiction where one source overrides all others.
- Use prospect-specific facts for this meeting while retaining relevant BuyerTwin context as broader hypothesis/background where appropriate.

Sales-prep guardrails:
- Do not assume CRM, email, call-recording, account-intelligence, or private prospect-history access unless user provides it.
- Do not invent product capabilities, customer outcomes, ROI values, or certifications.
- Do not invent certainty scores such as close probability or deal-risk percentages.
- If stage is unknown, provide useful general preparation without inventing a stage.

For detailed sales-prep methodology and edge-case handling, consult:
- references/sales-conversation-methodology.md

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: update-buyer-knowledge
description: Use when the user explicitly asks to add, correct, or update canonical BuyerTwin knowledge for one or more specific buyers via the proposal/apply mutation workflow.
---

Use this skill when the user explicitly asks to change canonical BuyerTwin knowledge.

Do not use this as the primary workflow for:
- buyer simulation
- buyer comparison
- messaging evaluation
- content creation
- sales-conversation preparation
- hypothetical brainstorming without explicit save/update intent

Activation rule:
- Require explicit mutation intent before calling mutation tools.
- Do not mutate from simulation output, AI synthesis, or casual statements unless the user explicitly asks to save/update BuyerTwin.

Core workflow:
1. Identify explicit mutation intent.
2. Resolve deterministic buyer target scope.
3. Preserve user meaning and qualifiers.
4. Call propose_buyer_knowledge_update.
5. Treat proposal output as the authoritative preview.
6. Verify proposal fidelity against the user's intended buyer, scope, meaning, qualifiers, and requested correction/addition intent.
7. If fidelity fails, do not apply; re-propose the original user instruction without inventing routing hints, or ask for minimum clarification.
8. Present concise proposal review details when needed.
9. Follow tool-returned confirmation policy.
10. Call apply_buyer_knowledge_update only through supported proposal/apply paths.
11. Report only authoritative apply outcome.
12. Handle duplicate, stale, expired, mismatch, unauthorized, and uncertain outcomes per tool semantics.

Classification authority on general intake:
- For `propose_buyer_knowledge_update`, do not send classification overrides such as `explicit_destination` or `explicit_target_key`.
- Submit user knowledge with preserved meaning and let BuyerTwin classify through canonical routing.
- Use the dedicated resolution workflow when a trusted human must explicitly re-target existing knowledge.

Retry lock for proposal_mismatch:
- A retry must not alter `knowledge_text`, `intent_level`, or `verification_intent` unless the user provided new information.
- If a new proposal is required, base it on the original user instruction and do not promote advisory suggestions into explicit targets.
- Do not automatically re-propose after `proposal_mismatch`; report the authoritative failure first and wait for explicit user direction before attempting another proposal.

Mutation safety rules:
- Never bypass proposal step.
- Never claim success after propose only.
- Never apply proposal to a different buyer or different change.
- Do not broaden a buyer-scoped request to all buyers.
- Preserve semantic qualifiers such as usually, often, may, when, and exceptions.
- Proposal fidelity and tool confirmation are separate gates; both must pass before apply.
- Do not reject meaning-preserving normalization or harmless internal routing label differences.
- If apply fails, report the authoritative failure and proposal state only; do not speculate a model-chosen classification as BuyerTwin truth.
- Do not attempt reclassification retries after apply failure to force a preferred category; preserve BuyerTwin authority boundaries.
- If apply succeeds with uncategorized capture (`create_uncategorized` / `inbox_created`), report that it was saved to Needs Review using BuyerTwin-authoritative result state.

Authority boundaries:
- BuyerTwin Simulation and AI Synthesis are not canonical knowledge writes.
- User intent plus supported mutation workflow is required for canonical changes.
- Preserve provenance/trust semantics supported by the mutation contract; do not fabricate stronger provenance than provided.

For detailed mutation methodology, confirmation semantics, conflict handling, and multi-buyer orchestration guidance, consult:
- references/buyer-knowledge-update-methodology.md

Referenced files: 2 — file references are metadata, not package contents.