Update to Breakthrough

{
  "description": "Answers any sales question for this user's company: how we sell, what we charge, how we position, what to ask a buyer, how to handle an objection, how we compare to a competitor, what to do next on a deal — plus open-ended questions about a prospect, account, or call. Answers come from the company's own playbook and sales data (contacts, companies, call transcripts), which only this skill can reach. The fallback for any Breakthrough request that isn't a record lookup, including writing an email, a message, or call notes.",
  "included_files": [],
  "name": "answer",
  "skill_md_contents": "---\nname: answer\ndescription: >-\n  Answers any sales question for this user's company: how we sell, what we charge, how\n  we position, what to ask a buyer, how to handle an objection, how we compare to a\n  competitor, what to do next on a deal — plus open-ended questions about a prospect,\n  account, or call. Answers come from the company's own playbook and sales data\n  (contacts, companies, call transcripts), which only this skill can reach. The\n  fallback for any Breakthrough request that isn't a record lookup, including writing\n  an email, a message, or call notes.\nwhen_to_use: >-\n  Use for ANY question about selling that the user's company would answer differently\n  from a generic one — even when no person, company, or call is named: \"what's our\n  pricing\", \"give me 3 discovery questions for a CFO\", \"how do I handle the pricing\n  objection\", \"how do we position against X\", \"what's our elevator pitch\", \"what should\n  I do next here\", \"help me prep for this call\", \"should we chase this\". The company\n  keeps a playbook for exactly these; answering them from general sales knowledge is\n  the failure this skill exists to prevent. Do NOT use to pull up one person or company\n  record; that is find-contact or find-business. Do NOT use for \"what did they say on\n  the call\"; that is research-transcripts. Also use when the user wants something\n  written from their calls or records — \"write a follow-up email to Jane after our\n  call\", \"draft a LinkedIn message to him\", \"write up yesterday's call as a MEDDPICC\":\n  load the context here, then write it the way you normally would.\n---\n\n# Answer a question\n\nThe default for questions, general chat, brainstorming, and explanations.\n\n## Steps\n\n**1. Entities — only when named.** When the question touches a person, company, or\ncall the user knows, follow `${CLAUDE_PLUGIN_ROOT}/skills/gather-context/SKILL.md` in\nfull. Its last step calls `sales_playbook` with the ids it just resolved — that is the\nplaybook step for this path, so do not call `sales_playbook` again afterwards. Order\nmatters: on an org with more than one playbook, the resolved call's sales/partnership\ntag is the strongest signal for which playbook applies, and it is only available\nafter resolution. Skip this step entirely for questions that reference none of the\nuser's data.\n\n**2. Playbook — when nothing was named.** If step 1 did not run, call\n`sales_playbook` directly with the user's message verbatim as `latest_user_message`\nand the conversation so far as `conversation_history`. Do this for every such\nquestion: the native chat runs this retrieval on every turn, and the tool decides for\nitself when nothing applies (it returns `skipped`, which costs nothing). \"What's our\npricing?\" and \"give me 3 discovery questions for a CFO\" are playbook questions even\nthough they mention no one.\n\nEither way, exactly one `sales_playbook` call per question.\n\nFor questions about the user themselves — their background, experience, or how to\nposition who they are — call `whoami(detail=\"full\")` rather than the default\n`whoami()`. The default returns bare scope; `detail=\"full\"` adds their LinkedIn\nheadline, summary, experience, and education. It reads cached data only, so it is\ncheap and never prompts.\n\n**2. Answer to the contract** in\n`${CLAUDE_PLUGIN_ROOT}/references/output-contracts.md`:\n\n- No hard length cap, but the conciseness rules bind. Conversational questions get\n  conversational answers — typically 1–5 sentences.\n- Answer, then stop. No recap of the question, no \"additional considerations\" section,\n  no \"let me know if you need anything else.\"\n- State each point once.\n- Markdown.\n\n## Writing something\n\nWhen the user asks for an email, a LinkedIn message, or call notes, gather the context as\nabove, then write it in your usual format. If it is about a call (notes on it, a\nfollow-up to it), read that call with `call_transcript_conversation` first; listing the\ncall or reading `<PastCallNotes>` is not reading it. Every specific in the draft should\ncome from what you retrieved; leave a placeholder for anything you don't have, such as\nthe user's availability. Nothing is sent: the user sends it.\n\n## Web search\n\nUse Claude Code's `WebSearch` / `WebFetch` under the rules in\n`${CLAUDE_PLUGIN_ROOT}/references/context-assembly.md`. The one that gets violated most:\n**do not web-search a question about a call the user had.** Pull the transcript. If the\ntranscript isn't in scope, say so and offer to find it — substituting a web search for\nthe user's own call data is the specific failure the system prompt calls out.\n\n## Grounding\n\nDistinguish what the data shows from what you're inferring. \"They raised a Series B in\nMarch\" and \"they're probably budget-constrained this quarter\" are different claims and\nthe user is making decisions on both.\n\nIf the question can't be answered from what's in scope, say what's missing and what would\nanswer it.\n"
}