Make the agent interview you before it touches the portal.
An agent handed a one-line request will fill every gap with a guess — and in a live HubSpot account the gaps are exactly where the damage is: live content in the fields it would touch, dependents it can't see, a deploy that publishes immediately. This prompt flips the opening move: the agent asks first, you answer, and the build starts from a brief instead of a guess.
Copy it, paste it before your next change
Bring a real change you need to make — a module edit, a property cleanup, a new section. It opens by orienting in whatever files you can share, then interviews you one round at a time and writes the brief. Nothing gets built until you've seen it.
I have a change to make in HubSpot, and before you plan or build anything I
want you to interview me — the way a senior HubSpot developer would — until
the change is actually specified. In this platform the danger isn't in the
code you can read; it's in the live content, the hidden dependents, and the
deploy that publishes immediately. Your questions have to surface those.
PHASE 0 — Orient. Read whatever project files I can share and tell me what
you can see (templates, modules, fields) and what you can't (live content,
workflows, who edits what). Then ask me to describe the change in one or two
sentences, and WAIT.
PHASE 1 — The interview. Ask one round at a time, most-blocking first, and
wait for my answers between rounds. Cover at least:
- THE INTENT — what should be different for a visitor or a teammate when
this is done? What must NOT change?
- LIVE CONTENT — does this touch fields that marketers have already filled
on live pages? Would a rename or type change orphan or blank what's
there? Do we know who edits those pages in the app, and when?
- NAMES VS. LABELS — if anything is being "renamed," is it a display label
(cosmetic) or an internal name that automations and integrations match
on? If I don't know, that's an answer too — record it as a risk.
- REACH — is anything shared (a global module, a template, a property)?
One page's edit or every page's? What would we check to know?
- ACCESS — could this page's visibility be driven by CRM lists or
memberships rather than the code?
- SHIPPING — when this deploys it publishes live. Is my local copy
current with the account? Who needs a heads-up before it ships? What
would "verified" look like afterward?
- ROLLBACK — how would we undo it? If there's no clean undo, say so and
propose a sandbox-first or staged approach.
Push back on vague answers. "The marketing pages" is not an answer;
"the pricing page hero, edited by Dana on Tuesdays" is.
PHASE 2 — The brief. Write it up short: the intent, the exact assets touched,
what stays untouched, every open risk with its owner (me or you), the ship
plan including the verify step, and the rollback or its absence. Mark every
claim ANSWERED (I told you), READ (you saw it in files), or OPEN (nobody
knows yet). An OPEN on live content, reach, or rollback blocks the build —
name it, don't bury it.
Do not start building. The brief is the deliverable. Start with Phase 0 now.It asks the questions that block, not the ones that fill time
The questions carry the danger
A generic spec interview asks about intent and edge cases. This one asks the HubSpot questions that actually block: does live content fill the fields you'd touch, is that "rename" a label or a load-bearing internal name, and is the page's access even in the code?
Vague answers get pushed back
"The marketing pages" isn't an answer. The interview keeps drilling until assets are named and owners are known — because in a live portal, the difference between one page and every page is the whole risk.
Open risks block, visibly
The brief marks every claim answered, read, or OPEN — and an open on live content, reach, or rollback is flagged as blocking instead of buried. You decide with the risk in view, not after it fires.
A brief with the risks in view
The shape the interview produces — intent pinned, the touched and untouched assets named, a ship plan that treats the deploy as a live publish, and the open risks flagged with an owner instead of buried.
For "add a plan-comparison row to the pricing module," the brief comes back:
INTENT Visitors see a third pricing tier; nothing else moves.
TOUCHES PricingTable module (new field + render); pricing page only —
confirmed not global. [ANSWERED]
UNTOUCHED Existing tier fields keep names AND types — Dana's live
content fills them. [ANSWERED]
ACCESS Pricing page is public; not CRM-gated. [ANSWERED]
SHIP PLAN 1. Dana signs off on edit freeze for Thursday
2. Confirm local is current with the account first
3. Deploy = live publish; verify the pricing page renders
all three tiers + Dana's content intact
RISKS — OPEN, owner named
⚠ Whether the quotes integration reads tier names → me, check live
ROLLBACK Code reverts cleanly; a field DELETION wouldn't — none planned.The deploy is a publish — the interview treats it that way
The brief's shipping round — is local current, who needs a heads-up, what does verified look like — exists because of how HubSpot deploys actually behave. The specifics, sourced:
A CMS-React project ships with hs project upload — there's no staging tier between upload and production; a successful upload is live. The lower-level file commands make the asymmetry explicit: upload publishes immediately (default --mode is publish), watch auto-uploads on every save (also live), and fetch will not overwrite local files without an explicit --overwrite flag — so local quietly falls behind while pushes stay destructive.
As of CLI v8 the old top-level hs upload/hs fetch/hs watch were removed — use the hs cms equivalents; don't let an agent run commands from an older memory.
Reflects HubSpot as of June 2026 · verify against the linked docs
Knowing which questions block is the skill.
This interview works because each question traces to a real HubSpot failure mode — the label that was actually a load-bearing internal name, the “one page” edit that fanned out site-wide, the deploy that stomped a marketer's afternoon. The Agentic HubSpot CMS course teaches the failure modes themselves, so you can judge the answers — not just collect them.
Prefer it as a reusable tool? This prompt is the public twin of the kit's /brief skill. The full kit ships with the course.