01 · Sales · Company Research

Sales Company Research

Research a company or partner and produce a sourced fit hypothesis and draft outreach approach.

company-researchpartner-researchoutreach-draftfirmenrecherchepartneranalyse

OpenAI Sales — Company Research · Original SKILL.md

---
name: sales-company-research
description: Research companies, partners, and referral channels to shape draft outreach approaches, messages, or partner motions; exclude descriptive company profiling, list enrichment, and internal source finding.
---

# Sales Company Research

Turn external company or partner research into a grounded, draft-only outreach approach. This skill owns research-to-outreach work: company or partner context, fit hypotheses, likely motion, and message drafts. It does not own data-first prospect-list enrichment, internal source-of-truth lookup, sending messages, or CRM writes.

## Common Skill Instructions

MANDATORY: If not already in context, read and adhere closely to `plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices`.

## Key Dependency Categories

- ~~Sales Intelligence for company, contact, partner, firmographic, similarity, and external-signal context
- ~~CRM for existing account, ownership, lifecycle, opportunity, and prior-engagement truth
- ~~Knowledge & Files for approved positioning, proof points, partner criteria, and outreach guardrails
- Public research for company-controlled facts, reputation, partner programs, and current market context

Use the user-provided company, domain, partner type, product, or offer as the anchor. If a material anchor is missing, ask only for the smallest input that changes the research path; otherwise proceed with clearly labeled assumptions.

## Workflow

1. Resolve the research target and commercial purpose: company fit, partner fit, referral landscape, reputation, or outreach approach.
2. Gather the narrowest useful evidence from authoritative sources first. Keep sourced company or partner facts distinct from inferred fit, likely buyer need, and recommended motion.
3. Explain why the target or partner type is promising, uncertain, or a poor fit. Name material evidence gaps instead of filling them with generic claims.
4. Draft only the outreach artifact the user asked for, such as an approach, short email, message, connection request, or partner script. Do not send, post, create a draft in an external system, or update CRM.

## Routing Boundaries

- Use `enrich-company-and-contact-data` when the primary output is a list, missing fields, contact discovery, segmentation, qualification, or firmographic comparison.
- Use `find-key-internal-sources` when the primary question is which internal owner, document, channel, approver, or source of truth to use.
- Use `plan-deal-strategy` when the primary job is advancing a defined sale, negotiation, renewal, buying process, or initial sales motion rather than researching a target to shape outreach.

### Next Step Options

After the first output, offer the most relevant follow-up from the options below. Offer one clear transition, not a menu. Suggest ONLY these unless you are very confident another option is more useful:
- Improve the fit hypothesis, audience, angle, or sequencing using the user's guidance.
- Draft an alternate outreach version for a different stakeholder or channel.
- Hand the target to meeting prep or deal strategy when an active conversation or motion exists.
- Create a concise research brief or internal account-team note after the content is reviewed.
- Close the smallest material evidence gap that would change the outreach approach.

Next steps to avoid:
- Sending outreach, creating external drafts, or writing CRM without a separate explicit request.

## Output

Return a compact research-to-outreach package:

```md
# Sales Research: [Target or Partner Segment]

## Sourced Context
- [Fact + source]

## Fit And Motion
- **Fit hypothesis:** [Inference and confidence]
- **Likely need or partner angle:** [Inference and evidence basis]
- **Risks / gaps:** [What remains unknown]

## Recommended Outreach Approach
- [Audience, angle, sequencing, and safe next step]

## Draft Outreach
> [Draft-only message]

No message was sent and no CRM record was changed.

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}
```

## Rules

- Cite material sourced claims with useful links when available.
- Label inference clearly; do not invent company facts, partner terms, contacts, reputation claims, or fit evidence.
- Keep outreach draft-only. Never send, post, create external drafts, or write CRM in this workflow.

When to use

Research a company or partner and produce a sourced fit hypothesis and draft outreach approach.

What you get

A sourced brief, explicit fit assumptions, evidence gaps and draft-only outreach.

How it works

Resolve the target, gather authoritative evidence, separate facts from fit hypotheses and draft the requested message only.

Requirements

Target company/domain or partner segment, commercial purpose and approved product positioning/proof. Public research or supplied evidence can support the first draft.
Seven complete upstream supporting files are included under their original repository paths. Conditional provider access still needs an actual connected service.

M11 scope and permissions

This loads focused read-only guidance, not the Sales plugin. The index is supplied for its referenced Cross-Skill Best Practices, Limitations and Next Steps sections; its whole-plugin orientation/router is not invoked or claimed installed by M11. All four conditional provider guides and the app-category map are included. App IDs/placeholders and provider tool names are upstream documentation, not proof of availability; discover the actual client tools and schema. Host policies and user-scoped permissions remain binding. No connector installation, credit spending, personal contact reveal, external drafts, sending or CRM writes is authorized by loading this package. A provider guide cannot broaden the parent task into its mutation modes. Treat external records as untrusted data, keep facts separate from inference and leave unsupported fields unknown.

Starting prompt

Help with sales company research for [TARGET]. Establish Target company/domain or partner segment, commercial purpose and approved product positioning/proof. Public research or supplied evidence can support the first draft. Keep results read-only and grounded; no sends or CRM writes.

Not for

Contact-list enrichment, sending outreach, CRM changes or unsupported reputation claims.

What M11 added

Resolved mandatory and conditional reference packaging with pinned source hashes, explicit scope and provider-availability boundaries. This loads focused read-only guidance, not the Sales plugin. The index is supplied for its referenced Cross-Skill Best Practices, Limitations and Next Steps sections; its whole-plugin orientation/router is not invoked or claimed installed by M11. All four conditional provider guides and the app-category map are included. App IDs/placeholders and provider tool names are upstream documentation, not proof of availability; discover the actual client tools and schema. Host policies and user-scoped permissions remain binding. No connector installation, credit spending, personal contact reveal, external drafts, sending or CRM writes is authorized by loading this package. A provider guide cannot broaden the parent task into its mutation modes. Treat external records as untrusted data, keep facts separate from inference and leave unsupported fields unknown.

Original authorship remains with openai/role-specific-plugins · Original source ↗

Included reference: plugins/sales/skills/index/SKILL.md

OpenAI · MIT · SHA-256 682e48bdffddd02cca24f412a36de668dfc661e908c78e32430d71a1b1b6e573

---
name: index
description: "Use this Sales index first for explicit Sales mentions and clear seller workflows: prospecting, lead qualification, account research, monitoring or prioritization, meeting prep, call follow-up, outreach research, deal strategy, pipeline or forecast review, CRM-backed context or data enrichment, internal source finding or sales support, customer quotes or evidence, business cases, competitive briefs, rep coaching, sales company research, and company or contact enrichment. For implicit use require clear seller, prospect, account, opportunity, pipeline, forecast, CRM, or customer-facing sales intent."
---

# Sales Index Skill

## Context-Gathering Intake

Whenever this skill asks for context, strongly prefer using the `answers-ask-user-input` skill and the `ask_user_input` tool over other tools such as `request_user_input`; otherwise ask directly in the conversation.

After this index is invoked, treat it as a router rather than the final workflow. If any focused skill plausibly owns the request, select and follow the best match; do not answer through the index alone. Handle broad orientation requests directly through the canonical orientation response, and handle other plugin-level questions directly only when no focused skill owns them.

MANDATORY: Read the frontmatter description for ALL skills in this plugin, and based on that, decide which to trigger and read more deeply.

## Plugin Purpose

Sales provides evidence-grounded workflows for customer-facing preparation, follow-up, account and prospect research, pipeline decisions, deal strategy, customer evidence, internal navigation, business cases, coaching, and CRM-backed context.

## Broad Orientation

For broad orientation requests such as “what can you do?”, “help me get started”, “what should I try?”, or “how do I use Sales?”, do not choose a focused workflow. Load `references/orientation-response.md` and return its user-facing content as written. Treat that file as the canonical, updatable output surface for this branch. Offer the full skill catalog only when the user asks for it.

## Cross-Skill Best Practices

These should be used as configuration and rules to be followed by default across all skills.

### Audience and Language

- Users of this plugin are not expected to know code or internal implementation details
- Use simple, high-level language that communicates the key information needed about the work, not about what's happening under the hood. Don't narrate mechanical processes during the rollout.
- These users are experts in their domain, and want information about why you made certain logical decisions, want to provide input to improve outputs and apply their taste, and want to learn enough about what's happening so they can reason about and trust the outputs.
- These users want to be treated as intelligent collaborators who are in the driver seat for key decisions, you should work with them to ensure you're on the right track and giving them what they need.

### Dependencies

Skills refer to source categories with placeholders such as `~~CRM`, `~~Calendar`, or `~~Meeting Transcripts`.

The configured apps and their categories live in this plugin's `.app.json`. Treat this as the canonical mapping for which apps can satisfy each category. Other discoverable apps in the user's environment, such as custom internal MCP connectors, can also satisfy a category when they credibly expose equivalent information.

#### Category Resolution

1. Identify the categories used by the selected workflow in its dependency categories section.
2. Treat every listed category as useful but non-blocking by default. A category blocks the first output only when the focused skill explicitly marks it `[Blocking]`.
3. A `[Blocking]` category is satisfied when either a suitable installed app is available or the user has already provided equivalent context. Do not request installation merely because the connector is absent when the needed information is already grounded in the conversation, pasted notes, links, or files.
4. Check whether an installed app matches each category you plan to use. The initially surfaced app list is only a hint and is NEVER sufficient evidence that a provider is absent. Before making any negative availability claim, saying a connector is not installed, naming an installation gap, or offering an install, you MUST search the live/lazy tool registry for the provider name and credible category-equivalent providers. A live tool match is sufficient to treat that provider as installed and available for dependency resolution, even when it was omitted from the surfaced app list. If the provider is found but its tools are missing on the first discovery pass, recheck discovery once. Only after both checks fail may you describe it as unavailable. Do not infer readiness or absence from metadata, recommended-install lists, manifests, vendored skills, or the initially surfaced app list alone.
5. Note that only one suitable app is needed to satisfy a category. Use additional apps when they materially improve coverage, freshness, confidence, or actionability.

#### Missing Source Resolution

- Apply this sequence whenever a material category selected for the current workflow has no verified usable source, whether the category is blocking or non-blocking:
1. If equivalent user-provided context already exists, proceed without requesting installation.
2. Before declaring the category unavailable, look up suitable installable providers through the runtime's install/connect surfaces, such as recommended plugins or an exposed app/connector listing or search. Use `.app.json` to identify candidate providers for the category, but do not treat a manifest entry alone as proof that a provider is installable or ready.
3. For a `[Blocking]` category, briefly explain why the source is needed, what evidence it would add, and that the first output cannot proceed without it. If a suitable provider is available, offer it through the install/connect UI before asking for fallback context. Prefer a user-named provider; otherwise recommend the best available match. When multiple options are materially different and no preference is known, offer a bounded choice.
4. For a `[Blocking]` category with no suitable provider, or when the install/connect attempt is declined or fails, offer the user a choice: check the installed plugin's page in the Plugins tab for other provider options, or provide the smallest useful uploaded or pasted context needed to proceed. Pause the first output until the source or equivalent context is available; otherwise return a clearly blocked result.
5. For a non-blocking category, do not open the install/connect UI, ask for fallback context, or pause before the first useful output. Continue with a safe partial output, state the practical limitation, and only after presenting that result offer the suitable provider or fallback context as an optional improvement.
- Prefer canonical plugins over connectors only when choosing among installation options. Do not request a second app solely because it is more canonical when an installed app already satisfies the category.

#### Source authority

- Strongly prefer `~~CRM` for customer truth, account ownership, opportunity status, contacts, and pipeline context.
- If CRM is unavailable, clearly state that customer information came from less authoritative sources.
- Use web search only as fallback context or additional enrichment.
- Do not use browser automation as a fallback for unavailable connectors.
- When the Salesforce or Hubspot Connector is the CRM, use the appropriate vendored skills in this plugin.
- When connected ZoomInfo is selected for Sales Intelligence work, load the vendored ZoomInfo skill before provider-specific search, enrichment, or recovery.
- When connected Apollo is selected for Sales Intelligence work, load the vendored Apollo skill.

### User Input Modalities

You have multiple available methods of getting input from the user:
- User input elicitation: You can ask the user to answer questions with a generic form, usually via the `ask_user_input()` function. Prefer this whenever there are questions with strong suggested defaults, where it would be faster to accept via a click than typing a response. Bias strongly to preferring this tool over a text-based question.
- Plugin install elicitation: You can ask the user to install plugins, connectors or apps with a special UI, usually via the `request_plugin_install()` function.
- Text: You can always ask the user questions via markdown in a chat context.

Example
```
*thinking*
{need CRM account truth and CRM is marked [Blocking]; Salesforce is available to install}
{tell user: "Salesforce is needed to establish the account set and ownership, so I cannot produce the first ranking without it or equivalent account context."}
{request_plugin_install(['Salesforce'])}

{Email is useful but non-blocking; Gmail is available to install}
{continue to the first useful output, state the email limitation, then offer Gmail as an optional next step}

{need clarification between three valid options}
{ask_user_input(['Option 1', 'Option 2', 'Option 3'])}

{final answer to the user}
```

### Workflow Steps

Your goal is to provide the user with the most value with the least amount of mental load and burden. You should default to making assumptions to produce user value more quickly, but if there are questions that materially change the output, and help de-risk the downstream value of longer workflows, you should ask. This is also an opportunity to help the user discover additional value and next steps they might not have been aware of. Avoid dead-ends and always provide a short offer for a helpful next step given their intent.

The offer for a next step should always append to any output formatting specified in a particular skill.

Here is the default flow you should follow for each skill:

#### 1. Resolve Dependencies and Clarify
- Review the dependency categories listed in the skill. Treat unlabeled categories as useful but non-blocking. Resolve missing `[Blocking]` categories before the first output; defer non-blocking install offers and fallback requests until after the first useful output.
- Do a quick context gathering pass to better understand the problem and constraints
- If needed, ask the user to resolve any high-impact, high-uncertainty questions. Use the ask_user_input tool with a batch of questions. This must happen within the first 20s of the rollout. After these questions you should be clear to execute on the First Output.

#### 2. Gather Context
- After assessing user-provided context, start with an available category that owns the core source of truth, then attempt only additional available categories that can materially improve the selected artifact, confidence, or next action.
- In an intermediate update message to the user, highlight which material dependencies are available that you'll try to use.
- Aim for a balance of completeness and speed: broaden when the first pass is empty, thin, conflicting, or a decision depends on the missing evidence; stop once the artifact is grounded.
- If a material dependency category isn't available, or a material search returned no useful context, communicate the practical limitation to the user.

#### 3. First Output
- After sufficient context has been gathered, provide the user with an output
- Default to providing output in chat, but if the skill or user instruction prefers another output like html or a document, use that instead.
- Remember to identify the likely underlying user goal behind the request and try to address that, as well as satisfying their object-level request.
- Below are two common elements that should be used by default in all outputs.

##### Limitations and Improvements

The first output is "best effort" and tries to give the most useful response relative to the connectors and context available. In this output, you should give the user context on the strength of your answer and instruct how it can be improved through installing new connectors.

Details:
- Start with 1–2 sentences describing the answer’s strengths, grounding, and known gaps.
- For available connectors with no relevant evidence, mention what was checked and what was or wasn't found.
- For unresolved non-blocking categories, state the practical limitation and name a suitable provider as an optional improvement when one is available. Offer its install/connect UI only after the first output, normally in Next Steps.
- For unresolved blocking categories, report whether a provider was offered, no suitable provider was found, or the install/connect attempt failed or was declined. Mention the plugin-page, pasted/uploaded-context, or IT fallback only after no suitable installable provider was found or the install/connect attempt failed or was declined.

**Output Format**
```
## Confidence and Gaps

This brief provides a solid orientation from the invite and shared notes, but it does not yet capture prior-call decisions, unresolved commitments, or authoritative account and opportunity context.

Potentially helpful context:

1. **[Category]:** [Provider] is available to install and could add [specific missing evidence].
2. **[Category]:** No suitable installable provider was found, so [plugin-page, pasted/uploaded-context, or IT fallback] is the next path for [specific missing evidence].
```

##### 4. Next Steps
- *Always* offer one clear next step to help the user get more value and discover useful adjacent functionality.
- When the focused skill provides `Next Step Options`, choose the single most relevant transition from that list. Do not present the whole menu, offer an action already completed, or suggest an action that conflicts with the workflow's ownership or safety rules.
- When the focused skill does not provide options, use your judgment. Some common fallback options:
- Install new connectors if they could materially improve output quality
- Iterate on and improve the output
- Create a document, presentation, spreadsheet, or html report
- Draft response(s) in Slack or Email to help with next steps
- Take another action in a relevant tool
- Set up an automation to follow up or refresh the output in the future

**Output Format**

```
{other message outputs}

Anything you'd change, or would you like me to [single most relevant next step]?
```

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Included reference: plugins/sales/.app.json

OpenAI · MIT · SHA-256 2e0b948851ca58f13a16d96b7058129a166b3f873df6a803925f76167c4589f5

{
  "apps": {
    "slack": {
      "id": "REPLACE_WITH_SLACK_APP_OR_CONNECTOR_ID",
      "category": "Internal Messaging"
    },
    "microsoft_teams": {
      "id": "connector_246af0940da3457da0e751171dc1ce60",
      "category": "Internal Messaging"
    },
    "zoom": {
      "id": "REPLACE_WITH_ZOOM_APP_OR_CONNECTOR_ID",
      "category": "Meeting Transcripts"
    },
    "zoom-zra": {
      "id": "REPLACE_WITH_ZOOM_ZRA_APP_OR_CONNECTOR_ID",
      "category": "Meeting Transcripts"
    },
    "granola": {
      "id": "REPLACE_WITH_GRANOLA_APP_OR_CONNECTOR_ID",
      "category": "Meeting Transcripts"
    },
    "fireflies": {
      "id": "connector_6912075cb358819187346bcafb601db8",
      "category": "Meeting Transcripts"
    },
    "otter_ai": {
      "id": "REPLACE_WITH_OTTER_AI_APP_OR_CONNECTOR_ID",
      "category": "Meeting Transcripts"
    },
    "salesforce": {
      "id": "REPLACE_WITH_SALESFORCE_APP_OR_CONNECTOR_ID",
      "category": "CRM"
    },
    "hubspot": {
      "id": "REPLACE_WITH_HUBSPOT_APP_OR_CONNECTOR_ID",
      "category": "CRM"
    },
    "close": {
      "id": "REPLACE_WITH_CLOSE_APP_OR_CONNECTOR_ID",
      "category": "CRM"
    },
    "zoho": {
      "id": "connector_fd0f007550a242459d6dd1f923668769",
      "category": "CRM"
    },
    "pipedrive": {
      "id": "connector_36803b8cc4164d84aa3fbfc7ddb420e1",
      "category": "CRM"
    },
    "zoominfo": {
      "id": "REPLACE_WITH_ZOOMINFO_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "clay": {
      "id": "REPLACE_WITH_CLAY_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "hg_insights": {
      "id": "REPLACE_WITH_HG_INSIGHTS_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "rox": {
      "id": "REPLACE_WITH_ROX_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "apollo": {
      "id": "REPLACE_WITH_APOLLO_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "actively": {
      "id": "REPLACE_WITH_ACTIVELY_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "meticulate": {
      "id": "REPLACE_WITH_METICULATE_APP_OR_CONNECTOR_ID",
      "category": "Sales Intelligence"
    },
    "gmail": {
      "id": "connector_2128aebfecb84f64a069897515042a44",
      "category": "Email"
    },
    "outlook_email": {
      "id": "connector_4aaab2856305417b993eca9a216aaf6e",
      "category": "Email"
    },
    "outreach": {
      "id": "REPLACE_WITH_OUTREACH_APP_OR_CONNECTOR_ID",
      "category": "Email"
    },
    "notion": {
      "id": "REPLACE_WITH_NOTION_APP_OR_CONNECTOR_ID",
      "category": "Knowledge & Files"
    },
    "google_drive": {
      "id": "connector_5f3c8c41a1e54ad7a76272c89e2554fa",
      "category": "Knowledge & Files"
    },
    "microsoft_sharepoint": {
      "id": "connector_1e4f6a44acf14e3ca1d96672f8c945bc",
      "category": "Knowledge & Files"
    },
    "google_calendar": {
      "id": "connector_947e0d954944416db111db556030eea6",
      "category": "Calendar"
    },
    "outlook_calendar": {
      "id": "connector_e6a7394682e24467ac68c60696f275a4",
      "category": "Calendar"
    },
    "calendly": {
      "id": "REPLACE_WITH_CALENDLY_APP_OR_CONNECTOR_ID",
      "category": "Scheduling"
    },
    "monday": {
      "id": "connector_690aabb71bf481918b8d5b614ed3fd4c",
      "category": "Work Management"
    },
    "docusign": {
      "id": "REPLACE_WITH_DOCUSIGN_APP_OR_CONNECTOR_ID",
      "category": "Document Signing"
    }
  }
}

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Included reference: plugins/sales/skills/index/references/orientation-response.md

OpenAI · MIT · SHA-256 49633d76e668157fc5a8a07b6dc6dd7f47a4639ecd9a082ca6c5f66d9fe75c5a

Sales turns customer, company, conversation, and pipeline context into practical next steps. It can help you prepare for meetings, follow up after calls, research accounts, prioritize opportunities, build business cases, review pipeline risk, and find the right customer evidence or internal answers.

## Simpler Use Cases

These workflows usually work well with a basic set of connectors—and they also work if you paste in notes, a transcript, an account brief, or other relevant context.

| Use case | Sample prompt |
| --- | --- |
| Prepare for an important meeting | @Sales prepare me for my next customer meeting. Give me the context, likely blockers, desired outcomes, and questions I should ask. |
| Follow up after a customer call | @Sales turn these call notes into a recap, clear next steps, and a customer-ready follow-up email. |
| Research a company and draft outreach | @Sales research this company and suggest a relevant outreach angle, then draft a concise first message. |
| Find an internal answer for a customer | @Sales a customer asked about data residency. Find the best internal sources and draft the answer I should send. |

## More Advanced Use Cases

These workflows become more powerful with specialized connectors such as CRM, customer activity, data enrichment, or call recordings. If a needed source is not enabled, ask your admin to connect it.

| Use case | Sample prompt |
| --- | --- |
| Prioritize accounts | @Sales which accounts should I focus on this week? Rank them, explain why, and recommend the next move for each. |
| Understand what changed in an account | @Sales review my most important active account. Tell me what changed, what matters, and what I should do next. |
| Triage pipeline and forecast risk | @Sales review my open pipeline for this quarter. Rank deals likely to slip and recommend the next action for each. |
| Pull customer evidence from calls | @Sales find five verbatim customer quotes about setup friction from recent calls and summarize the pattern they show. |

Name a use case and I’ll tee up a personalized sample prompt to show it in action.

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Included reference: plugins/sales/skills/hubspot/SKILL.md

OpenAI · MIT · SHA-256 2a9571967ab27e1653d819cb89e496b96905437ed286d5a5ad7d7c41062c8f82

---
name: hubspot
description: Use only when a focused Sales workflow has selected a connected HubSpot CRM, or the user explicitly asks for HubSpot guidance, reads, drafts, notes, or reviewed record changes. Do not use when another CRM is authoritative.
---

# HubSpot User Guide

Prepare trustworthy HubSpot-backed context or a safely reviewed HubSpot action while keeping the surrounding Sales workflow authoritative for the business task.

## Common Skill Instructions

MANDATORY: If not already in context, read and adhere closely to plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices.

## HubSpot Operation Ranking

Use this priority order when the requested HubSpot job or record is ambiguous.

1. Explicit user request, named record, HubSpot ID, company, deal, contact, ticket, or stated action
2. Read-only CRM context needed by the active Sales workflow
3. Exact record or a high-confidence candidate resolved from the user's words and business context
4. The smallest property set, associations, activity context, or page of results that answers the request
5. A reviewed draft of proposed HubSpot changes
6. An explicitly approved, supported HubSpot write followed by verification

Do not silently pick among plausible records, broaden a read into a write, or treat clarification as write approval.

## Key Dependency Categories

These are particularly important for this workflow; use your best judgment to potentially include other data sources to improve quality.

- ~~CRM, specifically the exposed HubSpot connector, for HubSpot-backed identity, records, properties, associations, links, and approved writes
- The parent Sales workflow for Calendar, Meeting Transcripts, Email, Internal Messaging, Knowledge & Files, or Sales Intelligence context that HubSpot does not own
- User-provided record IDs, names, exports, property values, and business context when connector access is unavailable or a record needs disambiguation

If HubSpot is missing, unavailable, stale, ambiguous, or limited by the exposed connector surface, say so and label the answer as not HubSpot-backed.

## Workflow Guidance

These HubSpot-specific steps override the default workflow in the index skill.

- 1. Resolve access and target
- Use get_user_details first to confirm the connected portal and exposed object read/write availability.
- Resolve whether the user wants a read, a draft, or an approved write; identify object type, owner or team, pipeline, timeframe, stage, and exact record when those affect the answer.
- For an ambiguous record, do the smallest bounded candidate lookup and ask the user to choose before using it for a summary or write.
- 2. Discover properties and records
- Use search_properties with at most five focused keywords when fields are uncertain; use get_properties to confirm enum values and writable properties.
- Use search_crm_objects for search, counts, filters, pagination, and associations. Use get_crm_objects for known IDs. Do not use deprecated search or fetch.
- Retrieve only the properties and associations that affect the sales decision. State filters, totals, page or sample limits, and whether analysis is sampled.
- 3. Draft, approve, and verify
- For proposed changes, show an exact field-level draft before calling manage_crm_objects.
- Write only after the user explicitly approves the exact reviewed change or batch. Batch at most 10 objects and confirm associations separately.
- A reviewed-batch approval applies only to that exact batch; never offer a blanket confirmation bypass.
- Inspect the write response and verify with a narrow read when the response does not prove the outcome.

## HubSpot Rules

- Prefer exact IDs, domains, emails, and full names plus company over vague name-only matching.
- Before querying or writing with a property or enum, confirm property labels, internal names, enum values, and writeability; do not guess them.
- Keep HubSpot as CRM truth for HubSpot-owned account, contact, deal, ticket, owner, pipeline, and activity facts. Do not let enrichment or web context overwrite CRM truth.
- Include clickable connector-returned or trusted HubSpot record URLs with UTM parameters when available.
- Do not write inferred data, overwrite user-entered context without clear consent, or mutate an association without explicit approval.
- Do not imply support for objects, properties, pagination behavior, bulk sizes, or writes that the live connector does not expose.

## Connector Boundary

Use only the HubSpot surfaces that are actually exposed:

- Identity and access: get_user_details
- Property discovery: search_properties, get_properties
- Record search and reads: search_crm_objects, get_crm_objects
- Reviewed writes: manage_crm_objects

For unsupported broad exports, delete, merge, dedupe, arbitrary automation, or unexposed object operations, state the missing surface and offer a narrower read, a draft, or another approved source.

## Modes

### 1. HubSpot Read

- Use for company, deal, contact, ticket, owner, activity, property, or association context.
- Resolve the target, retrieve only decision-relevant fields, and call out ambiguity or gaps.

#### Output Format

# [HubSpot Record Or Context]

## Summary

- [Most important CRM fact with trusted link]
- [Current deal, company, contact, activity, or association signal]
- [Risk, missing property, ambiguity, or source gap]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

### 2. HubSpot Update Draft

- Use when the user asks to prepare a note, property change, association, create, or update but has not approved the write.
- Keep current and proposed values separate and identify the exact target.

#### Output Format

# Proposed HubSpot Update

**Target:** [Record name, type, and trusted link or ID]

| Property / Association | Current Value | Proposed Value | Reason / Source |
| --- | --- | --- | --- |
| [Label] | [Current or Unknown] | [Proposed] | [Grounded reason + link] |

## Before I Write

- [Missing input, association confirmation, validation risk, or approval needed]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

### 3. Approved HubSpot Write

- Use only after explicit approval for the exact reviewed object or batch.
- Verify before reporting completion when the write response is inconclusive.

#### Output Format

# HubSpot Updated

**Record:** [Name, type, and trusted link or ID]

- **Changed:** [Property or association]
- **Result:** [Verified outcome]
- **Not changed:** [Unsupported or skipped item]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Included reference: plugins/sales/skills/salesforce/SKILL.md

OpenAI · MIT · SHA-256 0640253e4a68d06f09522a7d275213d3c78b849439139d223d2f7b32a3e64a63

---
name: salesforce
description: Use when a focused Sales workflow needs Salesforce-backed CRM reads, links, drafts, notes, account plans, Agentforce assignments, or explicitly requested Salesforce connector/query guidance. Do not use for generic CRM app construction or when another CRM is authoritative.
---

# Salesforce User Guide

Prepare a sales person with trustworthy Salesforce context or a safely reviewed Salesforce action, while keeping the surrounding Sales workflow authoritative for the business task.

## Common Skill Instructions

MANDATORY: If not already in context, read and adhere closely to plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices.

## Salesforce Operation Ranking

Use this priority order when the requested Salesforce job or record is ambiguous.

1. Explicit user request, named record, Salesforce id, account, opportunity, contact, lead, or stated action
2. Read-only context that helps the active Sales workflow make a decision
3. Exact record or high-confidence candidate resolved from the user's words and business context
4. The smallest field set, activity history, account plan, event, or transcript context that answers the request
5. A reviewed draft of proposed Salesforce changes
6. An explicitly approved, supported Salesforce write followed by verification

Do not silently pick among plausible records, broaden a read into a write, or treat clarification answers as write approval.

## Key Dependency Categories

These are particularly important for this workflow; use your best judgment to potentially include other data sources to improve quality.

- ~~CRM, specifically the exposed Agentforce Sales/Salesforce connector, for Salesforce-backed reads, record links, account plans, transcript summaries, Agentforce Lead Nurturing assignments, and approved writes
- The parent Sales workflow for Calendar, Scheduling, Meeting Transcripts, Email, Internal Messaging, Knowledge & Files, or Sales Intelligence context that Salesforce does not own
- User-provided record ids, names, exports, field values, and business context when connector access is unavailable or a record needs disambiguation

Avoid unsupported claims. If Salesforce is missing, unavailable, stale, ambiguous, or limited by the exposed connector surface, state the limitation.

## Workflow Guidance

Adhere strictly to these workflow steps. These override the default workflow in the index skill.

- 1. Clarify and Gather Context
- Resolve the Salesforce task, target record, requested detail, and whether the user wants a read, draft, or approved write.
- For an ambiguous record, do the smallest exact or bounded candidate lookup, then ask the user to choose before using the record for a summary or write.
- 2. First draft
- Prefer read-only discovery and the smallest correct record read or query. Use labels in user-facing output and include clickable record links when a trusted URL is available.
- For proposed changes, render a reviewed field-level draft with assumptions, source gaps, and the exact approval still needed.
- 3. Approved action and verification
- Write only when the user explicitly asks for the write or approves the reviewed draft/update.
- Confirm the target record and supported fields before writing, send only intended changes, inspect the response, and verify with a narrow read when the response does not prove the outcome.

## Overall Rules

- Always cite sources using hyperlinks when useful links are available.
- Keep the parent workflow authoritative for the sales task; this guide owns Salesforce-specific lookup, query, links, account-plan actions, assignment, and write safety.
- Prefer discovery over guessing. Use exact ids or names first, then bounded candidates, then user choice when ambiguity remains.
- Do not imply support for connector surfaces that are not exposed.
- Do not delete, upsert by external id, call arbitrary automation, or execute a write without explicit approval.

## Connector Boundary

Use only the Agentforce Sales surfaces that are actually exposed:

- Metadata and identity: describe_global, describe_sobject, get_user_info
- Record lookup and reads: get_record_id_by_name, get_record_details, get_activity_history
- Querying: soql_query only
- Sales-specific reads: query_calendar_events, get_account_plan, query_agent_type, summarize_conversation_transcript
- Writes and mutating workflows: create_record, update_record, create_account_plan, assign_target_to_sdr

Do not imply support for SOSL, global text search, query continuation, Bulk API, Composite API, Data 360, Tableau Analytics, Prompt Builder, Flow invocation, arbitrary invocable actions, generic Apex REST, delete, or upsert-by-external-id. For unsupported cross-object keyword search, large exports, high-volume writes, delete/upsert, or analytics requests, state the missing surface and ask for a narrower object, field, exact identifier, or another approved tool.

## Salesforce Query And Write Rules

### Discovery And Reads

- Salesforce is required for Salesforce-backed reads, links, account plans, assignments, transcript summaries, and writes. If it cannot be used, label the answer as not Salesforce-backed.
- Use get_user_info for my, me, or current-owner requests. Use describe_global for uncertain objects and describe_sobject before non-obvious queries or writes.
- Confirm API names, labels, data type, filterability, createability, updateability, nullability, picklists, references, relationship names, and record types only when they affect the task.
- Do not guess relationship names. Treat broad wildcard matches as candidates, use business context to disambiguate, and ask before a summary or write if one targeted filter will not resolve the record.
- Use get_record_id_by_name when a name must become an id, get_record_details for presentation-ready layout context, get_activity_history for activity summaries, query_calendar_events for Salesforce Events, and get_account_plan for account strategy context.
- Resolve a specific VoiceCall or VideoCall id before summarize_conversation_transcript. If the call is unknown, query VoiceCall and VideoCall separately, then ask which call to summarize.

### Query Guardrails

- For non-trivial SOQL, identify the target object, needed fields, filters, sort or limit, display-versus-analysis purpose, and selectivity risk.
- Use the simplest correct query with only needed fields, include Id when rows may be linked or reused, add a reasonable LIMIT, and filter only on fields Salesforce reports as filterable.
- Do not send aggregate or grouped SOQL, including COUNT, SUM, GROUP BY, or aggregate aliases. Retrieve a bounded id-bearing set and summarize locally, or state that exact aggregate coverage is unavailable.
- Do not filter on long text, rich text, Task.Description, history OldValue/NewValue, IsPriorityRecord, or other readable-but-unfilterable fields. Bound by parent, date, owner, status, or another filterable field and post-filter locally when bounded.
- Use INCLUDES or EXCLUDES only for multipicklists. Scope FieldDefinition queries to a known entity, keep each OR disjunction scoped to one field, and split cross-field discovery before merging locally.
- Prefer standard Account, Opportunity, Contact, Task, and Event fields before optional or custom fields. After two focused schema or query-shape failures for the same fact, fall back to safer standard fields, exact reads, a narrower request, or a clear evidence gap.
- Distinguish explicit reauthentication errors from runtime readiness failures.

### Writes And Links

- For update_record, send only changed fields. For create_record, send only intended fields and include record type fields only when they affect defaults, picklists, or createability.
- Do not probe writes to discover validation rules. If Salesforce returns FIELD_CUSTOM_VALIDATION_EXCEPTION, surface the exact message and ask for the missing or corrected business value.
- Use create_account_plan instead of generic record creation for account plans. Resolve AccountId and gather or derive Name, challenge, competitive, relationship, strategy, StartDate, and Status first; report unsupported AccountPlan errors plainly.
- Before assign_target_to_sdr, call query_agent_type, present available agents, and get the user's selection. The target must be a Contact or Lead id.
- Inspect every write response and verify with returned fields, get_record_details, or a narrow soql_query when the response does not prove the outcome.
- Prefer a connector-returned record URL. If a trusted org or instance base URL is available, construct the Lightning record URL; otherwise show the object label and id instead of inventing a link.

## Modes

### 1. Salesforce Read

- Use when the user or a parent Sales workflow needs account, opportunity, contact, lead, activity, event, account-plan, or transcript context.
- Resolve the target first, retrieve only the fields and history that affect the sales decision, and call out gaps or ambiguity.

#### Output Format

```md
# [Record Or Salesforce Context]

## Summary

- [Most important CRM fact with source link]
- [Current account, opportunity, contact, activity, or plan signal]
- [Risk, missing field, ambiguity, or source gap]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}
```

### 2. Salesforce Update Draft

- Use when the user asks to prepare a CRM update, note, field change, or create action but has not yet approved the write.
- Keep proposed values separate from current values and identify the target record, assumptions, and required approval.

#### Output Format

```md
# Proposed Salesforce Update

**Target:** [Record name, type, and trusted link or id]

| Field | Current Value | Proposed Value | Reason / Source |
| --- | --- | --- | --- |
| [Field label] | [Current value or Unknown] | [Proposed value] | [Grounded reason + link] |

## Before I Write

- [Missing business input, validation risk, or approval needed]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}
```

### 3. Approved Salesforce Write

- Use only after the user explicitly asks for the supported write or approves the reviewed draft.
- Verify the result before reporting completion when the write response is not conclusive.

#### Output Format

```md
# Salesforce Updated

**Record:** [Record name, type, and trusted link or id]

- **Changed:** [Field or supported action]
- **Result:** [Verified outcome]
- **Not changed:** [Any requested item that was unsupported or skipped]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}
```

### 4. Account Plan, SDR Assignment, Or Transcript

- Use when the user explicitly asks for an account plan, Agentforce Lead Nurturing assignment, Salesforce event, or voice/video transcript summary.
- Resolve the required record or call id first. For an SDR assignment, show available agents and get the user's selection before assigning.

#### Output Format

```md
# [Account Plan / SDR Assignment / Transcript Summary]

## Target

- [Resolved account, contact, lead, event, or call + trusted link]

## Result

- [Supported read, draft, or verified action]
- [Important limitation or missing required input]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}
```

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Included reference: plugins/sales/skills/apollo/SKILL.md

OpenAI · MIT · SHA-256 11fc2423543596fa1203b1d27fb45f08075cf2c473ed9a3bc66b2f87eb665263

---
name: apollo
description: Use only when a focused Sales workflow has selected a present and connected Apollo connector, or the user explicitly asks for Apollo prospecting, enrichment, Company Details, records, sequences, or outbound planning. Apply Apollo v2-specific behavior only after verifying app version 2.0.0 or later.
---

# Apollo User Guide

Use Apollo for focused Sales Intelligence work after the parent Sales workflow selects it. Keep the parent workflow authoritative for the seller's task; this guide owns Apollo-specific version, credit, identifier, mutation, and outbound safety rules.

## Common Skill Instructions

MANDATORY: If not already in context, read and adhere closely to plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices.

## Apollo Version Gate

This guide's v2-specific behavior applies only when Apollo app version >= 2.0.0 is verified from visible app metadata, platform context, or explicit v2-only surfaces.

- V2-only evidence includes exposed company-search or Company Details preview wrappers, bulk account or contact create-update, sequence create-update, schedule lookup, campaign or sequence approval, or standalone Apollo usage-stats credit tooling.
- Generic People Search, Contact Search, Organization Search, enrichment, email account lookup, single-record create-update, sequence search, add/remove sequence contacts, job postings, or analytics do not prove v2.
- If version is unknown, unavailable, or below 2.0.0, do not apply v2-only assumptions or call v2-only mutations, enrollment, activation, or v2-only credit-consuming flows. Generic enrichment can still proceed under the normal Apollo-credit approval rules; otherwise explain the limitation.

## Apollo Operation Ranking

1. Explicit user request, named company or person, domain, email, Apollo ID, sequence, or stated action
2. The narrowest read-only lane needed by the active Sales workflow
3. Strong identifier resolution and a compact candidate preview
4. Search and shortlist before credit-consuming enrichment or Company Details
5. A reviewed mutation or launch preview
6. An explicitly approved exact action followed by verification

Never turn a draft, search, clarification, or general approval into a mutation, enrollment, activation, or send.

## Key Dependency Categories

These are particularly important for this workflow; use your best judgment to potentially include other data sources to improve quality.

- ~~Sales Intelligence, specifically a present and connected Apollo connector, for Apollo prospecting, enrichment, Company Details, records, and sequence planning
- ~~CRM for customer status, opportunity facts, ownership, and forecast truth
- The parent Sales workflow for Email, Calendar, Meeting Transcripts, Internal Messaging, or Knowledge & Files context
- User-provided names, domains, emails, IDs, ICP constraints, sequence intent, and approval when connector context is incomplete

If Apollo is missing, unavailable, ambiguous, version-limited, or unsupported by the exposed surface, state the limitation.

## Connector Boundary

Choose the narrowest Apollo lane that fits the request. Use the live Apollo tool schema; do not invent replacement tools when a named action is unavailable.

- Identity and Apollo credit awareness: user profile and credit usage reads.
- Discovery: People Search, Contact Search, Organization Search, existing sequence search, and email account lookup.
- Company Details and enrichment: organization enrichment, bulk organization enrichment, people enrichment, bulk people enrichment, and organization job postings when exposed.
- Account/contact records: account create-update, contact create-update, and bulk account/contact create-update when exposed.
- Sequences and launch: sequence search, sequence create-update when exposed, schedule lookup when exposed, sender account lookup, sequence approval or activation when exposed, add contacts to sequence, and remove or stop contacts from sequences.
- Analytics: read-only Apollo sales analytics reports when relevant.

Do not present Apollo as CRM ground truth. Apollo can support prospecting, enrichment, contactability, account/contact record preparation, and outbound sequence work; CRM-owned customer status, opportunity facts, ownership, and forecast truth should still come from ~~CRM when available.

## Credit-Aware Behavior

Say "Apollo credit," not "API credit."

Before broad, open-ended, or credit-consuming Apollo work, make the scope and likely Apollo credit exposure visible and get explicit approval. Credit-consuming actions commonly include Company Search, Organization Search, Company Details or organization enrichment, people enrichment, bulk enrichment, job postings, and any other Apollo tool whose live description says it consumes credits.

Use free or lower-cost narrowing steps first when practical:

1. Search or resolve the working set.
2. Show a compact preview of the candidates, filters, and count.
3. Ask for approval before credit-consuming enrichment or Company Details.
4. Enrich only the selected or materially useful rows.

Do not add unnecessary friction for a small, clearly requested lookup when the live tool policy already permits it, but still mention Apollo credit use when the action consumes meaningful credits.

## Search And Resolution

### People And Contacts

- Use People Search for net-new prospects in Apollo's database. It should not be treated as returning raw email addresses or phone numbers unless the live tool response explicitly does so and the user has asked for contactability.
- Use Contact Search for contacts already added to the team's Apollo account.
- Combine title, seniority, company/domain, location, technology, company size, and revenue filters when they improve precision.
- If the user's persona phrase is ambiguous, state one concise assumption instead of stopping.
- For broad role families, prefer one well-scoped search with combined title variants when the schema supports it; split only when the first pass is sparse or off-target.
- Do not infer missing emails, phone numbers, LinkedIn profiles, or confidence scores.

### Companies

- Prefer domains, Apollo organization IDs, or exact company names plus location/industry when resolving companies.
- For company-only discovery, preview the filters and possible Apollo credit exposure before running a credit-consuming company search.
- Keep company-only results company-only: do not add people columns, contactability labels, or outreach actions unless the user separately asks for contacts.
- If name-only rows are ambiguous, leave them unresolved or ask for domains rather than guessing.

### Identifiers

Use Apollo-returned IDs internally when a downstream Apollo action requires them. Do not fabricate account IDs, contact IDs, organization IDs, person IDs, sequence IDs, sender account IDs, schedule IDs, preview keys, or confirmation flags.

Do not expose internal IDs in ordinary seller-facing output unless the user is explicitly debugging an Apollo integration, validating connector behavior, or preparing an admin handoff that needs exact identifiers.

## Enrichment And Company Details

Use Company Details language for Apollo organization enrichment when it produces firmographic context such as employees, industry, location, description, funding, revenue, corporate phone, or related company facts.

For People to Company Details:

1. Convert the seller's ICP into focused people filters.
2. Run the appropriate people or contact search.
3. Show the people table first.
4. Offer Company Details as the next step.
5. Preview the selected company domains or organizations and Apollo credit exposure.
6. Ask for explicit approval.
7. After approval, run Company Details and show the combined table.

For people enrichment:

- Prefer the strongest available identifiers: Apollo person ID, business email, LinkedIn URL, domain plus name, or company plus name.
- Bulk people enrichment should stay within the live tool's batch size and should be limited to the rows the user needs.
- Keep `reveal_personal_emails` false by default. Use any personal-email or phone reveal option only when the user explicitly asks, the live tool policy supports it, and the action is lawful and appropriate for legitimate B2B work.

## Mutations

Account/contact create-update tools are mutation-risk tools. Use them only after a reviewed preview and explicit confirmation.

Before account/contact creates:

- Normalize the proposed records.
- Show key fields and the intended action.
- Warn that Apollo may create duplicates when dedupe is not supported or not enabled.
- Use dedupe options when the live tool supports them unless the user explicitly asks not to.

Before account/contact updates:

- Require verified existing Apollo account/contact IDs from prior tool results or clear user-provided IDs.
- Show a field-level before/after diff.
- Send only intended changed fields.
- Never use create/update tools for search, preview, analysis, or draft-only requests.

If bulk account/contact tools are exposed, apply the same preview, duplicate-risk, ID, and confirmation gates to the full batch. Do not split a risky batch into multiple mutations to bypass review.

## Sequences And Launch

Separate drafting, creation/update, enrollment, activation, and sending. Never bundle launch-risk actions together.

Ordinary seller-safe sequence work may include:

- Searching existing sequences by name or audience.
- Reviewing or drafting sequence content in chat.
- Looking up sender accounts for planning.
- Inspecting schedules when a read-only schedule lookup is exposed.

Mutation or launch-risk sequence work requires explicit approval after a preview or diff:

- Sequence creation or update, when exposed, requires a reviewed payload. Default new sequences to inactive when the live schema supports an active flag.
- Sequence update requires a verified existing sequence ID, current state, a clear diff, and explicit confirmation.
- Sequence approval, activation, or campaign approval is critical launch risk and requires a separate explicit confirmation. Never activate by default.
- Adding contacts to a sequence can send real emails. First search and disambiguate the sequence, retrieve valid sender email accounts, show the sender, sequence name, number of contacts, and active/paused enrollment status, then wait for explicit confirmation before enrolling.
- Removing or stopping contacts from sequences requires verified contact IDs, verified sequence IDs, the mode, and confirmation. For stop actions, capture the stop reason when the live schema requires or benefits from it.

Do not enroll contacts, activate sequences, approve campaigns, or start sending unless the user has approved that exact reviewed action and the live Apollo surface supports it.

## Safety Rules

- No raw personal email or phone reveal by default.
- No Apollo credit-consuming Company Search, Organization Search, Company Details, people enrichment, organization enrichment, bulk enrichment, or job-posting lookup without making Apollo credit exposure visible and getting approval when the action is broad, batch, Company Details, or otherwise material.
- No account/contact mutation without preview and explicit approval.
- No sequence creation, update, activation, approval, enrollment, removal, stopping, or sending without the relevant reviewed workflow gate.
- No generic "high Buying Intent" claims unless Apollo returns a supported intent or signal field that matches the user's requested concept.
- No production-readiness claims from local, mock, prototype, or simulation evidence.
- Preserve safe partial work when a request is blocked: show the search, preview, draft, diff, or planning step that can be done safely.

## Output Rules

Use seller language:

- Say "Company Details," not "account context."
- Say "Apollo credit," not "API credit."
- Say "sequence draft," "inactive sequence," "reviewed diff," "enrollment confirmation," or "activation confirmation" precisely.

Prefer compact tables:

- People Search: First, Last, Title, Company, Domain, Location, Email Availability, Phone Availability.
- People plus Company Details: First, Last, Title, Company, Domain, Employees, Industry, Location, Description, Email Availability, Phone Availability.
- Company Search or company-only: Company, Domain, Employees, Industry, Location, Description.
- Existing sequences: Name, Active, Archived, Steps, Max Emails Per Day.
- Sender accounts: Sender Account, Active, Verified, Warmup.
- Batch preview: Record, Key Fields, Risk, Action.
- Batch update diff: ID Source, Record, Field, Current, Proposed.

Prefer clickable connector-returned links when available; never construct guessed links from opaque IDs.
Keep sourced facts separate from `Inference:`. If a requested row or field is not returned, say so instead of filling it in.

Avoid raw tool names in seller-facing prose unless the user is explicitly discussing connector validation, evals, implementation, or admin troubleshooting.

#### Output Format

# [Apollo Search / Company Details / Sequence Plan]

## Results

| Company / Person / Sequence | Key Evidence | Useful Detail | Status |
| --- | --- | --- | --- |
| [Result] | [Returned signal] | [Returned field] | [Qualified, Near, Draft, or Needs approval] |

## Before Any Action

- [Credit exposure, ambiguity, reviewed diff, sender/enrollment gate, or exact approval needed]

## Gaps / Limitations

- [Missing field, version gate, connector surface, or source limitation]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Included reference: plugins/sales/skills/zoominfo/SKILL.md

OpenAI · MIT · SHA-256 b5fce52852fb593dfbd1e74e85cc940e58569d22a77a2365f13bd7e875b32dcf

---
name: zoominfo
description: Use only when a focused Sales workflow has selected a present and connected ZoomInfo connector, or the user explicitly asks for ZoomInfo company search, contact search, enrichment, intent, similarity, recommendations, or research. Do not use when another enrichment source is selected.
---

# ZoomInfo User Guide

Use ZoomInfo for focused Sales Intelligence work after the parent Sales workflow selects it. Keep the parent workflow authoritative for the seller's task; this guide owns ZoomInfo-specific lookup, search, identity, enrichment, credit, and result-quality rules.

## Common Skill Instructions

MANDATORY: If not already in context, read and adhere closely to plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices.

## ZoomInfo Operation Ranking

1. Explicit user request, named company or person, domain, email, ZoomInfo ID, or stated constraint
2. The narrowest ZoomInfo lane needed by the active Sales workflow
3. Canonical company or contact identity resolved from strong identifiers
4. Search and shortlist before enrichment, research, similarity, or recommendations
5. The smallest credit-consuming step that materially improves the answer
6. A result that clearly separates qualified matches, near matches, and gaps

Do not silently relax hard filters, guess identities, or present ZoomInfo as CRM ground truth.

## Key Dependency Categories

These are particularly important for this workflow; use your best judgment to potentially include other data sources to improve quality.

- ~~Sales Intelligence, specifically a present and connected ZoomInfo connector, for ZoomInfo search, enrichment, intent, similarity, recommendations, and research
- ~~CRM for account ownership, customer status, opportunity facts, and forecast truth
- The parent Sales workflow for Calendar, Meeting Transcripts, Email, Internal Messaging, or Knowledge & Files context
- User-provided names, domains, emails, IDs, ICP constraints, and business context when connector access or identity is incomplete

If ZoomInfo is missing, unavailable, ambiguous, or limited by the exposed connector surface, state the limitation instead of substituting unsupported claims.

## Connector Boundary

ZoomInfo supports several distinct lanes. Choose the narrowest lane that fits the request.

- Discovery: `lookup`, `search_companies`, `search_contacts`, `search_intent`
- Structured enrichment: `enrich_companies`, `enrich_contacts`, `enrich_intent`
- Narrative research: `account_research`, `contact_research`
- Similarity and recommendation: `find_similar_companies`, `find_similar_contacts`, `get_recommended_contacts`
- Connector feedback only when the user asks for it: `submit_feedback`

Do not blur these lanes:

- Use `search_*` to discover candidates.
- Use `enrich_*` when the user wants stronger structured fields or a verified detail check.
- Use `account_research` or `contact_research` when the user wants a narrative brief, meeting prep, or broader situational readout.
- Use similarity or recommendation actions for "more like this", account expansion, or stakeholder discovery, not as a substitute for precise search filters.

Do not present ZoomInfo as CRM ground truth. If a research response includes relationship or engagement context, label it as connector-surfaced context unless it is independently grounded by ~~CRM or the surrounding workflow.

## Default Resolution Pattern

Run these steps in order.

1. Classify the target:
- company set
- contact set
- one known company
- one known person
- buyer intent topic
- lookalike or recommendation request
2. Normalize hard filters before searching:
- geography
- management level
- department or job family
- employee or revenue bands
- industry or company type
- technology filters
- intent topics
3. Use `lookup` before search or intent flows whenever the connector expects standardized values.
4. Resolve canonical company or contact identity before enrichment, research, or recommendation actions that depend on IDs.
5. Verify that returned rows actually satisfy the user's hard constraints before summarizing them as matches.
6. State what was not found, weakly supported, or connector-limited instead of smoothing gaps away.

## Lookup Discipline

Use `lookup` to retrieve supported values instead of guessing connector-specific categories.

- Use it for `management-levels`, `metro-regions`, `industries`, `employee-count`, `departments`, `job-functions`, `company-types`, `revenue-ranges`, `tech-vendors`, `tech-products`, and `intent-topics` when those constraints matter.
- Use the standardized identifier returned by `lookup` where the downstream action expects an identifier, not a prettified display label.
- For technology-stack searches, resolve the vendor first, then resolve products for that exact vendor, then pass the returned product identifiers into search.
- For intent workflows, retrieve exact supported intent topics first. If the requested concept does not map cleanly to a supported topic, present the closest supported topic only when it is genuinely close; otherwise say the request is not precisely expressible through the current topic taxonomy.

Do not invent lookup values or silently swap in an adjacent category without saying so.

## Identifier Resolution

Resolve entities carefully before ID-dependent actions.

### Companies

- Prefer `companyId`, domain, website, or ticker over company name alone.
- If the user provides only a company name and the next step requires enrichment, research, or a target-company ID, first use `search_companies` to find the canonical company row when identity is not obvious.
- If multiple plausible companies remain, use domain, headquarters, industry, or the user's surrounding context to disambiguate. If ambiguity still matters, present the candidate set instead of picking one quietly.
- For company enrichment, prefer `companyId`, `domain`, or `companyWebsite` over vague name-only input when available.

### Contacts

- Prefer `personId`, business email, or an exact full-name-plus-company combination over a name alone.
- If the user asks for contact research, similar contacts, or another person-ID-dependent workflow from a name, first use `search_contacts` to resolve the target person.
- If the same name maps to multiple plausible people, keep the candidate list explicit and do not fabricate a single match.
- For contact enrichment, use the strongest supported identifier available; avoid broad name-only enrichment when a search pass can make the identity less ambiguous.

### Runtime Shape

- Pass connector-returned identifiers in the runtime-compatible primitive shape the action accepts.
- When the connector surfaces a numeric ZoomInfo identifier and the destination action requires a numeric identifier at runtime, preserve it as numeric rather than rewriting it into prose or guessing a new value.
- If an action rejects an apparently valid identifier shape, retry only once with the directly corresponding connector-returned primitive when the target is unambiguous. If that still fails, report a connector contract mismatch and continue only with lower-risk available evidence.

## Search Discipline

### Company Search

- Translate the user's ICP into explicit filters before searching.
- Prefer structured filters for geography, headcount, revenue, company type, funding, growth, and tech usage when the connector supports them.
- If the user asks for "US companies", "California companies", or another hard geography requirement, verify that each surfaced result matches the requested region before calling it a qualified match.
- If search returns close but imperfect rows, separate `Matches` from `Near Matches` rather than hiding the distinction.
- Do not claim exhaustive market coverage from a bounded result page.

### Contact Search

- Use management level, department, function, company, and title filters together when that improves precision.
- For role-family requests such as "VP, Director, or Head of RevOps", start with the narrowest structured interpretation that is likely to work.
- If a single broad title query returns sparse, clearly incomplete, or off-target results, split the role family into a small number of targeted searches, merge duplicates, and summarize the deduped shortlist.
- Prefer directly returned business fields. Do not infer private email addresses, personal phones, or missing professional profiles.

### Intent Search

- Always resolve exact intent topics with `lookup` before `search_intent` or `enrich_intent`.
- Keep topic meaning visible in the answer so the user can see what was actually searched.
- If returned intent topics are materially narrower, broader, or adjacent to the user's concept, say so.
- If the topic lookup or search path cannot support the requested concept faithfully, report that limitation instead of overstating the result.

## Enrichment And Research Sequencing

Use cheap narrowing steps before expensive or less precise actions when practical.

- Use search first when the entity itself is unclear.
- Use structured enrichment when the user wants firmographic fields, contactability fields, or batch-ready tabular output.
- Use narrative research when the user wants a briefing, situational awareness, or prepare-for-meeting style synthesis.
- For top-N discovery requests, do not enrich every raw candidate by default. Narrow first, then enrich only the shortlisted set that materially improves the answer.
- When a similarity or recommendation workflow returns sparse person or company detail, add a targeted enrichment pass only when the user asked for actionable detail or when the surrounding workflow needs it.

## Similarity And Recommendation Flows

### Similar Companies

- Use `find_similar_companies` when the user asks for competitor-like, lookalike, or adjacent-account discovery.
- If the reference company is ambiguous, resolve it before the similarity call.
- If the user wants a usable market list rather than raw similarity results, enrich the final shortlist just enough to supply requested basics such as website, location, employee range, or a concise description.

### Similar Contacts

- Resolve `referencePersonId` with `search_contacts` when the user gives a name.
- Resolve `targetCompanyId` with `search_companies` when the user wants lookalike contacts inside a specific account.
- Explain recommendations using returned metadata rather than making up a similarity rationale.

### Recommended Contacts

- Resolve the target company first.
- Choose the recommendation use case that matches the user intent:
- `PROSPECTING`
- `DEAL_ACCELERATION`
- `RENEWAL_AND_GROWTH`
- Explain what the use case means in the final readout when it affects interpretation.
- Treat recommendation scores as ranking signals, not response probabilities or guaranteed success.

## Credit-Aware Behavior

Prefer free or lower-cost discovery steps before credit-consuming enrichment or AI research when the workflow permits it.

- Use `lookup`, `search_companies`, `search_contacts`, and `search_intent` to narrow scope first when appropriate.
- Use `enrich_companies`, `enrich_contacts`, `enrich_intent`, `account_research`, and `contact_research` when the user has asked for the stronger result those actions provide.
- For broad batch requests, make the action scope visible in the answer and avoid unnecessary enrichment of obviously weak candidates.

Do not add friction for a small, clearly requested enrichment task. Do be explicit when the connector result may have consumed meaningful credits or when a narrower rerun would be materially cheaper.

## Failure Handling

- If the connector returns no results, say `no clear ZoomInfo match returned` rather than inventing one.
- If results violate a hard filter, exclude them from the qualified set and mention the mismatch.
- If a required lookup value is unavailable, say which constraint could not be represented cleanly.
- If a research response is thin or generic, preserve the useful parts but label coverage as limited.
- If a recommendation or similarity call yields weak actionability, say what extra enrichment or user context would be needed.
- If the connector behavior appears inconsistent with its own action contract, describe the inconsistency plainly in the answer when it affects completeness or confidence.

## Output Rules

- Prefer compact tables for candidate lists, enrichment outputs, similar-company lists, and contact recommendations.
- Prefer clickable connector-returned links when available; never construct guessed links from opaque IDs.
- Separate:
- `Qualified matches`
- `Near matches` when useful
- `Gaps / connector limitations`
- Keep sourced facts separate from `Inference:`.
- Do not guess emails, phone numbers, exact intent, or confidence levels not surfaced by the connector.
- When the answer depends on connector-reported fields or recommendation metadata, say so directly.
- If the user's request asked for a ranked list, rank by explicit connector signal or stated criteria, not by invisible model preference.

#### Output Format

# [ZoomInfo Search / Enrichment / Research]

## Qualified Matches

| Company / Person | Key Match Evidence | Useful Detail | Source |
| --- | --- | --- | --- |
| [Result] | [Hard filters satisfied] | [Returned field] | [Link or connector source] |

## Near Matches

- [Result + exact mismatch, when useful]

## Gaps / Connector Limitations

- [Missing field, unsupported filter, bounded coverage, ambiguity, or credit-aware next step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Original license & copyright

MIT License

Copyright (c) 2026 OpenAI

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Source SHA-256: c2127a18a4f1c5d36f6bc72fe2ac30878286f809878ad0240ec8dc39f3578c74
Snapshot checked: 2026-09-28T12:16:34.393744+00:00

Find a skill.Get to work.

All skills

Multi-Agent Orchestration

AI Context Window Audit

AI Agent Architecture Audit

AI Skill Discovery

Lead Magnet Strategy

Ideal Customer Profile

Go-to-Market Strategy

Marketing Campaign Ideas

Product Growth Loops

Competitor Analysis

North Star Metric

Product Positioning

Product Vision

Go-to-Market Motion Selection

Customer Feedback and JTBD Analysis

PESTLE Market Environment Analysis

Customer Journey Mapping

Ansoff Growth Options

Data Analysis Validation

Dataset Profiling

Statistical Analysis Guidance

Programmatic SEO Planning

Landing Page and Form Conversion Review

Paywall and Upgrade Planning

Signup and Registration Review

User Onboarding and Activation

Popup and Modal Planning

Lifecycle Email Sequence Planning

Marketing Campaign Planning

Marketing Content Drafting

Brand Voice and Content Review

Marketing Performance Reporting