Hubspot developer skill
use this skill when building, reviewing, migrating, or planning hubspot developer platform apps (cli projects, app-hsmeta.json), ui extensions (app cards, app pages, settings), @hubspot/ui-extensions components, crm hooks and crm data/action components, hubspot.fetch and serverless app-function hsmeta (config.endpoint, endpoint.methods array), hs project validate upload errors, oauth vs static token distribution, webhooks, custom workflow actions, agent tools, app events/objects, scopes and sensitive data, or marketplace readiness. use for coding agents that need architecture, extension-point choice, file layout, component selection, security constraints, checklists, and testing guidance.From its SKILL.md
npx -y skills add 0xRy4n/hubspot-developer-skillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
16.5 KB, ~3.6k tokens by cl100k_base, as published. Nobody here has run it
HubSpot Developer Skill
Purpose
Use this skill to design, implement, or review HubSpot developer platform apps and UI extensions. Prefer the project-based developer platform over legacy private/public apps unless the user only needs a simple REST token or explicitly maintains legacy code.
Platform apps are file-defined, CLI-managed projects: configuration, assets, and source live in the repo; hs project dev / hs project upload drive local and deployed behavior. UI extensions are React or TypeScript bundles registered by *-hsmeta.json and rendered inside HubSpot’s sandboxed runtime (web worker constraints; use HubSpot APIs and components, not the full browser surface) via hubspot.extend().
Official documentation (start here)
HubSpot’s docs move quickly. Prefer current pages over memory or old blog posts. For a wider link set grouped by topic, use references/official-doc-map.md.
Documentation index: HubSpot publishes a machine-oriented index at https://developers.hubspot.com/docs/llms.txt for discovering pages; if that endpoint is blocked or returns a login wall, use the table above, references/official-doc-map.md, and “See also” links in the docs.
Examples repo: https://github.com/HubSpot/ui-extensions-examples (includes legacy card converter).
Distribution, authentication, and features
From the developer platform overview, what you can ship depends on distribution and authentication (static token vs OAuth; private vs Marketplace). Use the official docs for the live matrix; at a high level:
- API calls, agent tools, app cards, app pages, app settings, custom workflow actions, telemetry, and webhooks v3 are broadly available across common private app setups; webhooks v4, app events, and app objects lean toward OAuth / Marketplace-style distribution in the documented matrix.
- Serverless functions and SCIM are documented with tighter pairing to static-token / private patterns in that matrix—verify before promising architecture.
- Public functions for CMS follow the CMS serverless path (see CMS docs), not the same shape as app project serverless functions.
When choosing features, read app configuration and the overview table together so you do not design OAuth-only features (e.g. certain webhook or app-object flows) for a static-token-only app.
First decision (task routing)
- Only scripted API access for internal automation: a legacy private app token may suffice; still mention developer platform for anything that might grow UI or Marketplace.
- In-portal UI, cards, app home, settings, OAuth, Marketplace: use a developer platform project.
- Context beside a record, ticket, preview, or supported sidebar: app card (UI extension).
- Dashboard / multi-step / full-width app experience: app pages.
- In-app configuration (API keys, mapping, toggles): settings page UI extension.
- External HTTP from the extension:
hubspot.fetch()only with allowed URLs, size/time limits, and security docs understood first.
Hard limits to internalize (see UI extensions overview and references/ui-extensions-runtime.md): default 15s fetch timeout (up to 120s), 1 MB request/response bodies, 20 concurrent fetches per account, no custom headers except Authorization, no native fetch in extension code (lint enforces this).
UI extension components (@hubspot/ui-extensions)
Follow the UI extension components overview.
Package version
Install or upgrade the SDK in the extension directory that owns the card, settings, or page bundle (often under src/app/cards, settings, or pages—match your repo):
npm i @hubspot/ui-extensions@latest
Two import surfaces
- Standard components (layout, forms, text, charts, modals, etc.): from
@hubspot/ui-extensions. They do not fetch CRM data by themselves; you compose them with hooks, props, orhubspot.fetch(). - CRM data and CRM action components: from
@hubspot/ui-extensions/crm.
import { Alert, Text, Flex, Button } from "@hubspot/ui-extensions";
import { CrmAssociationPivot, CrmActionLink } from "@hubspot/ui-extensions/crm";
CRM-specific behavior
- CRM data components load from the current CRM record context. Official docs state they are restricted to the middle column of CRM records—do not plan sidebar-only layouts for them without verifying current placement rules.
- CRM action components (e.g. action button, link, card actions) expose the same underlying CRM actions through different UI shapes—pick by UX, not by capability difference.
For layout, use Flex, Box, Inline, Spacer, AutoGrid, etc., per manage UI extension layout. Prefer HubSpot primitives over ad hoc HTML/CSS that fights the sandbox.
Design reference: Figma design kit (linked from the components overview).
Core app workflow
- Clarify audience, account type, and Marketplace vs private.
- Read platform version from
app-hsmeta.json/ project docs (e.g.2025.2,2026.03—never assume from memory). - Scaffold with HubSpot CLI (
hs project create,hs project add); treat generated layout as the default. - Keep
app-hsmeta.jsonand each extension’s*-hsmeta.jsonas the source of truth for UIDs, types,location,entrypoint,objectTypes, and display metadata. - Implement UI in React/TSX; register with
hubspot.extend()in the entrypoint. - Prefer CRM hooks and CRM components for HubSpot-hosted CRM data; use
hubspot.fetch()only for allowed external URLs. - Develop with
hs project dev; upload withhs project uploadwhen validating deployed behavior. - Use extension logs, render logs, and fetch logs before calling work “done.”
- For Marketplace, add a review pass: scopes, sensitive data, errors, install/uninstall, empty states, and security.
Modern UI extension anatomy
*-hsmeta.json: extension type, HubSpot location, display metadata, objectTypes (for CRM surfaces), entrypoint path.- Entrypoint:
hubspot.extend(({ context, actions }) => …)(see current samples for exact typing imports your project uses). - React tree: standard + CRM components; loading / empty / error / permission states.
- Optional
hubspot.fetch()to partner backends; optional serverless functions where docs allow for your auth model.
App-function *-hsmeta.json (serverless) and hs project upload
app-function components use "type": "app-function" and config.entrypoint (see serverless reference). hs project validate / hs project upload may fail if HTTP-oriented functions omit config.endpoint.
Common validation errors (real CLI output):
Missing required field: 'config.endpoint'— add anendpointobject underconfigfor functions that receive inbound HTTP (for example OAuth callback routes).Missing required field: 'config.endpoint.methods'plusadditionalProperty: method— the schema expectsmethods(array of verbs, e.g.["GET"],["POST"]), not a singularmethodfield. Removemethodand usemethodsinstead.
Always run hs project validate after editing function metadata; if the validator disagrees with an older doc example, follow the validator for your installed hs --version. Details and examples: references/serverless-app-function-hsmeta.md.
File layout rules
CLI templates evolve. After hs project add, mirror the generated paths instead of inventing filenames. Commonly you will see extension code under paths such as src/app/cards/ with a shared package.json per feature area; confirm on disk before advising moves or imports.
Do not conflate legacy CRM cards (iframe / external patterns) with modern UI extension app cards; migrations should be called out explicitly in plans and commits.
Security and sensitive data
- Request the smallest scope set that satisfies the workflow.
- Sensitive Data scopes carry extra restrictions (e.g. interactions with
hubspot.fetch()and serverless functions). Treat docs as law: if the app needs both sensitive CRM surfaces and external calls, you may need product splits or a different flow—validate in current HubSpot documentation before implementation.
Required agent behavior
- Read the repo first:
src/app/app-hsmeta.json, extension metadata,package.json, lockfile, and CLI version. - Classify legacy vs developer platform and static vs OAuth.
- Smallest coherent change; keep generated structure unless there is a documented reason to diverge.
- Verify APIs against official pages (links in this file) when outputting config shapes, component names, or limits.
- Report what was changed, commands run, scopes, manual HubSpot test steps, and doc assumptions.
Bundled reference files
Use these for deeper patterns without duplicating them entirely in chat:
references/official-doc-map.md— curated doc index by topic (platform, UI, serverless, APIs, legacy).references/ui-extensions-runtime.md— sandbox,hubspot.fetch()limits,locationvalues, Sensitive Data, CRM data placement.references/ui-extensions-sdk-primer.md—context/actions, hooks vs props, overlays, iframe modal, clipboard, logging.references/app-cards-metadata.md— card*-hsmeta.jsonfields,objectTypes+ scopes, sidebar vs CRM data components, help desk.references/serverless-and-enterprise.md— 2026.03 serverless, Enterprise install, dev test accounts, vs CMS serverless.references/serverless-app-function-hsmeta.md—config.endpoint,methodsvsmethod,hs project validate/ upload failures.references/testing-and-linting.md—createRenderer,@hubspot/ui-extensions/testing,@hubspot/eslint-config-ui-extensions, monitoring.references/marketplace-and-gated-features.md— matrix reminders, app objects approval, webhooks v3/v4, listing readiness.references/hubspot-modern-platform.md— platform concepts, CLI commands, migration outline.references/ui-extension-design.md— extension-point choice, UX, data loading, sensitive data.references/implementation-checklist.md— before coding, review, testing, debugging.references/examples.md— minimal shapes and prompt recipes for agents.
What ships with it: 17 files
46.8 KB alongside SKILL.md, 1 of them executable
agents/
- openai.yaml174 B
references/
- app-cards-metadata.md3.6 KB
- examples.md3.1 KB
- hubspot-modern-platform.md3.2 KB
- implementation-checklist.md3.7 KB
- marketplace-and-gated-features.md2.6 KB
- official-doc-map.md7.6 KB
- serverless-and-enterprise.md2.4 KB
- serverless-app-function-hsmeta.md2.5 KB
- testing-and-linting.md2.8 KB
- ui-extension-design.md3.0 KB
- ui-extensions-runtime.md4.3 KB
- ui-extensions-sdk-primer.md3.7 KB
scripts/
- install-claude-skill.shruns342 B
- .gitignore105 B
- LICENSE1.0 KB
- README.md2.8 KB
Gives 0 of the 12 instructions most sales crm skills give in ~3.6k tokens
Counted across 361 of the 361 authors here whose files we hold, read 2026-08-07
- Read product marketing context before writing if it existsin 22 of 361, across 15 files
- Keep the ask low-frictionin 16 of 361, across 7 files
- Call RUBE_SEARCH_TOOLS firstin 15 of 361, across 5 files
- Use a single, low-friction call to actionin 14 of 361, across 6 files
- Personalize every outbound messagein 13 of 361, across 4 files
- Confirm connection status is activein 13 of 361, across 4 files
- Keep forwardable blurbs under 100 wordsin 13 of 361, across 4 files
- Cut any sentence that does not drive a replyin 13 of 361, across 4 files
- State if personalization context is missingin 13 of 361, across 4 files
- Calibrate tone to the specific audiencein 12 of 361, across 3 files
- Make each follow-up email add new valuein 12 of 361, across 6 files
- Use proof instead of adjectivesin 12 of 361, across 3 files
Said here and by no other author read
- prefer current documentation pages over memory
- use the project-based developer platform over legacy apps
- read platform version from configuration files
- scaffold projects using the HubSpot CLI
- treat extension metadata files as source of truth
- use React and hubspot.extend for UI entrypoints
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.