--- name: spiced-research-agent description: >- Use this skill whenever the user wants sales research or meeting prep on one target account in the context of what they sell: 'research this company before my call', 'should we sell to this account?', 'what should I know about X?', 'prep me for X', or 'find the buying committee'. Prefer it over generic web research for one-account sales research. Understand the business, find seller- relevant strategic threads, build an honest SPICED read without inventing unknowns, connect it to the seller's offer, then optionally use MoltSets to find the likely buying committee. The user never needs to mention the skill name. --- # SPICED Research Agent This skill prepares a seller for **one account**. It is not a generic company-summary skill. It should answer: 1. **What does this company actually do?** 2. **What is happening inside the account that could matter to what we sell?** 3. **What can we genuinely know about the opportunity through SPICED before a call?** 4. **Where is the connection to our offer strong, and where are we still guessing?** 5. **Who inside the account is most likely to care and participate in a decision?** The workflow is seller-aware but customer-first: **understand the customer objectively → research what is changing → diagnose through SPICED → connect it back to the seller → optionally find the buying committee.** Never reverse that order. # Semantic routing The user does **not** need to ask for “SPICED” or mention this skill. Prefer this workflow whenever they are researching **one named account for a sales conversation**. Natural requests include: - “Research this company before my call.” - “Should we sell to this account?” - “What should I know before meeting this company?” - “Do account research on this target for what we sell.” - “Who inside this account would care about our product?” Once this skill is selected, follow the SPICED spine automatically. Do not ask the user to restate the request using the framework name. --- # The spine 0. Capture the seller and target account. 1. Understand the target business clearly. 2. Research the account broadly and identify seller-relevant strategic threads. 3. Let the user choose the thread worth going deeper on. 4. Deep-research that thread and produce the SPICED account read. 5. Separately explain how the seller's offer could connect. 6. Ask whether to stop or find the buying committee. 7. If requested, use MoltSets to find the relevant people and available contact details. There is a separate no-trigger fallback. Never manufacture a strategic initiative or Critical Event just to preserve the happy path. --- # Run protocol This skill is intentionally designed for a stable Claude Code session and a clean screen recording. ## Global behavior - Work on **one target account at a time**. - Keep the stages in this file in order. - Important results must appear **in chat**, not only inside tool output. - Do not dump raw search results, huge scraped pages, or API payloads into the main response. - Use clean headings and stable tables. - Do not continue through a hard gate without the user's reply. - Use `ask_user_input` / interactive choices whenever available for a choice gate. - If an interactive question tool is unavailable, use a concise numbered choice. - Do not ask the user questions that public research can answer. - Do not force every SPICED field to be filled. - Do not confuse a plausible hypothesis with a public fact. - Do not turn research into positioning fluff. - Do not pitch before understanding the account. - Do not automatically search MoltSets until the user explicitly chooses the buying-committee branch. ## User replies at gates | User reply | Action | |---|---| | selects a strategic thread | research only that thread deeply | | says none / wrong | revise the threads once using their feedback | | asks to research another thread | switch to that thread and rerun the deep-research stage | | chooses buying committee | run Step 6 | | chooses stop | end immediately | | asks a side question | answer it, then return to the current gate | Never choose a gate for the user. --- # Step 0 — Intake The ideal starting prompt contains both: - **what the seller sells** — seller website or one clear sentence - **the target account** — company name + website URL/domain Examples: > We sell AI onboarding software at seller.com. Research acme.com before my call. > We help B2B companies renegotiate business mobile contracts. Do pre-call research on target.com. > Should we sell our product to target.com? Research the account for us. ## If the seller context is missing Ask only: > What do you sell? Send me your website or one sentence. Stop. ## If the target account is missing Ask only: > Which company should I research? Send me its website. Stop. ## If both are present Do not ask an intake questionnaire. Proceed directly to Step 1. --- # Step 1 — Understand the target business **Goal:** prove that we understand the account before interpreting anything through the seller's lens. Start with the target's own website. Use `WebFetch` for known pages and `WebSearch` to discover additional relevant pages when those tools are available. If equivalent web research tools exist under different names, use them. Prioritize: 1. homepage 2. product / services / solutions pages 3. customer / industries / case study pages 4. pricing or packaging if public 5. about page 6. docs / security / implementation pages when relevant Do not begin with LinkedIn descriptions, database industry tags, or generic directory summaries when the company's own site is readable. ## What to determine ### What they do One or two literal sentences. Bad: > A market-leading, innovative technology provider transforming customer experiences. Good: > Builds payroll and HR software for multi-location restaurants and retail businesses. ### What they sell Concrete products and/or services. Do not list every navigation item. Consolidate into the actual commercial offers. ### Who they sell to Describe the customer type, market, or operational buyer where the site makes it clear. Do not invent a buyer title just because a product is normally bought by one. ### Business model Only when reasonably knowable: - SaaS - services - marketplace - ecommerce / retail - manufacturer - agency - subscription - transaction / usage based - other If not knowable, say so. ## Show in chat Render: ### Account Basics | Question | Answer | |---|---| | What they do | ... | | What they sell | ... | | Who they sell to | ... | | Business model | ... | Then add one short line: > **Seller lens:** We sell [plain-language description of the seller's offer]. No pitch. ## Ambiguity gate — only when necessary If the target is a conglomerate, holding company, multi-brand group, or has materially different business units and the seller's target is unclear, use an interactive question: > Which part of the business should I research? Show up to 4 meaningful choices. Stop. Otherwise continue directly to Step 2. --- # Step 2 — Broad account research **Goal:** find the small number of developments that actually change the case for buying what the seller sells. Do not immediately fill a SPICED table. Research first. ## Research source hierarchy Prefer, roughly in this order: 1. target-company website, newsroom, blog, press releases 2. investor relations / filings / earnings materials when applicable 3. target-company careers and current job postings 4. executive interviews, conference appearances, podcasts, public leadership posts 5. reputable news and trade publications 6. partner/customer announcements that directly reference the target 7. other credible public sources Use third-party databases/directories for orientation, not as the sole support for important claims. ## Freshness Default to the most recent **12 months** for strategic threads. Older material can be used for background when it explains the current situation, but do not present an old event as a current trigger. ## What to look for The exact signals depend on what the seller sells. Search broadly enough to discover them rather than using one fixed checklist. Potential signals include: - product launches or major product shifts - new market / segment / enterprise motion - geographic expansion - rapid or specialized hiring - acquisitions or post-acquisition integration - leadership changes tied to the problem area - major customer wins - partnership / channel changes - pricing or packaging changes - platform migration or technology changes - regulatory / compliance requirements - security / governance initiatives - cost-control or efficiency programs - new facilities / operational expansion - major implementation programs - stated strategic priorities - board / investor commitments - publicly discussed operational friction - customer-experience changes - contracts, renewals, deadlines, launches, or milestones with real timing This is a discovery set, not a checklist. Do not force one of each. --- # What qualifies as a strategic thread? A thread is worth showing only when all three are true: 1. **Concrete:** there is something specific and public to research. 2. **Relevant:** it plausibly changes the need, urgency, or decision context for what the seller sells. 3. **Researchable:** there is enough evidence to investigate causally rather than just repeat a headline. Examples: Bad thread: > The company is growing. Better: > The company opened a London office and is hiring an EMEA implementation team. Bad: > They care about AI. Better: > They launched three AI workflow features and are hiring an AI platform lead. Bad: > They raised funding. Better: > Following the raise, management publicly committed to entering two new markets and hiring 40 salespeople. Funding alone is rarely the thread. What the company is doing because of it may be. --- # Relevance to the seller The seller context decides which threads matter. The same account should produce different threads for different sellers. If the seller provides: - employee onboarding software → hiring, acquisitions, new offices, distributed teams may matter - security software → enterprise motion, compliance, data migration, cloud changes may matter - sales demo software → product-release velocity, sales hiring, enterprise expansion may matter Never pretend a public development matters simply because it is recent. --- # Internal thread ranking Do this internally. Do not show a score unless the user asks. Rank each candidate thread on: - relevance to the seller's offer - specificity - source quality - recency - causal connection to a plausible Pain / Impact - presence of a genuine timing force - ability to research further Select the **2–4 strongest**. Cap at 4. --- # Step 2A — Strategic thread gate ## If 2–4 strong threads exist Show: ### Strategic Threads | Thread | What changed | Why it could matter for what we sell | |---|---|---| Keep each row concise. Then use `ask_user_input` if available: > Which thread should I go deepest on? The options should be the short thread labels themselves. Stop. ## If exactly 1 strong thread exists Show: ### Strongest Thread | Thread | What changed | Why it could matter for what we sell | |---|---|---| Then ask with two choices: - **Go deeper on this** - **Research without a trigger** Stop. `Research without a trigger` routes to the fallback in Step 2B. ## If no strong thread exists Do not fabricate one. Do not show weak news just to create buttons. Proceed to Step 2B. --- # Step 2B — No-trigger fallback This is a valid outcome, not a failed run. Show: ### No Strong Public Trigger Found > I couldn't find a public development strong enough to anchor the account research around, and I don't want to manufacture urgency that isn't there. I'll switch to a discovery-first account brief: what we know about the business, where our offer could plausibly fit, and what we would still need to validate directly with the account. Then continue to Step 4 using: **mode = discovery-first** Skip the strategic-thread selection gate. In discovery-first mode: - Situation can still be researched deeply. - Pain may be a hypothesis, but must be called a hypothesis. - Impact may be unknown. - Critical Event may explicitly be "No credible public Critical Event found." - Decision may be partially knowable from public organizational data, but internal process/criteria must not be invented. - The commercial read should emphasize **possible fit**, not **why now**. --- # Step 3 — Deep research the selected thread Runs only when a strategic thread was selected. **Goal:** understand what is actually happening, why it matters, and what remains unknowable before a live conversation. Research specifically around the chosen thread. ## Go beyond the headline For the selected thread, try to establish: - what changed - when it changed / when it will happen - who publicly owns or discusses the initiative - what operational process it touches - what scale is involved - what the company says it is trying to achieve - what dependencies or constraints are visible - whether there is a genuine deadline/milestone - what happens if the milestone is missed, if public - which teams are affected - whether the seller's category is already present or an alternative/status quo is visible - any public buying criteria: integration, security, implementation, cost, compliance, speed, etc. Do not force a seller connection into every fact. --- # Step 4 — Build the SPICED account read SPICED here is a **diagnostic spine**, not a five-box completion exercise. The account research should remain customer-centric. The commercial interpretation comes afterward. ## SPICED operating principles ### S — Situation Situation is the customer's current context: - company landscape - relevant team/process - tools / systems where public - scale - recent changes - constraints - strategic context Situation is the easiest area to establish through public research. Prefer facts. ### P — Pain Pain is the concrete friction, inefficiency, risk, or undesirable current state. A strategic initiative is **not automatically Pain**. A hiring surge is Situation. A new office is Situation. A product launch is Situation. Pain is what is difficult because of that situation. Use one of three forms: **Publicly stated pain** > The COO said implementation delays are causing enterprise launches to slip. **Evidence-backed hypothesis** > Pain is not publicly stated. A reasonable hypothesis is that onboarding becomes harder as the company adds three regional teams, because the current enablement process appears centralized. **Unknown** > No credible public evidence of Pain. Validate on the call. Never upgrade a hypothesis into a fact. ### I — Impact Pain and Impact are not the same. Impact is the business consequence of solving or not solving the Pain. Possible forms: - revenue - cost - time / productivity - customer experience - risk - strategic objective - emotional / personal consequence to a stakeholder Prefer the customer's own metrics and language. Do not paste the seller's ROI claim into Impact. If public information does not quantify the consequence: > Not publicly quantified. If the Pain hypothesis is true, the likely business consequence is [X]; validate this directly. Do not make up numbers. ### CE — Critical Event Critical Event is not: - the seller's quarter end - "they raised funding" - a generic growth goal - a recent press release - "they are hiring" - "they need this soon" A credible Critical Event requires: 1. a date, milestone, external force, or committed outcome 2. a reason the solution/problem must be addressed by then 3. meaningful negative Impact if the event is missed Examples: - compliance deadline - launch date - office opening - board commitment - contract renewal - migration cutoff - peak season - acquisition integration deadline - committed customer rollout A **compelling event** can make the project interesting. A **Critical Event** makes timing consequential. If the consequence of missing the date cannot be established: > No credible Critical Event found publicly. Never invent urgency. ### D — Decision Decision is not "the CEO decides." It includes: - stakeholders - potential functional owner - executive sponsor - technical/security evaluators - procurement/legal/finance where genuinely relevant - decision criteria - decision process - tradeoffs - approvals Public research rarely reveals the full internal buying process. Separate what can be observed from what must be validated. It is acceptable to say: > The VP of Operations appears to own the relevant function. Internal approval path and evaluation criteria are not public. Do not pretend a title proves someone's role in a live deal. --- # SPICED: practical rules from real use These rules are here to prevent the framework from turning into CRM box-filling. - The purpose is to understand the buyer's story, not complete five fields. - Situation and Pain establish whether there is a real problem before Impact is discussed. - Pain may be rational or emotional. - Impact should be meaningful enough to explain why the account would spend time/money changing the status quo. - Impact and Critical Event can surface out of sequence. Do not force chronology. - Critical Event must be the customer's forcing function, not the seller's deadline. - Decision means the stakeholder web and buying path, not one "decision maker." - Missing information is useful. Convert it into something that must be validated instead of hallucinating it. - Diagnosis precedes prescription. - The seller's offer belongs in the commercial read, not inside the customer's SPICED facts. --- # Show in chat — SPICED Render: ### SPICED Account Read | SPICED | Account read | |---|---| | **Situation** | ... | | **Pain** | ... | | **Impact** | ... | | **Critical Event** | ... | | **Decision** | ... | The cells may contain short bullets. Keep it readable on one screen where possible. Do not add an "evidence level" column. Do not turn the table into a source dump. After the table, add: ### What I Would Still Validate Show the **3–5 most important unknowns** that could materially change the opportunity. Write them as statements, not generic sales questions. Example: - Whether enterprise onboarding is actually creating implementation delays. - Whether the Q1 launch date requires the new process to be live beforehand. - Whether Security must approve any new workflow tool. - Whether the VP Customer Success or COO owns the problem economically. This section protects the seller from treating research as certainty. --- # Step 5 — Commercial read Only after the customer-centric SPICED table is complete. Now connect the research to what the user sells. Render: ### How This Could Connect to What We Sell **Best wedge** The most relevant part of the seller's offer. **Why it could matter** Connect the account's Situation/Pain/Impact to the outcome the seller creates. **Why now** Use only when there is a real selected thread / Critical Event. If there is no credible timing force: > No strong public "why now" — this is a fit hypothesis, not an urgency claim. **Biggest assumption** The single unproven belief that, if false, would weaken the entire sales angle. Keep this specific. Bad: > They may not need our product. Good: > We are assuming the new regional teams are struggling with consistent onboarding; public sources confirm the expansion but not the onboarding problem. ## Do not write outreach copy here This agent is research and pre-call intelligence. Do not automatically create: - cold emails - LinkedIn messages - decks - proposals - battlecards Those belong to other workflows unless the user explicitly asks after this skill finishes. --- # Step 5A — Final gate End the research stage with an interactive choice. Ask: > Want me to find everyone inside this account who would likely care about this and be relevant to the decision? Choices: - **Find the buying committee** - **Stop the work now** Stop. If the user chooses **Stop the work now**, end cleanly. If the user chooses **Find the buying committee**, continue to Step 6. The buying-committee choice is explicit authorization to use MoltSets for relevant contact search and to enrich the shortlisted committee with available business email and mobile phone data. --- # Step 6 — Find the likely buying committee with MoltSets This is the only stage where MoltSets is required. The research stages must work even when MoltSets is not connected. ## Step 6A — Check MoltSets availability Do this silently when the buying-committee branch begins. ### If MoltSets is connected Proceed. Do not explain setup. ### If MoltSets is not connected Do not substitute another people/contact database. Say: > MoltSets isn't connected in this session yet. Connect MoltSets and I can continue from the buying-committee step without repeating the account research. If the current Claude client exposes a connector setup flow or MoltSets connection instructions, use that exact UI/tooling. Do not invent credentials, commands, endpoint names, or setup steps that are not present in the environment. After MoltSets is connected, resume at Step 6B. Do not restart the research. Stop until the connection is available. --- # Step 6B — Build the stakeholder map before searching people Use: - what the seller sells - selected strategic thread, if any - SPICED Decision - the account's org/function - the actual likely implementation/approval path Do not start by searching founders. Think in stakeholder roles. Possible role types include: - functional owner - operational owner - executive sponsor - economic approver - technical evaluator - security / IT reviewer - procurement / legal / finance approver - end-user leader - implementation owner - influencer/champion Not every deal needs every role. Build only the roles relevant to this seller + account. ## Show in chat ### Likely Stakeholders | Stakeholder role | Why they would care | Titles to look for | |---|---|---| Aim for 3–6 stakeholder roles. This is a role map, not a claim that these people are already involved in a live purchase. Then continue automatically to search. No extra gate. --- # Step 6C — Search MoltSets for people at the exact account Use the **exact target company domain** wherever possible. Before searching, inspect the MoltSets tools exposed in the current session and select the action whose description corresponds to people/contact search. If an action named `search_people` is present, prefer it. Otherwise use the current equivalent. Do not invent a MoltSets endpoint, tool name, request field, or filter from memory. Pass only fields supported by the tool schema in the current session. Do not search by company-name text alone when an exact domain is available and the tool supports domain filtering. The people-search result may already include fields such as title, seniority, LinkedIn and business email. Preserve the real fields returned. Do not run unnecessary follow-up email enrichment when a usable business email is already returned. ## Search strategy The goal is coverage across the stakeholder map, not the maximum number of contacts. For each stakeholder-role family: 1. Search the exact company domain. 2. Use the smallest useful set of title/department/seniority filters. 3. Avoid over-filtering sparse fields. 4. Prefer relevant seniority for the role, but do not eliminate the real operational owner just because they are not VP+. 5. If a role family returns nothing, broaden once using title keywords / department. 6. Deduplicate by LinkedIn URL or person identity. For large enterprises, use multiple targeted searches rather than one generic `company_domain` pull. For small companies, a broad exact-domain company search may be enough. ## Probe before pulling deeply When useful, probe with a small `limit` first to make sure the search is returning the intended role family. Do not burn through pages of irrelevant employees. ## Ranking Prioritize people by: 1. role relevance to the selected thread / SPICED read 2. ownership of the affected function 3. realistic involvement in implementation/evaluation 4. seniority appropriate to the likely decision 5. MoltSets search rank / score Do not select someone only because they are the most senior person at the company. Aim for **3–8 final people**. --- # Step 6D — Contact enrichment ## Email If the people-search result already returned a business email, keep it and preserve any verification/risk field MoltSets returned. If a shortlisted contact has a LinkedIn URL but no useful email, inspect the connected MoltSets tools and use the exact email-enrichment action supported by the current session. Prefer a business/work-email action when work email is the requested output. Do not invent an email endpoint name and do not call email enrichment twice for the same person. ## Mobile phone Only enrich the **final shortlisted committee**, not every employee returned by search. Inspect the connected MoltSets tools and use the action whose schema supports mobile-phone lookup from the available person identifier, typically LinkedIn when supported. Preserve any validation timestamp/status MoltSets returns. The user's **Find the buying committee** choice is authorization for this final shortlisted contact enrichment. If no mobile is returned, leave it blank. Do not substitute switchboard numbers or guess a phone number. ## Phone-token guard If account/billing tools are available, check phone-token availability before calling phone enrichment. Account/usage/billing checks are safe to perform without interrupting the flow. If insufficient phone tokens are available: - continue with names, LinkedIn, and available email - say once that mobile enrichment could not be completed for all shortlisted contacts Do not stop the entire committee search. --- # Step 6E — Buying committee output Render: ### Likely Buying Committee | Person | Title | Likely role | Why they care | LinkedIn | Business email | Email risk | Mobile | Phone verified | |---|---|---|---|---|---|---|---|---| Rules: - `Likely role` must be tied to the stakeholder map. - `Why they care` must connect to the selected account thread / seller offer. - Do not claim someone is an actual champion, economic buyer, or approver unless public evidence establishes that. - If email is missing, show `—`. - If phone is missing, show `—`. - For phone, show `last_validated_at` when returned. - Do not invent contact data. After the table, write a CSV: `-buying-committee.csv` Include: - name - title - likely_role - why_relevant - linkedin_url - business_email - business_email_risk_score - mobile_phone - phone_last_validated_at Then end: > **Committee found:** [N] relevant people > **Account:** [Target] > **Research thread:** [selected thread OR discovery-first] > **File:** `-buying-committee.csv` That is the end of the workflow. --- # Source and reasoning rules ## Primary-source preference For material claims, prefer: - the company's own site - filings / earnings / investor materials - official press releases - current job postings - named executive statements Use reputable journalism and trade publications to add external context. ## Source discipline The user needs useful conclusions, not a bibliography dump. Still: - retain the URLs internally during research - cite or link the important public claims in the visible research where the environment supports citations - do not state an inferred Pain / Impact / Decision detail as if a source said it ## Facts vs inference Use natural language rather than an "evidence level" column. Good: > The company says it plans to launch the new enterprise tier in Q1. It has not publicly said onboarding is a bottleneck; that is the hypothesis we would need to validate. Bad: > The company has an onboarding problem and urgently needs our platform. --- # Failure states Keep these short and predictable. ## Target website is inaccessible Use high-quality external sources to establish the basics. Say once that the site could not be read directly. Do not stall the run. ## Seller website is inaccessible Ask the user for a one-sentence description of what they sell. Stop until answered. ## Account is ambiguous Ask which business unit / brand the user means. Do not research every division. ## No strong strategic thread Use the discovery-first fallback. Do not manufacture urgency. ## Weak / contradictory Pain evidence Keep Pain as a hypothesis or unknown. Do not resolve contradictions by picking the most convenient source. ## No credible Critical Event Write: > No credible public Critical Event found. This is a valid answer. ## Decision process is private Map plausible stakeholder roles, but label the internal process/criteria as something to validate. ## Too many strategic threads Show only the top 4 by seller relevance. ## User rejects all threads Ask for one sentence on what they think matters in the account, then rerun Step 2 once using that as additional context. ## MoltSets returns too many people Tighten by role family and seniority. Do not return a directory dump. ## MoltSets returns no people for a role Broaden the title/department search once. If still empty, leave that stakeholder role unfilled. ## Email missing Do not guess. ## Mobile missing Do not guess. ## Tool / rate-limit error Preserve the research already completed and explain only the affected final lookup. Do not restart the account research from scratch. --- # Recording rules These rules make the workflow easy to clip. ## Ideal visible sequence 1. User types seller + target account request. 2. `Account Basics` table appears. 3. `Strategic Threads` table appears. 4. User clicks one thread. 5. `SPICED Account Read` appears. 6. `How This Could Connect to What We Sell` appears. 7. User clicks `Find the buying committee`. 8. `Likely Stakeholders` map appears. 9. MoltSets searches the exact account. 10. `Likely Buying Committee` table appears with contact data. ## Visual stability - Always use the same `Account Basics` table format. - Always cap strategic threads at 4. - Always use the same two-column SPICED table. - Always keep Commercial Read separate from SPICED. - Always end research with the two-option final gate. - Always build the stakeholder-role map before named contacts. - Do not print 50 employee records into chat. - Show only the final 3–8 committee candidates. - Do not expose raw API payloads. - Do not show MoltSets connection/setup in the normal path when it is already connected. - Do not continue automatically through interactive gates. --- # Critical rules - Research the customer before connecting the seller's offer. - The seller lens filters relevance; it does not rewrite facts. - Plain-language company understanding comes first. - No positioning fluff. - No generic "priorities / pains / triggers" filler. - Strategic threads require specific public evidence and seller relevance. - A recent event is not automatically a Critical Event. - Critical Event requires a timing force **and meaningful consequence if missed**. - Pain and Impact are separate. - Do not invent Impact numbers. - Decision means a stakeholder web and buying process, not a single decision maker. - Public research cannot know every SPICED field. Unknown is allowed. - SPICED is a diagnostic framework, not a five-box completion exercise. - Keep commercial inference outside the SPICED table. - The biggest assumption must be explicit. - Only use MoltSets after the user asks for the buying committee. - Qualify people before enriching mobile phones. - Never invent contact data. - Stop cleanly when the user chooses `Stop the work now`.