Update to BuyerTwin

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 430
    },
    {
      "relative_path": "references/buyer-knowledge-update-methodology.md",
      "size_in_bytes": 7782
    }
  ],
  "name": "update-buyer-knowledge",
  "skill_md_contents": "---\nname: update-buyer-knowledge\ndescription: 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.\n---\n\nUse this skill when the user explicitly asks to change canonical BuyerTwin knowledge.\n\nDo not use this as the primary workflow for:\n- buyer simulation\n- buyer comparison\n- messaging evaluation\n- content creation\n- sales-conversation preparation\n- hypothetical brainstorming without explicit save/update intent\n\nActivation rule:\n- Require explicit mutation intent before calling mutation tools.\n- Do not mutate from simulation output, AI synthesis, or casual statements unless the user explicitly asks to save/update BuyerTwin.\n\nCore workflow:\n1. Identify explicit mutation intent.\n2. Resolve deterministic buyer target scope.\n3. Preserve user meaning and qualifiers.\n4. Call propose_buyer_knowledge_update.\n5. Treat proposal output as the authoritative preview.\n6. Verify proposal fidelity against the user's intended buyer, scope, meaning, qualifiers, and requested correction/addition intent.\n7. If fidelity fails, do not apply; re-propose the original user instruction without inventing routing hints, or ask for minimum clarification.\n8. Present concise proposal review details when needed.\n9. Follow tool-returned confirmation policy.\n10. Call apply_buyer_knowledge_update only through supported proposal/apply paths.\n11. Report only authoritative apply outcome.\n12. Handle duplicate, stale, expired, mismatch, unauthorized, and uncertain outcomes per tool semantics.\n\nClassification authority on general intake:\n- For `propose_buyer_knowledge_update`, do not send classification overrides such as `explicit_destination` or `explicit_target_key`.\n- Submit user knowledge with preserved meaning and let BuyerTwin classify through canonical routing.\n- Use the dedicated resolution workflow when a trusted human must explicitly re-target existing knowledge.\n\nRetry lock for proposal_mismatch:\n- A retry must not alter `knowledge_text`, `intent_level`, or `verification_intent` unless the user provided new information.\n- If a new proposal is required, base it on the original user instruction and do not promote advisory suggestions into explicit targets.\n- Do not automatically re-propose after `proposal_mismatch`; report the authoritative failure first and wait for explicit user direction before attempting another proposal.\n\nMutation safety rules:\n- Never bypass proposal step.\n- Never claim success after propose only.\n- Never apply proposal to a different buyer or different change.\n- Do not broaden a buyer-scoped request to all buyers.\n- Preserve semantic qualifiers such as usually, often, may, when, and exceptions.\n- Proposal fidelity and tool confirmation are separate gates; both must pass before apply.\n- Do not reject meaning-preserving normalization or harmless internal routing label differences.\n- If apply fails, report the authoritative failure and proposal state only; do not speculate a model-chosen classification as BuyerTwin truth.\n- Do not attempt reclassification retries after apply failure to force a preferred category; preserve BuyerTwin authority boundaries.\n- If apply succeeds with uncategorized capture (`create_uncategorized` / `inbox_created`), report that it was saved to Needs Review using BuyerTwin-authoritative result state.\n\nAuthority boundaries:\n- BuyerTwin Simulation and AI Synthesis are not canonical knowledge writes.\n- User intent plus supported mutation workflow is required for canonical changes.\n- Preserve provenance/trust semantics supported by the mutation contract; do not fabricate stronger provenance than provided.\n\nFor detailed mutation methodology, confirmation semantics, conflict handling, and multi-buyer orchestration guidance, consult:\n- references/buyer-knowledge-update-methodology.md\n"
}