
Your team is already building with AI. It just doesn't reach anyone.
If your GTM engineer req has sat open for a quarter, look at what your team built while it waited. There's usually someone in marketing ops with a Claude skill that pulls account research in two minutes, and nobody else can run it. Two other people have built their own versions, and no two work the same way.

The same builders sit on both sides. What changes is where the skill lives, who owns it, and who gets the fix. We build the right side with your builders in four weeks, starting from what they've already built.
Find your builders this week. Ask one question in your team channel, or in your next one-on-ones:
“What have you built with AI for your own work, even if it only runs on your laptop?”
Say up front that naming a build won't add it to anyone's objectives without the time to run it.
- The answers name your builders. Give one of them a task someone did by hand twice this week.
- Name who fixes it when it comes out wrong.
- Count the days until everyone has the fix.
In a shared harness, one person's fix reaches everyone.
The shared harness ships a fix the way code ships: someone reviews it, every version is kept, and a bad change comes back out the same way it went in. Every skill reads the same brand, GTM context and systems of record, so a marketer's skill sounds like your team, and the checks catch what a builder misses.
Before a second person relies on a skill, name its owner, put the shared version in one place, and decide how changes get reviewed. That's the setup we build with your builders, at about half a day a week from each of them, with an owner and a backup on your team for every shared skill agent. Your team runs it after we go.
Two of our three builders aren't engineers, and all three ship.
Written with Claude, 14 Sep to 5 Oct
| Who | Among what shipped | Written with Claude, 14 Sep to 5 Oct |
|---|---|---|
| FounderRan marketing teams | The skill that logs his meetings to HubSpot; the check that makes every page write GTM; the image-service fix that gave everyone clean transparent backgrounds | |
| Delivery leadStudied computer science | A daily check on the answers our client portal's assistant gives; logging on every tool call it serves | |
| Program managerRuns our programs | A skill that drafts action items after every external call; a weekly calendar coverage check; two tools in our image service; a timeline component for this site |
Every one of us changes the harness: the skills, connections, brand rules and checks we all work inside. Read the program manager's row twice: 78 of 81 changes written with Claude, by the person who runs our programs.
A person who knows the task can build it.
- # Log my Sculpt meetings to HubSpot
- Lines 7 to 16: where it was built, then three numbered steps
- It is safe to re-run: an event already in HubSpot (same calendar link, or same title and start) is skipped. HubSpot's
- search lags a write by a few seconds, so wait a minute before re-running. It creates
- a contact only for an outside guest at a company domain, never for our team or free mail. Sam owns every record.
- Line 21 on: the code Claude wrote
Show all 28 lines
- ---
- name: sculpt-meetings-to-hubspot
- description: Log Sam's Sculpt meetings from Google Calendar into HubSpot, one meeting record per event on the guest's contact and company. Use when Sam says "log my Sculpt meetings to HubSpot", or names other meetings to log the same way.
- ---
- # Log my Sculpt meetings to HubSpot
- Built live in The Squeeze 01, beat two. Repo `fresh-context`; run from `fresh-context/`.
- 1. **Calendar.** With `GOOGLE_CALENDAR_REFRESH_TOKEN` in `apps/website/.env.local`, the script reads Sam's calendar
- itself. Without it, call the Google Calendar MCP `list_events` (`fullText: "Sculpt"`, the same window), save the
- result to a file in the scratchpad and add `--events <file>`.
- 2. **Run** the block below. `--dry-run` lists without writing. `--match "<words>"`, `--from` and `--to` (YYYY-MM-DD)
- pick other meetings; the default is Sculpt, today plus seven days. `--redact` prints "guest 1" for a recording.
- 3. **Report** each line and the HubSpot links.
- It is safe to re-run: an event already in HubSpot (same calendar link, or same title and start) is skipped. HubSpot's
- search lags a write by a few seconds, so wait a minute before re-running. It creates
- a contact only for an outside guest at a company domain, never for our team or free mail. Sam owns every record.
- Claude wrote the code from here down.
- ```bash
- cd "$(git -C fresh-context rev-parse --show-toplevel 2>/dev/null || git rev-parse --show-toplevel)"
- python3 - --match Sculpt <<'PY'
- import json, os, sys, urllib.error, urllib.parse, urllib.request
- from datetime import datetime, timedelta
- A = sys.argv[1:]
- arg = lambda k, d=None: A[A.index(k) + 1] if k in A else d
- MATCH, DRY, RED = arg('--match', 'Sculpt'), '--dry-run' in A, '--redact' in A
Sam asked Claude for that skill in plain English, with no engineer involved, then built one live in our recorded talk, The Squeeze 01. He ran it on one real meeting and the record showed up in HubSpot.
Read the paragraph under the steps. The skill skips any meeting already logged, never makes a contact for our own team or for free email, and names who owns every record. Those rules come from knowing the task, not from knowing how to code. What a builder needs to learn to start fits in a sentence: talk to your computer, tell it what you want, and know where to put it.
“There are a lot of people who are semi-technical, doing configuration and SaaS work today, who will totally grok this if you enable them. No one's given them the map.”Sam Gong, The Squeeze 01
When you do hire that GTM engineer, they take the reviewer's seat: reviewing, merging and keeping everyone else's skills working.
Not everyone becomes a great builder. A great builder can come from anywhere.
The critic in Ratatouille said it first, about cooks.
Anyone on your team can build fast: what they need today, shipped this week. Building right is knowing which skills the team needs, keeping the ones it runs on working, and changing the processes leaders own. Your best builders will come out of marketing ops, RevOps and the field, and they grow into an AI GTM product team when three seats are filled:
The first two get you a harness that works. The third changes what your team does, not only how fast it does it. Running GTM this way is GTM product thinking.
Your builders' time is your call.
The point is fewer handoffs for your customers, not fewer job titles. Your builders can build on their own. Redesigning the work around what they build is yours, because changing the process means changing people's jobs.
Protected time is a budget line.
Decide what each builder stops doing, who reviews their changes and who owns the result, before the first shared skill ships.
GTM Claude Code in Team ModeWe set up one GTM team in Claude Code with shared skills its own builders write and improve. Four weeks, beside your team.Field Guide What is GTM product thinking?Proposal B build, 5 October 2026. Concept frames are Studio explorations pending Sam's pick; data marks are drawn from git history and dated public facts; agent marks a term no source settles.