Map the blast radius HubSpot won't show you.
On a codebase, “what will this break?” has a mechanical answer: grep for the callers. HubSpot takes that tool away — there's no global “what references this” view, and the dependency graph lives in the running account, not in files. This prompt makes your agent build the dependents checklist the platform won't hand you — before you change anything.
Copy it, run it before your next change
Pick one asset you're tempted to change or delete — a property, a list, a module — and paste this in. It opens by asking what you can share and what you're changing; answer, and it structures the hunt. The agent holds the pen; you hold the truth.
I want to map the blast radius of a change in HubSpot before I make it, knowing
HubSpot has no global "what references this" view — the dependency graph lives
in the running account, not in files, so you cannot grep for it. Your job is to
structure the hunt; mine is to walk the account. Do not guess that anything is
safe.
PHASE 0 — Orient, then ask. First get oriented in whatever I can give you —
exported theme or project files, a list of our workflows and lists, screenshots
of an asset's settings — and tell me plainly what you can and cannot determine
about dependents from that alone. Then ask me:
- Which asset am I planning to change or delete (a property, a list, a
module, a template)?
- What do I already know about how it's used, and who built the automations
around it?
- What must still work afterward — the specific workflows, lists, reports,
and integrations, named one by one?
Then STOP and wait for my answers.
PHASE 1 — Pin the claim. Turn "don't break anything" into a falsifiable list:
the named things whose behavior must be unchanged after my edit. Vague entries
like "the marketing automations" get pushed back until they're specific.
PHASE 2 — Build the dependents checklist I walk by hand. For this kind of
asset, list every place it can be referenced — workflows, lists, reports,
forms, integrations, other assets — framed as concrete questions I go verify
in the account, one surface at a time. Mark each item:
- PROVABLE HERE — you could confirm it from the files or exports I gave you.
- VERIFY LIVE — only I can check it, in the account, by hand.
Assume there are dependents neither of us can see until checked.
PHASE 3 — Rate the map. As I report back, rate each dependency proved /
assumed / unknown. Be strict: "I checked and it doesn't reference this" is
proved; "it probably doesn't" is assumed. Keep every unknown on the board as
unresolved risk — do not round it up to fine.
PHASE 4 — Decide with the rollback named. Ask me how I would undo this change.
If there is no clean undo, say so plainly and recommend a sandbox-first or
staged approach instead of a live edit.
The artifact I want at the end: a short written blast-radius map — the claim,
each dependency with its rating, and the rollback or its absence. Do not tell
me the change is safe. Tell me what's still unknown.
Start with Phase 0 now.It doesn't pretend the graph is readable
It maps what it can't see
The dependents of a HubSpot asset live in the running account — configured in the UI over months — not in any file an agent can read. So the prompt makes the agent structure the hunt instead of pretending to run it: a checklist of every surface where the asset can be referenced.
Provable vs. verify-live
Every item is marked either provable from the files you handed over or something only you can check in the account. That split is the whole trick — it stops the agent from reporting success on a graph it never saw.
Unknowns stay on the board
Each dependency ends up rated proved, assumed, or unknown — and the unknowns are named as unresolved risk instead of rounded up to "fine." The output is a map you can review, not a verdict you have to trust.
A map you review, not a verdict you trust
Here's the shape the prompt produces — the claim pinned to named assets, the checklist split into what's provable from files versus what you verify live, and honest ratings with the unknowns kept on the board. Yours comes back specific to your change.
For "repurpose the lead_source property," the shape you get back: THE CLAIM — what must still work, named 1. "MQL routing" workflow keeps assigning owners correctly 2. "Paid-channel leads" active list keeps the same membership logic 3. The attribution report keeps grouping by the same values DEPENDENTS CHECKLIST — walk these by hand workflows Which workflows read or set lead_source? VERIFY LIVE lists Which active lists filter on it? VERIFY LIVE reports Which reports group or filter by it? VERIFY LIVE forms Which forms write to it? VERIFY LIVE integrations Does the CRM sync map this field? VERIFY LIVE theme code Does any module or template read it? PROVABLE HERE ✓ THE MAP — after you report back MQL routing proved (opened it; matches on option values — at risk!) Paid-channel list assumed (owner says no, not yet opened) CRM sync UNKNOWN ← resolve before touching anything ROLLBACK: none clean — option values don't revert. Recommend sandbox first.
The files are real — they're just not the whole site
The “provable here” column isn't empty: a modern HubSpot CMS project has a real code layer your agent can read and reason about. The X-ray works because it uses that layer fully — and refuses to extrapolate from it to the parts that live only in the account.
A project declares its platform in hsproject.json (e.g. platformVersion: "2025.2", srcDir); the theme lives under that src dir with theme.json, fields.json, HubL templates, and components/. A CMS-React module exports Component, meta, and fields — the field definitions that render the editor UI a marketer fills in.
That's the greppable layer. The content poured into those fields, and the workflows, lists, and reports that depend on your assets, live in the account — which is why the prompt splits its checklist into provable here vs. verify live.
Reflects HubSpot as of June 2026 · verify against the linked docs
The map is one rep. The reflex is the course.
This prompt compresses the HubSpot Orientation module into one paste: why the blast radius isn't greppable, why the safe-looking rename can be the destructive one, and the four-move pass you run before every real change. The full course makes it a habit — with the CMS module on top, so your agent ships theme changes without clobbering live work.
Prefer it as a reusable tool? This prompt is the public twin of the kit's /system-map and /blast-radius skills. The full kit ships with the course.