Value-First Studios · HubSpot Academy Bootcamp
CLAUDE.md starter — copy, paste, fill in
The CLAUDE.md guide explains the do-this / not-that behind every section. This is the blank it points to: a fill-in template you paste, complete in a couple of minutes, and keep. Each section carries a one-line reminder of why it earns its place — delete the reminders as you fill the blanks.
The blank
Copy it, then make it yours
Written for the build we do in the course — a HubSpot integration you run with Claude Code — but every line is a [bracketed blank] you swap for your own. The <!-- --> lines are the guidance; keep them while you fill it in, then remove them.
# CLAUDE.md — [Your Project Name]
<!-- Name the framework, the version, and the ONE job in a single breath.
Not "help me with my HubSpot project" — with no stack and no goal it guesses both, and guesses wrong. -->
[Framework + version, e.g. Next.js (App Router), TypeScript, Node.js 18+].
Deployed on [where]. One job: [the single thing this does, in one sentence].
## Where things live
<!-- Point it at your REAL folders, and the ONE place your HubSpot calls live.
Don't let it invent a structure — you'll fight the guesses for the rest of the session. -->
- Code: [path, e.g. src/app/...]
- HubSpot calls: [one file, e.g. src/lib/hubspot.ts — never inline in a route]
- Secrets: [.env — list the KEY NAMES only, e.g. HUBSPOT_TOKEN; never the values]
## HubSpot setup
<!-- Give it the REAL property and object names, and the auth it needs.
A guessed property name is the number-one way these break. Look names up
first; never invent one because it "sounds right." -->
- Auth: [private-app token / Service key] in [ENV_VAR_NAME]. Scopes: [read/write, which objects].
- Properties: use the real internal names — [list the exact ones], or read them back before using one.
- Lookups: [any rule, e.g. match a company by the contact's email domain].
## How I want you to work
<!-- Ask for the loop every time: plan, then run, then read back. A 200 is not proof. -->
- Plan before you write. Tell me the files you'll touch first.
- Run what you write. Don't hand me code you never ran.
- Read the record back and show me — a green checkmark is not "done."
- Approvals: [e.g. ask before anything that writes; one small change at a time].
## Guardrails
<!-- Warmth toward the teammate, discipline toward the work. -->
- Never write to a production portal unattended. Sandbox first.
- Never put a [customer email / any personal data] inside a web-search query.
- Right-size the model for the job — don't reach for the biggest one by default.
- [Anything else that must never happen here].
## Keep this short
<!-- If it's obvious, leave it out. Capture only what you'd otherwise re-explain
every session, and update it when the stack changes. -->
What each section is for
Name the framework and the one job
Stack, version, and the single thing this does — in one breath. Not "help me with my HubSpot project."
Where things live
Point it at your real folders and the one file your HubSpot calls live in. Don’t let it invent a structure.
Real HubSpot property names
Give it the actual internal names, or make it read them back. A guessed property is the number-one way these break.
Where keys and .env live
Name the environment variables, never the values. The token lives in .env, not in the file you paste around.
How we work, and what needs approval
Plan, run, read back — a 200 is not proof. Say what it may do on its own and what waits for you.
Never write to production unattended
Sandbox first, right-size the model, protect the human’s data. Then: keep the whole file short and intentional.
Want the reasoning behind each section, plus our real operating file in full? The CLAUDE.md guide walks all of it, section by section.