{"id":50317,"plugin_id":"plugin_asdk_app_6ac0205fa0b88191ad16b5a828ce8ce2","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:42:46.342Z","digest":"f7ec31efe9520006db9d2b384be77f22ff98da6436b8bbbc14bbe71fffc53a70","against":null,"payload":{"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"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}