本文へ移動
cccskills
無料GitHub で公開日本語紹介

hubspot

HubSpot CRMから商談、会社、担当者、チケットなどを検索し、案件の状況や顧客との関連情報を調べます。接続状態の確認や、条件を指定した集計にも対応します。

原文原文の説明を見る

Query HubSpot CRM for deals, companies, contacts, tickets, owners, and account/deal context. Use when the user asks for HubSpot data or connection status.

BuilderIO/agent-nativeスター 7,519(GitHub 7,519 + cccskills 0)
連携ツールHubSpot

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 商談の状況や担当者を確認したいとき
  • 企業や担当者の関連情報を調べたいとき
  • 条件を指定して案件群を集計したいとき
  • 失注の複数要因を整理したいとき

日本語での紹介

できること

HubSpot CRMの商談、会社、担当者、チケット、担当者情報やパイプライン指標を調べます。特定の会社や案件について、関連する会社・担当者・チケット・メモ・メールを集め、顧客や商談の状況を把握できます。商談群を分析するときは、商品、パイプライン、成約状況、日付などの条件を指定します。標準アクションで扱えない項目やAPI機能は、HubSpotのAPIを使って照会します。

こんなときに便利

営業担当者や案件の状況を確認したいとき、企業や担当者のCRM情報を補いたいときに向いています。特定期間にステージへ進んだ商談を数える場合は、ステージに入った日時の項目を使って条件を明確にできます。失注分析では複数の要因を整理できます。

使い方の例

  • 「この会社の商談、担当者、関連チケットを調べてください」
  • 「指定したパイプラインで、過去12か月に成約した案件を集計してください」

注意点

接続が不明な場合は接続状態を確認します。倉庫に複製されたHubSpotデータは、利用者が指定した場合などを除き、ライブCRMの代わりに使いません。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(1)

  • SKILL.md7.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

HubSpot

Use HubSpot for CRM facts: deal status, amount, stage, owner, forecast, associated account context, contacts, companies, and tickets.

Analytics' HubSpot actions use its native provider credential or granted workspace connection. A missing optional HubSpot MCP server does not mean HubSpot is disconnected. Never send the user to HubSpot MCP setup to answer an Analytics data question. If availability is unclear, call data-source-status with key: "hubspot"; when it reports HubSpot configured, run the native HubSpot action directly.

hubspot-deals is a legacy-named deal analytics shortcut, not the boundary of the HubSpot integration. If the user asks for any HubSpot object, endpoint, association, property, filter, batch read/write, or API version that the typed actions do not expose, inspect the provider catalog/docs and call provider-api-request with provider: "hubspot".

Actions

  • account-deep-dive — first choice for the CRM side of a named account/deal deep dive (use run-gong-native-insight for what was said in calls). It searches matching HubSpot deals, loads associated companies, contacts, tickets, notes, and emails, then pairs that CRM context with Gong evidence.
  • hubspot-deals — deals with normalized stage, pipeline, owner, forecast, and NBM fields. For a named customer/deal/account, pass query; do not fetch all deals first. For a deal cohort, use structured filters such as product, pipeline, closedStatus, closedDateFrom, and closedDateTo.
  • hubspot-records — generic HubSpot search/list for contacts, companies, deals, and tickets. Use this to enrich a deep dive with company, contact, or ticket records.
  • hubspot-pipelines / hubspot-metrics — pipeline definitions and aggregate sales metrics.
  • For HubSpot property metadata (available fields before requesting custom ones), prefer the metadata cached internally by hubspot-records when the needed field names are already known. If field discovery needs the properties endpoint, call provider-api-request (provider hubspot, e.g. /crm/v3/properties/deals) via provider-api-docs without stageAs. Property definitions are read-only control metadata, not analysis rows; never stage them. stageAs writes result rows to staged-dataset storage, which has a per-user quota and an app-wide limit. Going over either removes the least recently written datasets (the user's own for the per-user quota, any user's for the app-wide limit), and a write too large to fit even then fails. Do not clear existing staged datasets to make room. If a metadata request cannot be read without staging, narrow the request or return only the required property names, labels, and types through a read-only path.
  • provider-api-request with provider: "hubspot" — arbitrary HubSpot HTTP API calls when first-class actions are too narrow.

Pipeline Stage Timing — Use Stage-Entry Date Fields

Always use hs_v2_date_entered_{stageId} for deterministic pipeline-stage timing, not keyword or amount heuristics:

  • Each pipeline stage has a unique numeric ID (visible in pipeline definitions).
  • The property hs_v2_date_entered_{stageId} records the exact timestamp when the deal first entered that stage. Use this to filter deals that reached a specific stage within a date window.
  • Why this matters: heuristic filters (e.g., amount > $30K, keyword searches) have been found to diverge from stage-date filters by ~48% — nearly half the deals are different. Stage-entry date fields provide verifiable, auditable results.

To discover stage IDs, call hubspot-pipelines first and read the stageId fields in the returned pipeline structure.

Example use: to count deals that reached "Qualified Opportunity" stage in Q1:

provider-api-request(
  provider: "hubspot",
  path: "/crm/v3/objects/deals/search",
  method: "POST",
  body: {
    "filterGroups": [{
      "filters": [{
        "propertyName": "hs_v2_date_entered_<stageId>",
        "operator": "BETWEEN",
        "value": "2026-01-01",
        "highValue": "2026-03-31"
      }]
    }],
    "properties": ["dealname", "amount", "hs_v2_date_entered_<stageId>"]
  }
)

Multi-Dimensional Closed-Lost Analysis

Deals are rarely lost for a single reason. When analyzing closed-lost deals:

  • Use a multi-factor matrix with notation: primary factor (★★), contributing factor (★), possible factor (~).
  • Track 8-10 common loss factors per deal: Budget, Product Fit, Implementation Friction, Competitive Loss, Security/Compliance, Wrong Persona/Champion, Timeline Mismatch, Support/Success Gaps, etc.
  • Identify combination patterns — e.g., "Product Fit + Implementation Friction" may affect multiple deals simultaneously.
  • Do not force a single root cause categorization. Real losses are multi-dimensional, and flattening to one reason distorts win/loss patterns.
  • Report both the count of deals per single factor AND the top multi-factor combinations.

Patterns

For account or deal deep dives:

  1. Call data-source-status if you are not sure HubSpot is connected.
  2. Call account-deep-dive with query set to the company, domain, deal, or opportunity name. Use its associated companies, contacts, tickets, notes, and emails as the CRM backbone of the answer.
  3. If a specific CRM gap remains, call hubspot-deals or hubspot-records with bounded filters for that missing object only.
  4. Cite which records you inspected and keep unsupported associations as caveats.

Example:

account-deep-dive(query: "The Knot", days: 180, gongLimit: 10, transcriptLimit: 5)
hubspot-deals(query: "The Knot", limit: 10)
hubspot-records(objectType: "companies", query: "theknot.com", limit: 5)
hubspot-records(objectType: "contacts", query: "theknot.com", limit: 25)

Do not use warehouse copies of HubSpot as a substitute unless the user asks for the warehouse data or the live HubSpot action is unavailable and the user chooses that fallback.

For deal cohorts:

  1. Translate the cohort definition into structured hubspot-deals filters. Example: "new business deals where products field is Publish, closed won in the last 12 months" means product: "Publish", pipeline: "New Business", closedStatus: "won", and explicit close-date bounds.
  2. Do not use query for property-specific filters. query: "Publish" is a broad HubSpot search across deal text and can include unrelated deals.
  3. Report the cohort count, filters, and date window before synthesizing. If the count looks too low, inspect deal property metadata (/crm/v3/properties/deals) or use stage-entry date fields via provider-api-request.
  4. When pairing a cohort with Gong, use returned deal/company/contact evidence to run bounded Gong follow-ups and state Gong coverage separately from the HubSpot cohort size.

If hubspot-deals still cannot express the needed HubSpot query, do not stop or approximate. Call provider-api-catalog(provider: "hubspot"), fetch the HubSpot docs/spec with provider-api-docs if needed, then call provider-api-request(provider: "hubspot", ...) with the exact CRM endpoint, filters, properties, associations, and pagination body.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

a2a-assets

無料概要あり

複数のアプリやMCPホストからブランド画像・動画を生成、調整、書き出し、挿入する作業を支援します。ライブラリ選択や修正依頼も扱います。

  • スライド用のブランド画像を作りたいとき
  • 既存素材をフィードバックに合わせて直したいとき
  • 動画素材を生成して書き出したいとき
BuilderIO/agent-native7,5192026年10月26日 更新

account-health

無料概要あり

特定の顧客企業について、契約と製品利用の数値を照らし合わせ、根拠や不足情報を明記した健全性レポートをまとめます。

  • 顧客の健全性を確認したいとき
  • 契約席数と実利用を比べたいとき
  • 更新前に利用状況を整理したいとき
BuilderIO/agent-native7,5192026年10月26日 更新

actions

無料概要あり

アプリの操作をエージェントと画面の両方から呼び出せるアクションとして実装し、API連携や画面のデータ取得を一貫した形で追加するスキルです。

  • 新しいアプリ操作を追加したいとき
  • 外部APIと連携したいとき
  • 画面からデータを取得したいとき
BuilderIO/agent-native7,5192026年10月26日 更新

adding-a-feature

無料概要あり

新機能をUI・エージェント用アクション・説明資料・画面状態の4領域でそろえ、利用者とエージェントのどちらからも一貫して使えるようにするチェックリストです。

  • 新機能追加の作業範囲を整理したいとき
  • UIとエージェント操作をそろえたいとき
  • 画面状態の同期漏れを防ぎたいとき
BuilderIO/agent-native7,5192026年10月26日 更新

adhoc-analysis

無料概要あり

複数のデータソースを照合して、傾向や指標、根拠をまとめた分析結果を作成します。必要に応じて、再実行できるダッシュボードとして保存できます。

  • 商談と通話記録を照合したいとき
  • 顧客の利用状況を横断して調べたいとき
  • 繰り返し更新できる分析を保存したいとき
BuilderIO/agent-native7,5192026年10月26日 更新

admin-surfaces

無料概要あり

Analyticsの管理画面で、機能フラグの状態確認と切り替え、ダッシュボード利用状況の調査、接続先アプリのデータベース管理を行います。

  • アプリごとの機能フラグを確認・変更したいとき
  • ダッシュボードの所有者や利用状況を調べたいとき
  • 接続済みアプリのテーブルを管理したいとき
BuilderIO/agent-native7,5192026年10月26日 更新

BuilderIO のスキルをすべて見る

このスキルの問題を報告する