HubSpot Projects CLI Checklist

Start with classification, not commands. A new public or Marketplace app, an existing non-project legacy public app, an existing project-based app, an existing private app, and a CRM card modernization project each point to different official docs. Writing down the app category first prevents a common failure mode: running a plausible CLI command before the app structure is understood.

After classification, inspect the local and account context. Record HubSpot CLI version, Node version, authenticated account, developer account ID, whether `hsproject.json` exists, current `platformVersion`, and where `app-hsmeta.json` lives. These checks are deliberately simple, because they create the evidence a developer or agent needs before giving production-affecting guidance.

Finally, connect the app inventory to delivery risk: OAuth redirect URLs, scopes, Marketplace listing requirements, support URL, privacy URL, CI secret handling, and a source recheck date. The checklist is meant to produce a handoff that another developer can verify, not a blind migration script.

Paste the app classification, file tree, CLI version, Node version, and target timeline into your coding agent. Ask the agent to return a likely path to verify, open questions, and source links. The packaged skill uses the same sequence and explicitly tells the agent to avoid official, certified, endorsed, or guaranteed claims.

If the agent cannot see current HubSpot docs during the session, require it to say that. This matters because HubSpot platform documentation can change, and the local source archive in this project was checked on 2026-05-24.

For agencies, use the checklist as a client intake artifact. It gives non-developers a way to see why the project is being routed to new app creation, public app migration, project migration, private app manual planning, or CRM card modernization.