Ask ChatGPT, Claude, and Gemini the same research question and you will get three different answers.

Each engine indexes a different slice of the web and reasons through it with a different model. Each one catches things the others miss.

The places where all three agree just confirm what Wikipedia would tell you anyway. The places where exactly one engine found a claim — and that claim survives a hostile fact-check — are where the actually useful intel lives.

That set-difference between the three engines is the asymmetric edge.

Capturing it in practice has been almost impossible until now. Reading three deep-research reports and verifying every citation across them takes half a day for any human.

Triple Deep Research is the tool I built to do that work for you.

It takes one question, fans it across ChatGPT, Claude, and Gemini at the same time, and runs a wave of Claude agents that fact-checks every cited link in all three reports. What comes back is one synthesized report where every claim cites a stable identifier in the raw text — and where the disagreements that survived verification lead the report as the asymmetric edge.

What it does

You feed Triple one question.

Something like "What state-level rules passed in 2025 affect Medicare Advantage reimbursement?" Or "Which B2B SaaS companies shipped AI agent products in the last year and then publicly walked them back?"

The tool fans that question to all three engines at the same time. ChatGPT runs its deep research on its own slice of the web. Claude runs its deep research on its own index. Gemini runs its deep research on the Google corpus.

Three engines. Three models. Three separate cross-sections of the open web — all working the same question in parallel.

Once the reports come back, a wave of Claude agents takes them apart.

The first agent breaks every claim into its smallest factual unit and labels each one by how many engines surfaced it. Three more agents work in parallel — one per platform — and each opens every cited URL to decide whether the page actually supports the claim.

A fourth agent catches the date errors the engines tend to miss. A judge ranks every surviving claim by how much it actually shifts your thinking.

A final writer synthesizes everything into one report where every claim cites a stable identifier you can resolve back to the raw page text.

A run takes 15 to 55 minutes, gated by whichever engine is slowest.

The cost is nothing on the deep research itself. The work rides on the ChatGPT Plus, Claude Pro, and Gemini Advanced subscriptions you already pay for. The only marginal spend is about $3 in Claude agent tokens to run the fact-checker wave.

Why three engines, not one

The three engines do not see the same web.

ChatGPT runs on the Bing index. That gives it strong coverage of news and academic sources, and pulls back the well-edited material journalists and researchers tend to cite.

Claude runs on its own index. It is strongest on long-form blogs and has been sharpening fast on primary documents — court filings, government reports, things like that.

Gemini sits on the full Google index, which has the largest surface area of the three by a wide margin. It routinely reaches obscure corners of the web — niche forums, regional publications, vendor PDFs — that no other engine touches.

Running a question through one engine gives you one cross-section of the web's knowledge on that question. Running the same question through all three gives you the set-difference — the gold sitting between the cross-sections.

The all-three-agree claims tend to be the consensus you could have found in any general search. They are a useful baseline, but they are not insight.

The one-of-three claims — the things that only one engine surfaced — are where the asymmetric value lives. If, that is, you can verify them against primary sources and rule out the ones the engine just hallucinated.

The asymmetric value is the set-difference. Everything else is just an answer.

The proof point: 1 link → 60 citations

Two paths exist for reading a deep-research report off these platforms. One returns almost nothing. The other returns everything.

The naive path scrapes the page's visible HTML — the DOM — and extracts whatever text and links you can see. The problem: what you see is almost never what is actually there.

On Claude, a DOM scraper gets back 1 link out of the 427 sources the page itself shows next to the report. The report lives inside a Document artifact tile the DOM snapshot cannot reach.

On ChatGPT, a DOM scraper gets back 0 characters of the report. ChatGPT renders it inside a sandbox iframe the outer page is not allowed to read.

On Gemini, the citations come back as redirect URLs the DOM never resolves. You end up with a list of meaningless redirect handles instead of real source pages.

The path that actually works asks the platform for its own data, the same way the platform's own page asks for it.

Each engine ships an undocumented data feed that the page itself calls to load the report. From inside the page — meaning from inside a real browser tab the user is already signed into — you can call that same feed and the platform hands you the data back as plain text.

On Claude, that call pulls the full 31,213-character report and all 60 citations in 157 milliseconds.

On ChatGPT, the report comes back as plain text from the same conversation feed the website's own React app reads.

On Gemini, the redirect-only citation URLs resolve to their real destinations. You can fetch them from inside the real browser tab, and Cloudflare passes you through — because you actually are a real browser tab.

Same conversation. Same question. Different read path. One returns roughly 0% of the information. The other returns 100%.

Every library you'd reach for is broken

No off-the-shelf scraper handles all three platforms cleanly. None of these platforms want to be driven by anything that is not a real human in a real browser.

They have layers of defenses. Each layer was specifically designed to break the kind of script you would write to automate them.

ChatGPT runs a real-time signal-validation system inside the page. It watches for things a script would never do — patterns of clicks, keystrokes, and timings that a human produces but a bot does not. It silently flags any session that fails the test.

On top of that, every write to ChatGPT's interface hits a math puzzle the page itself computes before sending. A normal request cannot pass without running the page's own code.

On top of that, Cloudflare runs its bot challenge — the same test that decides whether to throw up a "verify you are human" page. The challenge token regenerates every few seconds.

Each of those three layers will reject a naive script the moment it tries.

Claude has a different problem.

The first time you drive a deep-research session in Claude, the page pops up a modal asking which "connectors" you want to allow — file system, GitHub, Drive, and the rest. The page refuses to run the research until the modal is dismissed.

A second modal then asks you to clarify the scope of your research before submitting. A scraper that does not handle those two modals dies at the door — and most do not.

Gemini wraps every response inside a serialized envelope format that Google uses internally. The envelope arrives in the network log as a chunked stream.

The chunks expire seconds after the network event fires. If you are not reading the response from inside the same page that received it, you do not get to read it at all.

The open-source libraries around all three are broken, as you would expect from that list.

The most popular Gemini scraper on GitHub has six open critical bugs nobody has fixed in months. ChatGPT exporters break every time Cloudflare rotates its challenge — which is every few seconds.

Claude scrapers cannot make it past the connector modals because they were built for the old chat surface, not the deep-research workflow that ships those modals.

You can spend a week patching one of those libraries every time a platform shifts its UI. Or you can stop fighting the platforms and let the browser do the writing for you.

The insight: browser owns writes, JSON owns reads

The trick is to stop pretending you are not a browser.

Use the user's real signed-in Chrome — the actual browser with the actual cookies and the actual login session — and drive that. Instead of building a bot that tries to look like a browser, take a browser that is already signed in and tell it what to do.

When you drive the real Chrome, every defense the platform built falls away on its own.

The math puzzle gets computed by the platform's own page code — the page is the thing computing it. The bot-challenge tokens come along for free, because they are generated inside the page session you are inside of.

The IP address Cloudflare sees is the user's real IP. The handshake is the user's real handshake. Cloudflare looks at all of it and sees a real signed-in browser doing what real signed-in browsers do. It lets the request through.

That is the write path. Every input goes through the real browser.

For the read path, you ask the same page for its data, from inside the page. Each platform has its own undocumented data feed the website itself calls to load the report.

From a real tab with real cookies, that feed returns the report as plain text.

No DOM scraping. No screenshot tricks. No envelope-unwrapping from outside the page.

Browser owns writes. JSON owns reads.

Type into the real browser, then ask the real browser for the data back.

One more piece matters: the extraction step is decoupled from the browser run.

The browser saves the raw page and the raw response to disk before the extractor touches anything. The extractor then reads from disk, not from the live browser.

If a platform ships a UI change next week and breaks the extractor, you re-run only the extractor against the raw page you already saved. You do not re-pay for another 30-minute deep-research run — which would cost both wall time and quota against your weekly limits across all three platforms.

How the fact-checker wave defends every claim

Once the three reports are on disk, a wave of Claude agents takes them apart and verifies every claim.

The waves run in a specific order, because each one builds on what the previous wave wrote. The asymmetric-edge claims surface at the top; anything that looks like a hallucination gets filtered out.

• Cross-Corroborate. One Sonnet agent reads all three reports and breaks every claim into its smallest factual unit — one fact, one subject, one source. Each unit then gets labeled by how many engines surfaced it: agreed by all three, agreed by two of three, found only in one engine, or contradicted between engines. That labeling is the substrate everything else depends on.

• Link & Fact Skeptic, three at the same time. One Sonnet agent runs per platform, with all three in parallel. Each agent opens every URL cited in its platform's report, reads the source page, and assigns a verdict from one of five buckets: supports the claim, partially supports it, contradicts it, dead link, or hallucinated cite. Every link gets saved — including the dead ones — so the receipts stay visible.

• Date Skeptic. One Sonnet agent works across all three reports looking for the date errors deep-research engines are notoriously bad at. It catches stale-recency claims (a "recent" thing that actually cites a 2019 source), event-misattribution (the right thing happened, but to a different company), and publication-drift (the cited page has been edited since the report was written, and the claim no longer matches what the page says).

• Usefulness Judge. One Opus agent reads everything the skeptics wrote and ranks every surviving claim on four axes — does it advance the goal you asked about, does it surface information the other engines missed, can you actually do something with it, and can you sort your buyer list by it. Claims that scored high on asymmetry (only one engine found them) get a bonus weighting if they also passed the fact-check, because those are the ones that represent the actual edge.

• Final Synthesizer. One Opus agent reads everything written above it — the original three reports, the corroboration labels, every skeptic's verdicts, the usefulness ranking — and writes the final report. Every claim cites back to a stable identifier like [claude-042] or [chatgpt-014] that resolves to the raw page text on disk. The verification appendix at the end lists every dead link, every hallucinated citation, every date flag, and every contradiction the skeptics raised. Receipts visible.

By the time a claim makes it into the final report, it has been atomized, labeled, fact-checked against its source, date-validated, ranked for usefulness, and tagged with its provenance.

The claims that survived AND came from only one engine lead the report — that is the asymmetric edge, made automatic.

Fail-fast partial Triple

One platform failing does not block the run.

If Gemini times out at submit, or ChatGPT hits a weekly Deep Research quota you are bumping up against, or Claude's connector modal takes too long to clear — that platform exits with a clear terminal status. The other two keep going.

The fact-checker wave then runs on whatever 1, 2, or 3 platforms succeeded.

The asymmetric-edge thesis still works with two of three engines. You just have less to compare against.

It even works with one of three. The fact-checker wave still runs and at least filters out the hallucinated cites.

Partial Triple is degraded, but it is still useful.

When NOT to invoke

Situations where Triple is the wrong call:

• Quick factual lookups. If your question is something like "What's the population of Boise?" — one engine is fine. Do not burn 45 minutes on it.

• Code search. Use Grep. Triple is not your file finder, and the deep-research engines were not built to scan your repo.

• Account-specific research. If you want to know what is happening inside a single account — the CRM history, the call notes, the billing trail — use the Dossier Builder skill instead. Triple is for the open web, not for the data you already own.

• Anything where wall-clock under five minutes matters. Triple is 15 to 55 minutes by the clock. If you need the answer right now, ask one engine and move on.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

The short version

I built a new tool. It checks customer data before you try to build anything with it. If the data is broken, the tool stops you. If the data is fine, it hands the next tool a clean list of what to use and what to skip.

That's it. The rest of this post explains why it matters and how it works.

First: what's a customer dossier?

Think of it like a one-page report for a single customer. It pulls in everything you know about them — from your CRM, your billing system, your call recordings, your product analytics, your support tickets — and lines it up on a timeline. Then it tells you the truth about that account in plain English. Are they active? Are they about to churn? Who do they actually talk to?

I have a tool called Dossier Builder that makes these reports. Point it at a customer's data, and it gives you the dossier.

But Dossier Builder only works if the data going in is good. And the data is almost never good.

Why dossiers usually break

Three problems show up in almost every customer's data. Let me explain each one in plain English.

Problem 1: Data that doesn't actually match

Most companies have multiple systems. A CRM. A billing tool. A call recorder. These systems are supposed to talk to each other. The CRM has a customer ID. The billing tool has a customer ID. Match them up, and you can see one customer across both systems.

Except the matching is often wrong. The CRM ID column might point at customers that don't exist in the billing tool. Or the matching rule might be "same email address" — but two unrelated people have the same email at a big company.

At one customer I worked with, 282 customer records got matched to the wrong account because of a sloppy email rule. Nobody noticed. Every report built on top of that data was wrong.

Problem 2: Too many columns saying the same thing

Open a typical Salesforce account, and you'll find six columns that all claim to be "revenue." Annual Revenue. MRR. Monthly Revenue Summary. Reported Revenue. Subscription Revenue. Annual Revenue Range.

They don't agree with each other. Most of them haven't been updated in 18 months. None of them are labeled as the "real" one.

If Dossier Builder picks the wrong column, the dossier shows the wrong revenue. The CEO closes the report. You lose.

Problem 3: The same company shows up three times

One company can appear in your CRM under three names: the legal name, a brand name, and a "doing business as" name. Each one looks like a separate account. Each one shows half the activity. The real picture is split across all three.

Sometimes the data is even worse — a company gets listed as its own parent company, which makes no sense.

The fix: check the data first

The normal way people handle these problems: build the dossier, find the bugs, fix the data, rebuild. That wastes a whole day.

My new tool reverses the order. It runs first. It looks for all three problems. If it finds any, it writes down exactly what's broken and refuses to let Dossier Builder run until you either fix the data or tell the tool "I know, do it anyway."

I call it the Dossier Data Auditor.

The auditor and the builder talk to each other through a single file. The auditor writes the file. The builder reads it. No human has to copy anything by hand.

What it caught when I tested it

Before I let the auditor near any real customer data, I tested it against a fake dataset I made up. I deliberately put broken stuff in the fake data. Here's what it caught:

• 60% of the matches were wrong. A column that was supposed to connect two tables actually only worked 40% of the time. The auditor labeled this as a hard failure. Dossier Builder would have run on top of broken matches for every record.

• One company was listed as its own parent. The auditor caught the loop and flagged that one row for repair.

• A revenue column that should never be used got picked. I put a column called Monthly Revenue Summary in the data and marked it as do-not-use. The auditor read the rule, skipped that column, and picked the right one (MRR) instead.

Each catch is the kind of thing that would have broken a real dossier.

The rule that makes it trustworthy

The auditor does math first, then asks the AI to make a call. Never the other way around.

Why this matters: if you let an AI compute numbers directly, it's roughly right most of the time and wrong in unpredictable ways the rest of the time. You can't tell which is which.

So the auditor does it like this. Step one: a small Python script counts how many records in column A have a match in column B. It writes the answer to a file. The answer is a real number. You can check it by hand.

Step two: an AI reads that file. The AI's only job is to look at the number and call it pass, warning, soft fail, or hard fail. The AI is allowed to have an opinion. It is not allowed to invent the number.

This is the load-bearing rule. The math is on disk. The AI is making a judgment call. You can audit either one.

The order matters too

The auditor checks things in a strict sequence. Each step has to pass before the next one starts.

• 1. Domains first. Figure out the real website for each company. Is it the brand site or the corporate site? Both? Neither? Some companies own multiple domains. The auditor uses a stack of tools to ground-truth this.

• 2. Joins second. Check the matches between systems. Throw out matches that don't survive a real test.

• 3. Revenue third. Pick the canonical revenue column. Skip the do-not-use ones. Make sure the picked column actually has data in it.

• 4. Sanity last. Look for impossible combinations. Customers with positive revenue but zero calls in six months. Columns nobody has updated in years. Self-referencing parent companies.

You can't flip this order. You can't compare revenue across two systems if you don't trust the matches between them. You can't trust the matches if you don't know which website belongs to which company.

What it costs to run

The math part is free. No AI tokens, no API calls. Just Python running on your laptop.

The AI part — eleven small AI helpers, each reading a different number and making a call — runs about $8 to $15 per customer-data folder. A real dossier build costs many times that. So the audit pays for itself the first time it catches anything.

— Jordan

Written with Claude Opus 4.7

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

Chapters

• 00:00 — Intro

• 01:00 — Why intent and personalization died

• 05:30 — The asymmetry engine

• 08:00 — The librarian who only buys in December

• 11:00 — Housecall Pro and the vertical data moat

• 13:00 — Aligning price to customer outcome

• 15:30 — FundraiseUp and the 7% animated heart

• 18:50 — A five-day edge on global resin

• 19:50 — Where this is going

A founder I know sells software to plastic manufacturers. Four thousand of them in the country. Eighty percent of the price of plastic is the cost of resin.

I asked him what he knew about the cost of resin that his customers didn't.

I know the price five days before they do.

Wall Street has paid billions of dollars to shave nanoseconds off the route between Chicago and New York. He has a five-day gap on a global commodity. I told him to stop building software and become a day trader.

That's the purest example of where AI go-to-market is going. It's also the one I want you to keep in your head for the next 800 words, because it's the only frame that makes the rest of this make sense.

The two dead memes

Intent data and personalization both invaded our culture for the same reason. Both of them are dressed up as caring about the buyer. Neither one actually was.

The original goal of intent was good. If you could only talk to the people who actually wanted to buy, that's all you'd ever do. The problem was the implementation. The category got built on de-anonymizing buyer traffic — a thing no buyer would ever opt into if you asked. The data was dodgy. You couldn't inspect it. And the message it produced was Hey Jordan, I saw you on our website. Nobody replies to that, because it's not a gift. It's a confession that the seller noticed you and a request that you reward the noticing.

Personalization went the same way. The B2C version is real. Instagram knows what you click. Amazon knows your size. That's good personalization. The B2B version is Hey Jordan, congratulations on the new role. If you knew I spent only a minute and forty-eight seconds brushing my teeth this morning, that would be a very personal piece of information. It would also have nothing to do with my desire to buy your product.

Both memes promised to close the information gap between seller and buyer. Both of them did the opposite. They asked the buyer to give up their privacy so the seller could send a slightly more clever pitch. The buyer figured that out years ago. The ad blockers are the receipt.

The asymmetry engine is what replaces them

I wrote the deep doctrine on this last week. Here's the one-paragraph version.

Sales is a power game. Power flows from information asymmetry. The seller wins when they know more about the buyer's actual situation than the buyer does. Pre-AI, only the top one percent of reps could pull this off — the ones who'd lived inside one customer for years. Post-AI, anyone with a customer corpus and Claude Code can do it across a hundred customers in an afternoon.

Your customer transcripts are sitting somewhere. Your back-end has a schema and a few hundred thousand rows. The public web around each customer is one Serper query away. None of it is in the LLM's training set. None of it can be replicated by the recruiter sending cheap labor in the Philippines, 40% off — and the recruiters sending that exact email outnumber atoms in the universe by a rounding error. They're competing in the saturation zone. You don't have to.

The asymmetry engine is the machine that turns your private corpus into messages that can't be replicated. That's the whole game.

Three companies that already do it

Roland runs a company called Housecall Pro. Their pros have worked on one in every three homes in the country. He's said that publicly. Think about what that means. If a new pro signs up tomorrow and ingests their customer list, the platform could turn around and say twenty percent of the homes you worked on, the homeowner has moved — go figure out where. And of the ones still there, nobody in our database has touched the HVAC since you installed it twenty years ago. Here's a twenty-thousand-dollar job per house. The neighbors are buying this specific unit.

That's not personalization. That's information the pro could not have produced themselves. It is programmatically delivered. It is the asymmetry engine running over a vertical SaaS data moat.

FundraiseUp is the second one. They collect donations for nonprofits. UNESCO is on the platform. Their founder told me on stage that they don't charge a flat fee. They charge a percentage of donations collected. So every lever they can pull always points the same direction — increase the customer's conversion rate.

He told me a story. Someone on his team noticed that if a donor switched from a one-time gift to a monthly gift, a little heart could animate up the screen. There was no PRD. No product manager pitched it. It was a twenty-minute build with AI. It moved monthly-donation conversion seven percent. The only reason that animation exists is that FundraiseUp's pricing made it the company's interest to find it. If they charged a flat fee, nobody on the team would have been looking.

That's what pricing aligned to customer outcome buys you. It buys you a team that's incentivized to find seven-percent levers all day.

The third one is the resin guy at the top of this post. He's got a five-day window on the eighty-percent input cost for four thousand customers' core business. Every customer interaction he has should start with here's what's coming for you in five days, no pricing yet, what would you do with it? The software he's building is the wrapper. The five-day window is the actual business.

Where this is going

Three things compound from here.

Vertical wins. It is much easier to build the asymmetry engine when you own one industry's data than when you sell a horizontal tool to engineers and lawyers and HR teams. The horizontal businesses I love still need a vertical wedge — a specific customer transcript pile, a specific schema, a specific public-web slice — or they cannot direct the model. Pick one.

Pricing aligns to outcome. When the customer wins more, you make more. FundraiseUp is the simplest case. Outcome-aligned pricing means every engineer on your team is hunting for the next animated-heart feature instead of waiting for a roadmap meeting. The companies that do this will lap the companies that don't.

Your moat is the data, not the workflow. The compliance review, the dashboard, the AI agent — all wrappers. The thing flowing through the wrapper is what compounds. A friend's company reviews real estate contracts and cuts compliance teams from eight to one. I told him: the contracts are the business. Every lender, title company, mover, lawn-care provider in those contracts would pay for what's inside. Sometimes you give the workflow away to mine the data.

The question to ask tomorrow morning

The question is not what would my buyer be persuaded by? The question is what do I know about my buyer's situation that they would pay to learn? If you can answer it specifically, you have an asymmetry engine. If you can't, you have an intent vendor in a new coat.

Open one of your customer's transcripts tomorrow morning. Pull the back-end schema for the table they care most about. Ask Claude to play the buyer at that customer and tell you the three things they would want to know. Read the answer. Push back twice. Ship the survivor as a gift — no meeting ask, no demo button, just the data.

You will know within a week whether the engine is running. The replies will tell you.

— Written by Claude Opus 4.7, Approved by Jordan

What Annual Adds

This one was free. Paid gets the build. Annual gives you the tools that run it.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder, Talent Sourcer. Whatever ships next is included.

• All 3 courses: Who to Target and What to Say, Agent 7, AutoClaygent.

• Weekly office hours.

Run /edge install asymmetry-engine once your license key arrives — the runnable mining loop from the Asymmetry Engine post drops into your Claude Code in one command.

License key hits your email.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

May 17, 2026 · Build log

Every CEO running a Claude rollout has the same question and no good way to answer it. Is our AI investment paying off? Who's actually shipping with these tools versus chatting with them? Which of the people not yet on the leaderboard should be there next quarter? The deployment report is how I answer that question for a client.

(If you read about the $67K bill that wasn't earlier today: that came out of this same skill. The deck this thing renders is what sat under the panic.)

Here's the public version of the deck I built for a healthcare org. Anonymized as Northwind Health, real client run, names swapped, KPIs ranged. Eleven sections. About a fifteen-minute read for the CEO.

→ Open the Northwind Health AI Deployment Report

Scroll it while reading the rest of this. The article walks through what each section does and how to point the skill at your own team.

The three inputs

Three things go in. One HTML page comes out in about thirty minutes.

One. An Anthropic chat-history export ZIP. Every Claude conversation your team had during the reporting window. Individuals export from claude.ai → Settings → Data privacy controls → Export. Org admins export from inside console.anthropic.com → Privacy → Export organization data — Anthropic has full instructions at privacy.claude.com on exporting org data. The ZIP arrives by email. Drop it in ~/Downloads/.

Two. Local clones of every git repo where your team ships Claude-assisted code. The skill walks every commit across every repo, attributes by email, separates partner commits from staff commits, narrates multi-repo cutovers in one line, surfaces the people writing real code from the people running chat experiments. For Northwind that meant two repos and four months of history.

Three. An Anthropic admin API key. Create one at console.anthropic.com → Settings → Admin API keys → Create new key. The format starts with sk-ant-admin-. Rotate it the second the run finishes — it stops being useful and shouldn't live anywhere long. Without it, the report tells the people-and-shipping story. With it, the report also tells the dollars-and-infrastructure story: total Anthropic spend, per-key concentration, dormant credentials, daily cost curve, whether prompt caching is on, whether the Claude Code OpenTelemetry exporter is wired up. Both stories together are what makes the deck CEO-grade.

Set the key in your shell, then run one command from the skill's root:

export ANTHROPIC_ADMIN_KEY=sk-ant-admin-...
bash run.sh ~/Downloads/data-<export-id>-batch-0000.zip --client <your-client> --publish

Thirty minutes later the deck lands at playbooks.blueprintgtm.com/<your-slug>, behind a JS password gate until you tell the team the code.

What's in the deck

Eleven sections, each answering a specific CEO question. I'll group them.

The first two answer "where are we." Section one carries anchor KPIs from the client's existing exec deck plus the headline gap underneath — for Northwind, 91 people use Claude regularly, 3 of them ship code. That gap is the story the rest of the deck unpacks. Section two charts the daily conversation curve and the top five contributors by volume: is usage compounding or flat, who's carrying the weight.

Section three is the money section. Daily Anthropic spend curve. Monthly totals. Per-key concentration. Dormant credentials. Prompt-caching status. Whether the Claude Code OpenTelemetry exporter is wired up (most teams: it isn't). For Northwind, the four-month bill was $2,564 across 9 API keys and 1 workspace, with a $671 spike on March 26 from a 5,090-account churn analysis run. Section three only renders when the admin API key was set at run time.

The first time I built this section I read the cost-report endpoint's amount field as USD. It's in cents. I missed the unit on the first pass and almost shipped a deck with the totals off by 100×. The full story is the companion piece to this article. The fix lives at scripts/cost_units.py — every cost-report read in the skill now routes through cents_to_usd(). If you fork this, do the same.

Sections four and five answer "who's shipping." Section four is a shipping-gap table: every chat-active user plotted against their commits, lines, and chat overlap, partners separated from staff, multi-repo cutovers narrated in one line. Section five is the leaderboard. Every active user gets a row — archetype pill, six-attribute radar, a verbatim conversation quote as evidence, and a two-sentence exec read of who they are. The six attributes — deep functional expertise, creative problem solver, organized and structured, driver, trusted peer, learns fast — each scored 1 to 5 against actual conversation evidence and commit subjects. The archetypes are descriptive, not evaluative: Builder, Frontier Explorer, Workflow Embedder, Methodical Operator, Coach, Power User.

Section six is the punchline of the people story. Functional AI Lead candidates. For departments that already have a federated AI lead, a featured "lead in action" card profiles them — what they built, what's working, what they should build next, what risk to manage. For departments that don't have one yet, a candidate pool: ranked names from the active users with rationale, risk, and a next-step recommendation. The CEO closes the deck with a short list of people to promote.

Sections seven through ten are the "what's repeatable" layer. Top projects — the ones where the team wrote knowledge files in, so a new hire can pick up the work. Theme map — what the team uses AI for, with top contributors per theme. Recurring use cases — the patterns where multiple people are repeating the same task, the obvious Tiger Team productization targets. Best prompts gallery — 12 exemplary prompts the team should already be sharing internally, each with a one-line "why this is good" rationale.

Section eleven is the action layer. 9 concrete moves the CEO should make in the next 60 days — 6 people-and-process moves plus 3 Anthropic-spend moves (the spend moves auto-inject when the admin API was set). Each move is one sentence. The CEO closes the tab with a punch list.

Every paragraph in the deck got polished by a second skill

Every LLM-generated prose block in the deck runs through a second pass before render. There's a skill called wtf baked in as pipeline stage 10_wtf_polish.py. It applies an editorial-frame discipline to every two-sentence user summary, every candidate rationale, every prompt-card rationale, every use-case description, the featured lead's profile, the CS advisory line. It kills the standard AI tells — delve, robust, leverage as a verb, em-dash plus negation, "X. Not Y." reversals, BLUF-at-the-end. It forces every bullet to translate engineering nouns into business outcomes the CEO actually cares about. Verbatim quotes, sample prompts, evidence citations, numbers, and names: never touched. Only the prose around them.

Why bake it in? The alternative is shipping a deck where every paragraph reads like it came out of an LLM, and the CEO closes the tab in 30 seconds. The wtf pass costs about $2 and 30 seconds per deck. There's no version of this skill that skips it.

Cost expectations and the discipline that catches mistakes

The full pipeline costs roughly $70 to $100 per client run. Sonnet handles the per-conversation passes and the rubric scoring (sync-parallel, ~$55). Opus handles candidate selection, the featured-lead profile, the use-case merge, and the wtf pass (~$15). Haiku handles an optional defensible-counts codebook assignment (~$5).

Every LLM stage routes through a pre-flight cost-guard at tools/llm-cost-guard/cost_guard.py. Under $100 estimated: print and proceed. $100 to $1,000: prompt for y interactively. Above $1,000: type the dollar amount as a --confirm-spend flag matching the estimate within $5. Above $10,000: type a second --i-mean-it flag. The tiers are hardcoded so a runaway can't sneak through.

The artifact

→ Browse the public Northwind Health deployment report

Scroll the whole thing. That's what the skill produces for any team that hands you a chat export, a few git repos, and twenty minutes for an admin key. The deck pictured above is what your team's looks like — point the skill at your inputs.

— Jordan

Written with Claude Opus 4.7

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr — https://edge.blueprintgtm.com/subscribe?utm_source=ote&utm_medium=tier-block&utm_content=annual · Start at $50/mo — https://edge.blueprintgtm.com/subscribe?utm_source=ote&utm_medium=tier-block&utm_content=monthly (most readers start here)

Read more

It's a Wednesday afternoon, 2:47 on the clock. I'm at my desk pulling four months of Anthropic billing + usage data for a client, and I'm about to send the CEO a deck that walks him through what his team spent on Claude this quarter. The deck has already rendered, and I open Section 03 — the part where I show him the costs — and I freeze.

The summary card at the top says total spend for the four-month window was $256,409.51. A quarter of a million dollars. Underneath, the chart breaks the spending out by day. The biggest single day, March 26, shows $67,129.87 (that was the day I was most active for the client—shit!). The next biggest, April 7, shows $25,348.28. The one beneath it, April 15, shows $21,063.70.

I read all of it twice. Then I read the summary card again. Two hundred and fifty-six thousand dollars.

I have a meeting with the CEO at 3:15 (not really, but Claude LOVED THE DRAMA). That gives me twenty-eight minutes to figure out how to tell him that his company spent a quarter-million dollars on Claude that nobody knew about and it was mostly me and my champion BTW.

So I do the panic move. I go back into Section 03 and rewrite the headline at the top. Where it used to say Cost forensic — Q1, it now says One day cost 50× what it should have. I add a red dotted line on the chart at $67,000 to pull the eye toward the spike. I write three bullet points underneath, the kind that pretend you noticed the problem all along and you already have a plan. I save the file and refresh the browser. Now the deck looks like I found a fire and I'm already putting it out.

Then I start putting the fire out for real.

I open a new file in the project and start writing a safety check. The idea is simple. Any time someone in our code is about to fire off a big batch of Claude calls, this check has to compute the estimated cost first and refuse to send if the number crosses certain lines. Under a hundred dollars, it prints the estimate and goes ahead. Between a hundred and a thousand, it pauses and asks the person to type y before it continues. Between a thousand and ten thousand, it makes them type the actual dollar amount as a command-line flag, so a typo can't silently authorize a four-figure spend. Above ten thousand, it demands a second flag on top of that — --i-mean-it. I save, I commit, and I move on.

Next I open the code that runs the agent swarm — the script that I now believe burned a quarter-million dollars over four months. There's a setting on the long block of instructions that Claude reads at the start of every job, called the system prompt. If you mark the system prompt as cacheable, Anthropic charges you full price the first time it sees it and then about a tenth of that on every repeat. The swarm sends the same system prompt thousands of times in a row. I turn caching on, save, commit.

Then I write the cost rules into our project's instructions file. Not once. Three times. One copy at the top of my home folder, so any Claude session anywhere on my laptop reads them. One copy in the main company repo, so any project there inherits the same rules. One copy in the agent swarm's own folder, so an engineer working only on that orchestrator can't miss them. Three copies means somebody who wants to skip the safety check has to override the rule in three different places. That's not a quiet mistake anymore.

Twenty-three commits later, forty-seven minutes have gone by. My phone buzzes. The CEO meeting has been pushed to tomorrow — he's in something else (also this is not true—BUT OH THE DRAMA CLAUDE).

I go back to the deck. I want to triple-check Section 03 before I send it. Just one last thing — I want to read the documentation for the page Anthropic gives me to check what I spent (TBH I just said, BRO SUPER CHECK THIS OUT). Just to confirm what the numbers on that page actually mean.

I open the docs. I find the description for the field that the chart and the summary card both read from. And I see this sentence:

"amount: string — Cost amount in lowest currency units (e.g. cents) as a decimal string. For example, '123.45' in 'USD' represents $1.23."

I read it three times.

The number isn't dollars. The number is cents.

I open a small new file. I write a tiny function that takes the number Anthropic's page hands back and divides it by a hundred. I run it on the spike row. $67,129.87 becomes $671.30. I run it on the next biggest day. $25,348.28 becomes $253.48. I run it on the summary card. $256,409.51 becomes $2,564.10.

The chart wasn't saying sixty-seven thousand dollars. It was saying sixty-seven thousand cents. The summary card wasn't saying a quarter of a million dollars. It was saying a quarter of a million cents.

The whole deck was off by the same factor. The chart and the summary card hadn't been disagreeing with each other — they had been agreeing, but in the wrong units. Every dollar number in Section 03 had a decimal point that hadn't been moved over two places.

I want one more check before I trust the corrected reading. The same page Anthropic uses to report cost also reports raw usage — how many tokens they billed, broken out by model. I add those up across the four months. About forty-four million Opus input tokens. Two-and-three-quarter million Opus output tokens. Four hundred and fifty-nine million Sonnet input tokens. Sixty-two million Sonnet output tokens. I multiply each row by Anthropic's published rate for that model, and I add the results up. The total comes to about $3,200. That's in the same neighborhood as the corrected $2,564 from the bill itself. The bill is real. The rendering was just off by two decimal places.

I revert the deck. The One day cost 50× what it should have headline goes back to Q1 spend forensic. The red spike annotation drops from $67,130 down to $671. The summary card drops from a quarter-million to $2,564. The bullet points come out. Section 03 now reads the way a normal cost forensic should read — one day in March with a $671 spike sitting among many days under $10. Still an outlier worth flagging, but at a sane order of magnitude.

Then I sit with the rest of it. The safety check. The caching setup. The three different copies of the rules. The twenty-three commits I made in forty-seven minutes for a fire that wasn't a fire.

I revert nothing else. Here is why.

—

The Anthropic billing page traps you with cents disguised as dollars. The field that returns the cost — the one every chart and dashboard and executive deck reads from — is in cents. The field right next to it says the currency is "USD", as if it were reassuring you. The first three times I read the documentation, my eye skipped past the example tucked inside the parenthetical that spells out the units. The wrong reading and the right reading look identical on the page — both show a number, a currency, a date. There is no warning on the chart that something is off. The fix is one division. The danger is that there is nothing in the data itself that tells you the division is needed.

Claude is bad at predicting what Claude costs. The deck-generation script that produced Section 03 was written by me with Claude. Every single read of the cost field — the chart, the summary card, the per-model breakdown, every dollar on every page of the section — went through code that Claude wrote and that treated the cents value as dollars. Claude did not catch the units. Claude could not catch the units. The same model I'd been using to write the script had no internal sense of what API costs are or what magnitudes are plausible. It will dutifully render whatever number an endpoint hands back, in whatever units, without flinching. If you are about to spend money on a Claude job, or about to tell anyone what a Claude job cost, you cannot ask Claude what the answer is. You have to compute it yourself, against Anthropic's published rates, before you send a single request or ship a single chart to anyone who matters.

The defaults that produced the misread are still bad defaults. The agent swarm was running on Opus, the most expensive model. It wasn't caching the system prompt, which means it was paying the full price for the same long block of instructions thousands of times in a row. There was no pre-flight cost check anywhere in the path. The actual four-month bill turned out to be small — about $2,500 — only because the client's workload was small. Run the same configuration against a workload a hundred times bigger — a customer-facing AI tool with 50,000 daily users, a production agent loop that runs all day — and the bill stops being small. It becomes the kind of bill that ends careers. The deck didn't show $256K today. The next deck can.

So I revert the deck. I revert nothing else.

— Jordan

Written with Claude Opus 4.7

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

I asked Claude to write me an exec brief on customer churn. It produced 3,214 words. The recommendation was on page 4. The action layer didn't exist.

This is what every LLM does. Generates. Piles. Buries the point under "comprehensive analysis." A CRO opens it, gives it 30 seconds, can't find what to do, closes the tab.

I rebuilt that brief by hand. Took the same 3,214 words and cut them to 1,180. Moved the recommendation to sentence one. Added a "So what" block under every section — specific verb, specific artifact, by when. Picked one chart out of the eight the LLM produced. Killed the rest.

The result was a 30-second read. Same insight. Cleaner.

I did this for the third time this week and stopped. The pattern was always the same. I was doing the same five operations every time:

1. Find what's important

2. Cut what doesn't need to be there

3. Surface what the reader will actually do with this

4. Specify how they take action

5. Reorder the whole thing so the answer is first

So I built it.

The five questions

That's the Editorial Frame. Every section of the input gets scored 1–5 on each question. Default verdict is `cut`. You only `keep` a section when it earns it.

The questions map to the canon every exec-comms expert agrees on. Tufte's data-ink ratio answers question one — what's important. Doumont's signal-to-noise answers question two — what needs to be there. The military's BLUF doctrine answers three and four — what to do, how to do it. Minto's Pyramid answers five — how it's layered, with the answer first.

That's the whole methodology. Five questions. No frameworks-on-top-of-frameworks. No PowerPoint templates. Just the question every executive is silently asking when they open the document: what do I do, why, and by when?

The lint engine

The skill runs lint on its own output. Not the kind you run on code. The kind that catches LLM tells.

Twelve patterns the model loves and a CRO hates. Any hard hit blocks publish:

reversal cliffhanger      The X wasn't the Y. The X was the Z.
antithesis tic            It is not just X, it is Y.
throat-clearing opener    "In today's...", "As we all know..."
recap signature           "In summary", "To recap", "Key takeaways"
filler transitions        "Having said that", "With that being said"
rigid optimism close      Despite-its-challenges-X-faces-an-exciting-future.
imagine-a-world opener    "Imagine a world where..."
magic-adverb verbs        "quietly transforms", "fundamentally changes"
vague attribution         "studies suggest", "experts argue"
schema leaks              Internal vocabulary in customer-facing prose
inline code chips         Single-line backtick chips scattered through paragraphs
em-dash overuse           > 0.15 per sentence (GPT-4.1 uses 3.3× the human rate)

Plus the AI vocabulary — the words every LLM reaches for and no executive uses:

delve, leverage, robust, seamless, holistic, synergy, paradigm,
empower, harness, streamline, cutting-edge, best-in-class, ecosystem,
game-changer, unlock, elevate, disrupt, tapestry, landscape, notably,
moreover, furthermore, utilize, underscore, pivotal, transcend, navigate,
testament, realm

Any hard hit fires the block. One auto-retry with the lint output piped back into the rewriter. If it fails twice, the skill halts and surfaces the failing draft to me with the hit list. I either edit or override with a written reason. Never silently bypass.

The chart agent

Most LLMs produce charts the way they produce prose. Too many. Mostly decorative. Sometimes misleading.

I gave the chart job to a dedicated sub-agent that reads Tufte first. Twelve rules, applied in order. First match wins:

• Single number, no comparison → no chart (doesn't beat the sentence)

• Two numbers, simple ratio → no chart (bold the numbers in prose)

• Prose already carries the comparison ("37% vs 12%") → no chart

• Time series, 5 points or fewer → sparkline inline

• Categorical, 7 categories or fewer, ranked → horizontal bar, sorted descending

• Categorical, 8 to 25 categories → dot plot (Cleveland: position beats length beats angle beats area)

• Anything pie-shaped → bar chart. Always.

• A chart is required only when removing it loses information the prose can't carry

The agent has read Cleveland on perceptual encoding. Stephen Few on chartjunk. Bertin on visual variables. Cole Nussbaumer Knaflic on attention. Alberto Cairo on truthful visualization. Not as decoration. As constraints.

If charts are required, the skill upgrades the output to HTML automatically. A warning prints. The reader gets the brief styled like the playbooks at playbooks.blueprintgtm.com.

What it doesn't do

It doesn't generate AI hero images. Stock-illustration energy has no place on an exec brief.

It doesn't add words to feel "complete." Length isn't depth. The hard cap is 60% of the original word count. Output bigger than 65% gets re-fired with "cut harder."

It doesn't write what the reader already knows. Methodology sections are the first thing the editor agent flags as `cut`.

It doesn't mention itself in the output. The polished brief is the brief — not a meta-document about how the brief was produced. The reader has never heard of this skill and doesn't need to.

The customer voice problem

Generic exec briefs feel like they could apply to anyone. The fix is the customer's actual words.

My internal version pulls the last meeting transcript from my Sybill stash for whatever company the brief is about. The voice rewriter weaves the customer's specific concerns and vocabulary into the rewrite. The CRO reads it and thinks "this is about us, not a template."

Subscribers don't have my Sybill access. So the version shipped today takes a flag: `--transcript path/to/meeting-export.md`. Drop in any meeting file — Sybill export, Gong, Otter, Fathom, raw notes, anything text — and the skill ingests it as customer-voice context.

The output lands as a local file. The polished markdown copies to your clipboard automatically. Paste into a Google Doc, Substack, email, Slack. Whatever your delivery surface is, it's already on your clipboard.

What I learned

Most "AI bloat" isn't an AI problem. It's an editorial problem we never solved.

Humans have been writing bloated exec briefs since before LLMs existed. The 60-page consultant deck for a one-sentence recommendation. The "executive summary" that's longer than the substance below. The chart that exists because the slide needed three charts.

What LLMs did is industrialize it. The bloat got cheap. The volume went up. The editorial cost — the cost of a real human cutting the thing to what matters — stayed the same.

The skill is what happens when you make the editorial discipline mechanical. Five questions, applied every time. Lint that blocks the LLM tells. A chart agent that knows when not to make a chart.

The 30-second window is the only thing that matters to your reader. Build for it.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A founder showed me his dashboard.

He runs an AI tool that watches alcohol ads for large consumer brands. White Claw. Aperol. Suntory. The thing scans a video, flags music it can't license, flags any frame that implies the drink is solving someone's anxiety, flags whatever six dozen things a Czech regulator can sue you for. He'd just gotten his first wave of customers and was setting up cold email for the first time. He led every email with a screenshot of his dashboard.

I told him to scrap the screenshot.

Same week, a guy on the call before him runs go-to-market for a lending infrastructure startup. Eighteen customers. Six-figure ACVs. Each customer launches a few products a year — credit cards, buy-now-pay-later, personal loans. He's tried everything. PQS-style outbound. Signal scraping. Predictleads jobs. He can find the companies that announced new lending products. He just can't get a reply.

Both of them are stuck. Both of them are working hard. Both of them are about to learn the same thing, which is that pain segment isn't the deepest move I teach.

It's an application of the deepest move I teach.

The deepest move is information asymmetry. Manufacture more information about the buyer's situation than the buyer has. Then deliver the insight as a complete gift the buyer can use without ever replying to you. Pre-AI, only the top 1% of reps could do this — the ones who'd lived inside one customer for so long they basically became them. Post-AI, anyone with eighteen customer transcripts and Claude Code can do it across an entire customer corpus in a long afternoon.

I'm calling the system that produces it the asymmetry engine.

Pain Segment, PVP, PQS, Working Backwards, Old World vs. Jordan's World — the whole framework lattice you've been reading from me for the last year — they're all applications of this single underlying move. I want to lay it out end-to-end. The law that runs underneath. The four moves that flip the game. The mining loop you can run on your customer base this week. And the way the existing frameworks slot in once the master frame is clear.

This one's long. Pour another coffee.

The Asymmetry Law

Sales is a power game. Power flows from information asymmetry. Whoever knows more about the buyer's actual situation has the upper hand. That's the whole thing.

Most reps lose this game on day one. They walk in with a deck. The buyer walks in with their actual job, their actual quarterly number, their actual fired-CFO ghost, their actual lawsuit they almost lost in Q2, and the ten Slack threads about whether the thing the rep sells will save them or get them fired. The buyer has more information than the rep. The asymmetry runs the wrong way. The pitch fails. The rep blames the copy.

Top-1% reps have always inverted this. They've sold to enough people in the same role to know, before the buyer opens their mouth, what the buyer is going to say next. They know the lawsuit. They know the number. They know the ghost. When the buyer talks, they're not gathering — they're confirming. That's why those reps close.

The catch was always that you had to spend years being them to know them. The German entrepreneur I always think about wanted to start a dental billing company. So he found a dentist in San Francisco and worked for free for six months filing bills. He learned that molar replacements are the most common thing a dentist invoices. He learned every step of the process from the inside. Then he built software that replaced his job. His first customer was the dentist he'd been working for. Every other customer felt like he was reading their mind, because effectively he was.

That used to be the whole skill. Live inside one customer until your guesses about every other customer were ground truth.

It isn't anymore. The asymmetry engine is what replaces it.

The god-customer question

The new question — the one nobody could ask before language models — is this. If your buyer were a god, with infinite reach, and they had access to everything you know about every customer who came before them, what would they ask?

Not what's their pain. Not what's their persona. Not how do I personalize the second line of the email.

What would a god-buyer want to know?

I asked the lending-infrastructure guy this on the call. He had eighteen customers. They'd launched somewhere between two and four products each. That's roughly seventy product launches across his platform — credit cards, buy-now-pay-later, personal loans, refi products. Every single one had transaction data sitting in his database. Every single one had a story. Some of them died at six months. Some of them tripled the customer's portfolio. He'd never asked, across the seventy of them, what the launch-day signal was that separated the dead from the tripled.

A god-buyer would. A god-buyer doesn't care about his dashboard. A god-buyer wants to know: if I launch a credit card next quarter at 7% APR, what's my pickup curve going to look like, based on every other 7% credit card that launched on this platform?

That question wasn't askable in 2023. The data was sitting in a Postgres table. The customer was sitting in their office worrying about it. Nobody could connect the two without a six-month consulting engagement and a SQL analyst. Now you can connect them with a Claude Code session and a sample of the schema.

This is the move. Stop selling product. Start asking the god-buyer question.

Why AI made this not just possible but necessary

A buddy of mine is an AE at a payroll-and-benefits company. Top quartile of his team. He told me last week that the SDRs at his company aren't sourcing him pipeline anymore. They got replaced. Not by him. By Claude. The average AE got replaced too — the one who sends I saw you raised money, can I have some. The one who sends I noticed you're hiring a benefits administrator, our payroll product is the best solution. That whole tier is gone. AI does it now. Probably better. Definitely cheaper.

So the floor moved up. The bar to get a meeting got higher. If your message reads like the average AE wrote it, your message is competing with a robot army doing the same thing for free.

The only thing that beats the robot army is data the robot army doesn't have.

That's your customer interviews. That's your transaction histories. That's your support transcripts. That's the seventy product launches sitting in your back-end. None of it's on the public web. None of it's in the LLM's training set. None of it can be replicated by the recruiter sending the "I saw you're hiring, we have cheap labor in the Philippines" email — and let me tell you, the volume of recruiters sending that exact email is greater than atoms in the universe by maybe one rounding error. They are competing in the saturation zone. You don't have to.

Your customer corpus is the moat. It's the only moat that works in 2026. The asymmetry engine is the machine that turns the corpus into messages that can't be replicated.

That's the law. Now the moves.

The Inversion

The lending-infrastructure guy on the call asked me a fair question. How do you actually do this? Like, what's the practice?

The practice is four moves. Three of them are about how you think before you ever open a Claude Code window. The fourth one is the running. Today's article is about the thinking move-set, then the running. Let's start with the thinking.

The kidnap-engineer test

Imagine your customer broke into your office, kidnapped your engineering team, and got root access to your data. They can only do three things before the cops arrive. What are they?

Sounds insane. It works. The reason it works is that it forces you off your product and onto their actions. An engineer with access to your seventy product launches isn't going to look at your dashboard. They're going to write three SQL queries that answer what they personally need to ship next month and have nothing else.

For the lending guy, those three queries probably look like give me the pickup curve for every credit card we launched at 6.8% to 7.2% APR, normalized for issuer size. And give me the sign-up bonus value where pickup peaks and starts to flatten. And give me the personal-loan products that died inside six months and what they had in common.

Three queries. Three answers. Three messages he can ship to seventy companies that he knows are thinking about lending products this year.

That's the kidnap-engineer test. It's the inversion of the GTM question. You don't ask what would my buyer be persuaded by? You ask what would my buyer's most resourceful colleague steal if they could? Then you ship them what they would have stolen, without the kidnapping.

Inhabit the customer's mind

The quality of every piece of GTM work you do is set by how much of the buyer's mind you can inhabit.

I mean this almost literally. The German dental guy who worked at the dentist for six months — that's the gold standard. He went and lived inside the buyer until he stopped guessing. The reason he was the gold standard is that nobody else was willing to do it. Working at a dental office for six months for free is unpleasant. So almost no one did it. So the few who did had a permanent edge.

The asymmetry engine isn't a substitute for inhabiting the customer's mind. It's the only known way to inhabit a hundred customers' minds at once instead of one. You take every transcript a customer has ever recorded, every email a customer has ever sent you, every transaction in your back-end, and you ask Claude to act as this person at this company launching this kind of product. What questions would you ask of this data?

Then you read the answers. Then you push back. Then you ask three more times until the answers stop sounding like a robot puked them up. Then you go to a real customer — even just one — and ask, would you respond to this? And you listen to the no.

That's the inhabit step. The model is your speed. The customer is your ground truth. You need both.

The differentiation trap

The reason this matters more than ever is that everyone else is sending the same message.

A guy on the call last week wanted to sell a recruiting service. Cheap labor from the Philippines, 30-40% discount on hires. He asked me what he should write in the cold email. I told him not to send it. Every recruiting agency on Earth is sending the exact same email. I saw you're hiring a senior engineer. We can save you 40%. It's not that the offer is bad. The offer might be great. The problem is that the buyer has heard the same sentence eight hundred times this quarter. The message has zero differentiation. The buyer has no reason to read past the subject line.

The asymmetry engine breaks the trap by giving you something nobody else can say. Not because you're a better writer. Because you have data they don't have, and a question they couldn't ask, and an answer they didn't get last week from any of the eight hundred clones.

When you have that, the message practically writes itself. When you don't, no amount of merge-tag wizardry saves you.

That's the inversion. Now the engine itself.

Who Gets This

You've got the doctrine. Below the line is the build.

• Free: what you just read — the law, the inversion, why it matters now.

• $50/mo (most readers start here): the mining loop — the actual Claude Code prompt, the four data layers, the worked example for the lending case, the permissionless-gift template, and the way every existing framework I teach slots into this master frame.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder. Whatever ships next is included. Plus all 3 courses and weekly office hours.

Read more

A Series B healthcare AI company asked me last week to find them their next SDR leader. They wanted real candidates, not the resumes a recruiting agency would slide across the table for $50K and a 90-day clock.

So I built the recruiter instead.

The first version was a Sunday-afternoon hack. I pointed Blitz API at every company in my filter, fired the LinkedIn employee-finder against each one, ran the resulting candidates through Claude to score them, scraped fresh profiles with RapidAPI on the survivors. By Monday morning the team had a ranked Google Sheet with emails, phones, and per-person narratives. The recruiting agency would still be reading the JD.

That afternoon I kept thinking the same sentence over and over: this is a tool, not a one-off. So I rebuilt it as a Claude Code skill anyone with the right two API keys can run.

Annual subscribers install it now: /edge install talent-sourcer.

Why most recruiting pipelines lose

The default move when you're sourcing is to pick the 50 most obvious companies and search inside those. You list a few competitors, you add a couple of category leaders, you hit Apollo, you scroll.

That's the same move that makes outbound terrible. You sampled the universe — and the sample is small, predictable, and identical to whatever every other recruiter is doing the same morning.

Here's the thing: Blitz is flat-rate. $399/mo for unlimited people search and unlimited company search. The only constraint is queries-per-second — five for most accounts, twenty→fifty for agency tier.

So the architecture changes. You don't sample. You search every company that fits the filter.

For the SDR leader role, that meant 9,000+ NYC companies in the headcount band. The pipeline pulled every plausible person from every one of them. About four hours of compute on the slow tier. Thirty minutes on the fast one.

This is the asymmetry engine applied to hiring. Manufacture more information about every plausible candidate than the recruiting agency has, then deliver the ranked shortlist as a permissionless gift to the hiring team. They didn't ask for it. They couldn't have. You did the work.

The competitor bonus

Most scoring agents look at the candidate in isolation. Skills, tenure, trajectory, location.

I added one more dimension.

If a candidate works at a direct competitor of the company hiring, they get an automatic ranking boost. The agent flags it explicitly in the output.

This is obvious once you say it. A competitor's SDR leader already knows the buyer. They know the industry's objections. They probably know your customers by name because they've lost to them — or won them. They bring market knowledge a generic enterprise sales hire would need eighteen months to acquire.

Recruiters know this intuitively but rarely build it into the search. The pipeline does.

Score the company first, then the person

Here's the move that turned the A-rated list from "interesting" to "good."

Most tools score people in isolation. They don't know what the candidate's employer actually does.

A "VP Sales" at a 50-person healthcare AI company is a different human from a "VP Sales" at Oracle. Same title, same headline, almost no overlap in actual work. The first runs a pod of three SDRs and writes the messaging themselves. The second manages four directors and lives in QBRs.

Before the scoring agents see any candidate, the pipeline enriches their employer. Blitz pulls the company data — headcount, industry, stage. A separate worker downloads the homepage. Thirty companies in parallel. The scoring agent reads both and grades the person inside their actual context.

You stop seeing a list of titles and start seeing a list of people doing comparable work to the role you're hiring for.

What the team gets

The output is two URLs. A three-tab Google Sheet with the ranked candidates, the company context, and the search filters. A Google Doc with an executive summary and per-candidate narratives for the top thirty. Both shared "anyone with link can view" so the hiring team can read it on their phone before standup.

A recruiting agency for an SDR leader role is twenty to fifty thousand dollars and three months. The pipeline is two API subscriptions and an afternoon. You read the same shortlist either way — except the pipeline tells you which two of those candidates currently work at your direct competitor.

That's the trade.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 7, 2026 · Build log

Lauren is an AE at Ultromics. They make EchoGo — an AI that reads echocardiograms and flags two conditions doctors miss for years. Heart failure with preserved ejection fraction, and a stiff-heart disease called cardiac amyloidosis. The amyloidosis one is the bigger deal. Up to eighty percent of cases go undiagnosed. There are drugs that work, but only if you find the patient in time.

She sent me a 16-page doc. 163 hospitals across 13 western states. Specific titles she needed. ICD codes for the conditions her product catches. Drug brand names — Vyndaqel, Attruby, Amvuttra, the whole amyloid playbook.

She asked for 50 to 100 contacts.

I dropped the doc into Claude Code with one prompt — one-shot this, build it as a micro-app, push the result to a Sheet and email her. Then I went to make coffee or probably just dicked around online.

Thirty minutes later: 88 cardiologists, a Google Sheet shared with her, a Gmail draft sitting in my inbox. Done.

Then I looked at the data the build had produced along the way and got annoyed.

The architecture was wrong

Here's what the first pass did. For each of the 76 hospitals on Lauren's list, run a LinkedIn waterfall by leadership title. Director of Echo, Chief of Heart Failure, Amyloid Program lead. Match what comes back against a federal physician registry. Score each candidate. Send Lauren the top 88.

What the first pass also did, but threw away — pull every cardiologist in her 13-state territory from that federal registry. Score each one on Medicare prescribing data and pharma payment data. 9,668 cardiologists. 4,531 of them had at least one signal that said this person is treating amyloidosis or HFpEF right now. 50 of them scored at the ceiling — confirmed Tafamidis prescribers, paid by Pfizer or BridgeBio for it, also writing the heart-failure pills that go alongside.

The first pass kept 88 of those 4,531 and threw out the other 4,443. Why? Because I asked it to start from the hospital list and walk to the people. So if a cardiologist's hospital wasn't well-indexed on LinkedIn, or if Blitz's company-page database had a stale slug, or if the title-match threshold was tuned a hair too tight, the entire human disappeared from the output. Even the ones who were named on the relevant pharma company's "doctors we paid this year" public file.

A LinkedIn waterfall with no LinkedIn page is no waterfall at all. It's a sieve with no holes.

The fix

Flip the architecture. Start from the people, not the buildings.

Pull every Medicare cardiologist in the territory. Score each one on three signals:

Signal 1: Did they prescribe Tafamidis or Acoramidis through Medicare Part D?
Signal 2: Did they take pharma payments tagged to ATTR-CM drugs from
          Pfizer, BridgeBio, or Alnylam?
Signal 3: Did they prescribe Jardiance or Farxiga, the SGLT2 inhibitors
          that anchor HFpEF treatment?

Each signal is worth one to three points. The ceiling is eight. Then take the top 4,614 — everyone with at least one signal — and look them up on LinkedIn one at a time, by name, against the company page of any hospital they appear at. Tier them by signal score and title fit.

Same data sources. Same APIs. Different starting point. The result was 4,614 cardiologists instead of 88. 745 Tier A. 1,088 Tier B. 2,781 Tier C. 4,613 with a verified practice phone. 505 with a direct cell on top of that. 162 with a verified work email.

The 48 highest-scoring contacts include three cardiologists at Houston Cardiovascular Associates — Arvind Bhimaraj, Joggy K. George, and Barry Trachtenberg — who collectively wrote thousands of Tafamidis prescriptions through Medicare last year. There is no world in which Lauren's product is not relevant to those three people. EchoGo's whole pitch is we will help you find more amyloidosis patients before they need a heart transplant. Bhimaraj's day job is running the heart transplant program.

The first pass missed all three of them.

The data layer is the unfair advantage

Three federal data sets sit underneath this whole thing. None of them are gated. None of them are expensive. All of them have been sitting there forever.

NPPES         — every licensed physician in America, with name,
                address, specialty, phone. 9,668 cardiologists in
                Lauren's territory.
CMS Part D    — every Medicare-paid prescription, by physician,
                by drug brand, by year. Tells you who actually
                prescribes Tafamidis vs. who just talks about it.
Open Payments — every dollar pharma paid each physician, tagged
                to product. Tells you which doctors are believers
                deep enough that Pfizer paid them to teach others.

Most "AI lead list" tools don't touch any of these. The people who build them grew up in B2B SaaS where the data layer is Apollo, ZoomInfo, LinkedIn scraping. That's the whole stack. They've never met an NPI number. They look at a LinkedIn profile that says Cardiologist and call it a day.

For healthcare, that's a five-out-of-ten signal. The ten-out-of-ten signal is this person prescribed Vyndaqel forty-three times last year and Pfizer paid them eight thousand four hundred dollars for it. That cardiologist is, with near-certainty, treating amyloidosis patients today. They don't need to be convinced the disease exists. They need a better diagnostic tool.

That's what Lauren sells.

What the micro-app looks like

The whole thing lives at tools/ultromics-echogo/ in my repo. Eight stage scripts plus the v2 reroute. Three YAML data files — the hospital list, the title cascade, the clinical-signal config. One orchestrator. Re-runnable quarterly when Lauren's pipeline shifts. Forkable for the next medical-device AE who hands me a similar brief — change the specialty taxonomy, swap the drug list, point at a new territory, ship.

Six stages, in order:

1. Load 76 target hospitals from her doc, drop the 7 already
   in pipeline.
2. Pull the Medicare cardiologist roster for AZ + CA + NV + OR
   + TX + 8 extended states. 9,668 names.
3. Attach Part D + Open Payments + SGLT2 signals. 4,531 light up.
4. Look each one up on LinkedIn by name, against the hospital
   their NPI registers them at. Loose name match — first-and-last,
   not full middle-initial — because cardiologists register their
   NPI with full middle name and LinkedIn shows first-last.
5. Send the top 4,614 to a judge. The judge is Claude Opus 4.7.
   Each candidate scored on title fit, program fit, signal
   strength. Tier A / B / C / drop.
6. Find phones and emails. The federal registry already has
   the practice phone for everyone. Layer FullEnrich on top
   for direct cells. Use Blitz reverse-lookup on the LinkedIn
   URL for emails.

Total wall clock for the v2 run: about an hour, mostly waiting on the federal data exports and the third-party phone enrichment polling.

The interesting part is not that this works. The interesting part is that it works as a per-client micro-app, not a generic lead-gen tool. Lauren's territory, Lauren's titles, Lauren's drug list, Lauren's exclusion list. The next AE who walks in with a niche brief and a federal registry I haven't met yet — say, a fire-safety vendor with a state OSFM roster, or an electrical-permit prospector with municipal license data — gets the same skeleton with the data layer swapped. That is the unlock.

The data layer is the thing. If you are building leads for a niche where there is a federal or state registry — physicians, contractors, lawyers, real-estate agents, truck operators, fire marshals, any of them — and you skip that registry in favor of let me scrape LinkedIn, you have already lost. Someone else will pull the registry one day and beat you.

For Lauren, the win was specific. She has 4,614 cardiologists today she did not have yesterday. 745 of them are exactly the kind of physician EchoGo was built for. 48 of them are at the ceiling — confirmed amyloid treaters with pharma checks to match. She is going to call them this week.

The data layer made that call possible.

— Written by Claude Opus 4.7, approved by Jordan

Below is the geeky version. The paste-into-Claude recipe that rebuilds this whole thing for whatever niche you are working on — assuming there is a federal registry underneath it.

Or skip the rebuild. Annual subscribers install the tool I actually shipped with one command. Every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

My friend Matt Braley was at Chili-palooza last week with me.

He texted me. He wanted to see Claude.

Most people, when they say that, they want a demo. Watch me type a prompt. Watch the cursor blink. Watch a paragraph of marketing copy appear. Then they nod. Then they go home and don't change anything.

That's not what I do anymore.

I told Matt to come over. We sat down. I opened my laptop. I said, "What do you actually need."

He's a CRO. He sells big-deal vertical SaaS, and he advises a portfolio of AI companies. He was at a conference and wanted to follow up with people. He wanted leads — not in general, leads scored against him.

Sixty minutes later he walked out with one Google Sheet. Three tabs. Every tab was a working list he could call on Monday, all three graded against the same one-page rubric of who Matt actually is.

This is what showing Claude looks like now.

The three tabs

First, the rubric. Before any of the three tabs, we built one file: matt_profile.md. I pasted in his LinkedIn, then ran three sub-agents in parallel to enrich what was missing — his AI advisor portfolio, his investor network from Stage 2 Capital, his exit history at EngageSmart. The output was a one-page profile of who Matt is, who he's already talking to, and what kind of person it would be a waste of his time to meet.

Every score on every tab grades against that file. Same rubric, three populations. That's the only reason any of this means anything.

Every attendee at the conference, scraped and enriched

Matt sent a screenshot. Some WhatsApp group from the conference had dropped a link: ████████████████████████████.lovable.app. Chili-palooza had built a Lovable app that listed every attendee — name, company, title, LinkedIn URL, all alphabetized A through Z.

Claude OCR'd the URL out of the screenshot. Loaded the Lovable app. Walked every letter section A–Z. Pulled 138 attendees into a CSV with name, title, company, and LinkedIn.

Then enrichment. For every attendee Claude pulled the full LinkedIn profile via RapidAPI — work history, location, headline, photo. Then the company side: what the company does, headcount, funding stage. Then FullEnrich for cell phone and personal email on every row.

That's one tab. 138 humans, every one of them with a phone, an email, a LinkedIn, a company description, and a photo. Matt didn't make this. He didn't pay for this. Chili-palooza handed him an A–Z directory and we turned it into a contactable spreadsheet in about fifteen minutes.

Every Series A–D vertical SaaS startup that raised in the last year

This tab has nothing to do with the conference. This tab is about the rest of Matt's year.

I host 501 public go-to-market playbooks at playbooks.blueprintgtm.com. Every one is a real vertical SaaS deal I've worked or modeled — the company, the segment, the pain, the data signal. Three years of pattern library.

I asked Claude: take all 501. Filter to the ones where the company itself raised Series A through D in the last twelve months — that's Matt's investing band. Find the CEO, the founder, the CRO, the president. Find their email. Find their phone. Score every one of them against Matt's same rubric.

It's an eight-stage pipeline. Each stage writes a checkpointed CSV so I can re-run any step. Stage 1 loads the 501. Stage 2 hits Exa for funding news on every domain and uses GPT-4o-mini to extract the round and date — 501 in, 54 out. Stage 3 resolves each surviving domain to LinkedIn via Blitz. Stage 4 runs Blitz's waterfall to find every CEO, Founder, CRO, and President — 169 contacts stacked across the 54 companies. Stage 5 enriches each contact's LinkedIn profile via RapidAPI. Stage 6 finds email and cell phone for all 169 — Blitz first, FullEnrich on the misses. Stage 7 grades every one with Sonnet 4.6 against Matt's rubric — fit score, fit band, the talking point. Stage 8 writes a tab on the same Google Sheet.

Matt's not getting a list. He's getting an ordered queue. The top is the call he should make Monday morning. The bottom is the people he should skip. Every row already has the talking point. He doesn't have to think about it. He has to dial.

Every conference attendee scored against Matt — five swarm agents, six minutes

Back to the 138 attendees. Out of 138 people, who should Matt actually walk up to.

This is where I stopped touching the keyboard and let agents do it. Blueprint Swarm: five Opus sub-agents in parallel, each one given Matt's profile and a chunk of the attendee list. The job for each sub-agent — read this attendee's LinkedIn, read Matt's rubric, score the fit 1–10, label it high/medium/low, write the reason, write a one-line conversation starter Matt could literally say to them at the bar.

Five agents, 138 attendees. About six minutes wall-clock.

Output: 33 high, 65 medium, 40 low. Every row had a paragraph of reasoning and a tailored opener. "Curious how you're thinking about attribution for AI-driven outbound at Upside — at EliseAI we're wrestling with how to credit pipeline when an agent is doing 80% of the touches. Where does Upside draw the line?" That kind of opener. Specific to that human, written by an agent that had read both their LinkedIn and Matt's bio.

Then Claude built a mobile-responsive HTML leadbook out of it. Photos, filters by tier, click-to-call, click-to-email, the conversation starter visible right on the card. Modeled after a leadbook I'd built for a previous client. Published it live with the publish-html skill so Matt could open it on his phone walking into the next session.

That's the third tab — same data, ranked, with the talking point.

What this is not

This is not a demo.

A demo is when you show someone the tool and they leave with a story. "Jordan showed me Claude. It was cool."

This is when you show someone the tool and they leave with the work. "Jordan and I built three lists. I'm calling forty of these people on Monday."

The difference is whether the thing you made survives the meeting.

Most demos don't. The screen goes dark. The slides go away. Nothing changes on Monday. ← OPUS LOVES THIS FUCKING PATTERN!

What we did survives because Matt has it on his laptop. He has the GitHub repo — I invited his braley-ai handle so he owns the code. He has the Google Sheet shared to his email. He has a published HTML leadbook on his phone. He has a license to re-run the whole pipeline next time he goes to a conference.

The asset doesn't depend on me being in the room.

The hour

I want to be specific about the hour.

We didn't write any code by hand. I didn't pull up a notebook. We didn't open a Python file together.

I told Claude what we were doing. Claude scraped the Lovable app. Claude built the enrichment pipeline. Claude spun up the swarm. Claude wrote the HTML leadbook. Claude built the eight-stage playbook pipeline. Claude pushed every output to the same Google Sheet and to a published page.

I sat next to Matt the whole time and narrated. "OK now we're scraping the directory. Now we're enriching contact data. Now the swarm is reading his profile. Now we're scoring 138 people against him in parallel."

Matt didn't need to learn anything. He needed to see the shape of it.

That's what showing Claude is. You sit next to someone. You tell the agent what you both want. The agent builds the thing. The other person watches the shape of the work and goes, "Oh. That's how this is supposed to feel."

Why I'm writing this down

Because most of you, when somebody asks to see your tool, you still do a demo.

Stop.

Ask them what they need. Build it while they watch.

If you can't build it in an hour, your tool isn't ready. If you can build it in an hour and you're still doing slide decks, your job isn't selling — it's stalling.

The shift is small and total. Demos are about you. Builds are about them. One ends with a thank-you email. The other ends with three tabs, a published leadbook, and 169 vertical SaaS CEOs already scored against your rubric.

Matt's calling forty people on Monday. He didn't see Claude. He used it.

That's the only version of "showing Claude" I do anymore.

What Annual Adds

This one was free. Paid gets the build. Annual gives you the tools that run it.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor. Whatever ships next is included.

• All 3 courses: GTM Engineer, Pain-Qualified Segments, The Inversion.

• Weekly office hours.

Run /edge install agent-swarm once your license key arrives — the swarm I used to score Matt's 138 attendees drops into your Claude Code in one command.

License key hits your email.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

May 6, 2026 · Build log

Your ICP is lazy.

"50 to 1,000 employees in vertical X." That's not an ICP. That's an Apollo filter. You've described a list of companies the same way Apollo describes a list of companies, and you've told yourself you've done strategy.

The companies that write you the biggest checks and stay the longest don't share a headcount band. They share a situation. A specific operational thing that happened to them six to eighteen months before they bought, that almost nobody else on the filter is going through right now. That's the actual segment. Headcount and vertical are how Apollo organized the world. They're not how your customers feel pain.

So I spent the day building a skill that does ICP the other direction. You start from the outcomes you already have — your wins, your losses, your healthy accounts, your churns — and you reconstruct what those companies looked like before they bought. You hunt for signals you can pull from public data that distinguish good-fit from bad-fit. You ship a per-archetype scoring rubric instead of a one-line firmographic.

It's called `win-loss-rewind`. Annual subscribers can install it today. Below is the story of building it.

Outcomes first, hypotheses later

The old workflow: someone in marketing writes "we sell to mid-market HR teams in financial services," everyone nods, the SDRs go work the list, and three months later half the closed-wons are credit unions and the other half are insurance brokerages and nobody's HR team makes the buying decision. The ICP didn't predict anything. It just sounded reasonable.

The new workflow inverts it. You take the customers you actually have, label each one with the outcome that matters — won, lost, healthy, churned, expanded — and treat that as ground truth. Then you ask what those four buckets had in common before you ever spoke to them. Not what they look like now. What they looked like when they walked in.

This is the move Munger's been on his whole career. Invert, always invert. You don't ask "what makes a customer good?" — that's the question that gives you "mid-market vertical X." You ask "what was different about the customers who won versus the ones who didn't?" That question forces specificity. There's always a difference. Sometimes the difference isn't even something you'd have thought to look for.

Distrust your own data first

I almost shipped this thing without Phase 0 and it would've been useless.

Here's what kept happening on test data. The CRM record says "$50K ARR, healthy customer, expansion in flight." Cool. Then I run Firecrawl on their domain and LinkedIn enrichment on their org and discover the company has one employee, no working website, and the LinkedIn page hasn't been updated in two years. That's not a customer. That's a CRM record. Whoever logged the deal moved on, the account auto-renewed once, and now the system thinks they're a healthy expansion target.

You can't build an ICP discriminator on top of records like that. The training data is poisoning the answer.

So Phase 0 of the skill is just sitting on the data and not trusting it. It cross-references CRM labels against external reality — does the company exist on LinkedIn, does the website resolve, does the headcount match what the CRM thinks. Anything that fails gets quarantined. The operator gets a `data_confidence.md` to review and approve before the rest of the pipeline runs.

This step isn't glamorous and most teams skip it. It's also the step that determines whether the rest of the work means anything.

What the deliverable actually looks like

Skip ahead to what comes out the other end. Here's a real example from the fictional GRC SaaS test fixture I shipped with the skill — a compliance-automation product with two customer archetypes hidden in the data:

Archetype: Two-state legal-ops shop,
           no in-house engineer

Signal 1: State professional registrations
          in prior 18mo
  Source:     state SoS portal
  Threshold:  >= 2
  Weight:     0.55
  Lift:       4.1x train / 3.6x holdout

Signal 2: Compliance/GRC role posted
          in prior 6mo
  Source:     Firecrawl careers (keyword)
  Threshold:  present
  Weight:     0.45
  Lift:       3.5x train / 3.2x holdout

Combined fit_score
  = 0.55 * I(reg) + 0.45 * I(role)

"Looks like archetype" threshold:
  fit_score >= 0.60

That's the ICP. Two operational signals from public data. A weighted score. A threshold. A measured lift on training data and on a held-out 20% you didn't show the model.

Look at what's not in there. No headcount band. No vertical. No revenue range. None of the things you'd find on an Apollo filter. Because none of those things actually distinguish good-fit from bad-fit for this archetype. What distinguishes them is did this company recently expand into a second state and hire someone to own the compliance work that follows. That's the pain segment. Everything else is noise.

The other archetype in the same fixture comes out totally different — engineering-shops who built their own compliance code internally, then watched their compliance-tagged GitHub repos go quiet for nine months because the engineer who maintained them moved on. Same company-stage. Same revenue band. Completely different signal recipe.

You'd never write the ICP "compliance-tagged GitHub repos went quiet for nine months" by hand. You'd never think to. The skill writes it for you because it works backward from who actually won.

The vowel-name signal that died at holdout

Here's the moment I trust the work.

When the skill generates hypotheses about what distinguishes wins from losses, it generates a lot of them. Most are good. Some are nonsense. The hard part is figuring out which are which without a human reviewing every one.

In the test fixture, the hypothesis-generator coughed up something like "won customers tend to have company names starting with vowels." Apex, Atlas, Echo, Oak — four out of twelve wins, which on a small training set is a real-looking pattern. Train-set lift: about 2.4x.

It's also obviously horseshit. Company names don't predict buying behavior. The hard gates should kill it at Phase 5 because it doesn't prove pain — and they did, in this case. But suppose they hadn't. Suppose it slipped through.

Phase 6 is the safety net. You hold out 20% of your data from the start, never let any of the hypothesis-generation see it, and at the end you re-test every surviving hypothesis on the holdout. The vowel-name signal collapses to lift ≈ 1.0 on the holdout because it was a coincidence in the training set. Dead.

The real signals — state registrations, compliance roles — hold their lift on the holdout. Train 4.1, holdout 3.6. Train 3.5, holdout 3.2. They survive because they're not artifacts. They reflect actual operational pain.

This is the difference between an ICP you trust and an ICP you've fooled yourself into. You hold out 20%. You test on it. Anything that doesn't survive doesn't ship.

So what do I do with this

If you're staring at your own customer list right now and your ICP is some version of "mid-market vertical X," here's the move. Pull your wins, your losses, your healthy accounts, your churns. Get the outcome label honest — not what the CRM says, what actually happened. Then ask the question backward: what was different about the wins, six to eighteen months before close, in their public data?

Run that question with discipline. Hold out 20% of the data. Force every hypothesis through a "this proves pain, not just correlation" filter. Reject anything that uses headcount, industry, or revenue as the discriminator — those are inputs, not signals. The signals you want are the operational events that preceded the buying behavior.

That's the work. The skill automates it. But the discipline is what makes the answer real.

— Written by Claude Opus 4.7, approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

████████ shipped 297 changes to her company's code in four months.

She is not a programmer. She runs the team that keeps the sales data clean at a software company. Before January, she had never opened a coding tool. By April, she was the one wiring her company's sales calls into their customer records. She fixed 60 messy customer-name conflicts that had been broken for three years. She built a payout dashboard her partners now check every Monday morning.

I get asked, all the time: what does it actually look like after we “transform”? What does success look like?

Most of the AI talk lives upstream of that question. Here's the model. Here's the framework. Here's the prompt. Nobody shows the receipts twelve weeks later.

So I went and pulled the receipts. Three of my client companies. Three kinds of "after." Every change to the code. Every shipped piece of work. All of it written by people who six months ago could not have told you what code was. The names and the companies are blacked out — █ block letters, all the same width, so you can't count letters and figure out who is who. The numbers are real.

Here is what after looks like.

Story 1: The solo operator

████████ runs revenue operations at ████████████. One person. No coding background. She started shipping changes to the company's code on January 9.

Through April 29, she has been the second-most-active person in the entire company code base. The only thing ahead of her is a robot that runs the work she wrote. 297 changes across 404 code files. 98 of those changes added new things — actual new tools, not cleanups. She runs at a steady five-day-a-week pace. Two big spikes show up: late February when she rebuilt the company's master list of every potential customer, and early April when she fixed customer-record conflicts that had been blocking partner credit.

Here is the work, in concrete:

• A list of 69,747 customer locations. Pulled from public maps. Cross-checked against a federal industry registry. Joined to data on the people who run each location. 26.7% of locations now carry full operator records. Before her? They had a static spreadsheet. (to be fair, I built v1 of this)

• Customer record cleanup. The company had 1,100 active multi-location customers in their system. But only 616 of them — 56% — were correctly matched to their main customer database. After her cleanup: 798 matched. Target by quarter-end: 908 (82.5%). She manually fixed 60 messy cases where multiple cities shared a brand name and the database had stamped them onto the wrong company.

• A partner payout dashboard. Pulls live deal data. Calculates what each partner is owed under different tiers. Flags mistakes. Generates one view per partner and one big view across all partners. The company had been running this in a spreadsheet that someone updated by hand. She killed the spreadsheet.

• Six robots that run on a schedule. Daily refresh of customer data. Twice-a-day deal-name sync. Pushing account status to every contact at a company (not just the main one). Filling in missing contact names. Matching every recorded customer call to the right deal. Keeping payment data lined up.

• Monthly payment audits. She found and fixed billing data that had quietly drifted out of sync. The finance team did not know it was happening.

Total tools she now runs without help: their main customer database, their payment system, their call recordings, their team chat, AI models, cloud storage and computing, their data warehouse, spreadsheets, and their sales platform. She uses code that matches names that don't quite line up, code that makes lots of requests at once without breaking, and code for working with very large tables.

Her first session with me, on January 9, was getting the AI coding tool installed and pushing her first code change. She was uncomfortable using Terminal. She had never used the code-sharing system GitHub. By the end of the call, we had her pulling her company's call transcripts into a local folder. By February 4, she was running the customer uploads herself. By February 25, she was running the data-cleanup work weekly, on a schedule she set, without anyone telling her to.

Her CEO asks me, on a recent call: what's left for Blueprint to do here?

That is what after looks like for one in-house operator.

Story 2: The team that ships every day

The second company is different. Different industry — a regulated-services category with 33,560 possible customers. Different size. Different in one big way: it is not one person shipping. It is nine.

49 days. 283 changes. Nine different people. Five of them shipping in the same week.

Here is who is shipping what:

• The data-quality lead: 155 changes across 24 active days. Her job is checking contact info, syncing the sales platform, and keeping data clean. She pushed 7,875 of the company's 8,875 prospect accounts into a clean match against the regulatory ID system that governs the industry. Her checking process catches bad data 97.4% of the time.

• The marketing brand owner: 9 changes in 15 days. Brand voice. Messaging. Personas. Three custom marketing tools that other people on the team can now run.

• The sales-development lead: 15 changes in 16 days. A new quota model. Email cadences rewritten to sound like a real person. Lists of nearby customers to expand into. Outreach kits for people leaving a competitor that had a bad migration.

• The event coordinator: 11 changes in 7 days. Five major event briefs with confirmed venue and staffing details. Cleaning up event attendee lists. A small piece of code that joins clean emails back into the master list.

• The scraping specialist: 20 changes in 5 days. Tools that pull contact lists from state association websites. A recovery process that pulled out 14,067 contacts from old documents the previous tool had missed for years.

• The customer-stories owner: 2 changes in 1 day, setting up the next phase.

Plus the product analytics lead. Plus the executive sponsor. Plus me.

The output is not modest:

• 48,468 cleaned contacts in the master file, with 109 fields per contact.

• 1.2 million sales call records under analysis, going back six months.

• April outbound results: 897 prospects, 1,455 emails sent, 1,008 calls made, 83 meetings booked. A 9-out-of-100 prospect-to-meeting rate.

• Most recent week: A campaign targeting customers near existing customers — built two weeks before — has booked 10 meetings with sizable deal values from one tactic. The team's choice is to pour more volume into that motion instead of chasing a new one. That is what discipline looks like once a team can build its own pipeline.

• A document recovery tool I built at home for an unrelated reason. They picked it up the week it shipped. 10,000+ new contacts pulled from a state directory their previous vendor had been billing them not to extract.

This is the second kind of after. Not one star. A whole team. Every week. With version control, working sessions, and pull requests that turn into shipped tools that everyone else uses. Five people changing code in the same repo in a single week is not noise. It is a fundamentally different way of running a sales-and-marketing organization.

Story 3: The exec who builds

The third company is led from the top.

████████ is a senior leader at a software company. He has analysts. He has a revenue-operations team. He has the headcount to hand work off. He builds anyway.

71 days. 13 changes that he wrote himself — small compared to his team's total of 74, but every one of his is a structural piece. Pulling out shared code into reusable parts. Refactoring. Archiving 29 old scripts to keep the folder navigable. Building shared libraries that his analysts can run on their own.

His team's output during that window:

• Re-classified 38,117 companies in their master list using a free, open AI model running on rented computers that only spin up when needed. Total cost of the run: about $12. The classifier now correctly captures 60.6% of known customers (up from 54.9% in the prior version). The wrong-domain rate fell from 18.3% to 1.6%.

• Found 132 customers of a competing platform by guessing web addresses. The competitor's hosted product gives every customer a unique web address on the competitor's domain. He spun up 26 rented computers in parallel. They scanned 11.8 million five-letter guesses plus 48.5 million letter-and-number guesses. They found 223 active web addresses. Of those, 132 belonged to actual companies. Those 132 are now an account list nobody else in the market has.

• Lifted email coverage from 7.5% to 83.8% on 8,195 mid-size accounts. 618 emails became 6,864 emails. About $23 in tool fees, end to end. 4.5 hours of pipeline runtime.

• 101 sales call recordings turned into searchable text in three hours of compute for about $5.

Three plays. One leader who refused to delegate. The way of working now lives in his repo. Every analyst has access. The shared libraries he extracted will run forever.

He told me on a recent sync: he wants to roll the same tools out across the rest of the team. Everyone gets an AI subscription. The AI work isn't a special project anymore. It's just how the team operates.

What these three have in common

Look at the surface and they look nothing alike. A solo operator with no coding background. A nine-person team running a tightly-connected sales stack. A senior exec who codes. Different industries. Different stacks. Different team shapes.

The deeper pattern:

They ship every week. None of these is a one-time project. ████████ is on change number 297. The nine-person team has averaged about 6 changes a day for 49 days straight. ████████ is still pruning his code base for clarity. The work compounds because nobody stopped after the first wave.

They own the work in-house. I am not building any of this for them. I helped each of them get the AI coding tool installed for the first time. I am still on the weekly call. But every piece of work in every code base was written by their team, on their machines, against their data. The know-how stays with them. When I go away, they keep shipping.

AI is the substrate, not the feature. None of them talk about the AI in their meetings. They talk about the dashboard, the customer cleanup, the closest-customer campaign, the 132 hidden customers. The model is just there, the way electricity is there. It runs the pipeline. It writes the code. It cleans the data. The conversation is about the work.

Numbers run the room. Every meeting starts with a number and ends with a next step that has a number on it. 9 out of 100. 56% to 72.5%. 7.5% to 83.8%. 132 customers found. There is no fuzzy talk of "how the campaign is doing." There is the number, before and after.

This is what real AI go-to-market work looks like at week 16. Not a deck. Not a framework. A solo operator who can do the work of a team. A team that ships every day. An exec who refused to hand it off. All three are still going, every week, without me writing a single line of their code.

If you're reading this and thinking we don't have anyone who could do this on our team — you probably do. ████████ wasn't a programmer in December. By May she was the most-shipping human in her company's code base. The barrier was never talent. It was permission and a working session.

Show your team. Get the tool installed. Get out of their way.

What Annual Adds

This one was free. Paid gets the build. Annual gives you the tools that run it.

• Every tool I ship. Edge Copilot installs to your AI coding tool — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder, PDF Contact Finder. Whatever ships next is included.

• All 3 courses: Pain Segment, Permissionless Value Proposition, Pain Qualified Segment.

• Weekly office hours.

Run /edge install <slug> for any tool I've shipped — they all install the same way.

License key hits your email.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

A 798-page state fire marshal directory.

That's the test case. Every fire department in New Jersey. Names, titles, departments, emails, phones. Locked inside a PDF nobody can export.

Multiply that by every state and every industry. State licensing boards. Federal agency rosters. Trade association member lists. Conference attendee PDFs. There are tens of thousands of contact-rich PDFs sitting on government and industry websites right now, and every one of them is treated like a dead document.

They're not dead. They're a TAM list nobody has bothered to extract.

So I built the tool that extracts them. Today. End to end.

The naive way fails

Hand a 30-row contact table to any vision model. Ask for clean JSON. You get 58% accuracy. Sometimes worse.

I've seen this before. I built `video-list-extractor` last month — same problem, video frames instead of PDF pages. The vision model's attention degrades across a long list. Gemini in particular invents organization names. Claude is better but still drops names, swaps emails, normalizes "Dr. Sarah Chen, MD" to "Sarah Chen."

The fix is not better prompting. The fix is structural: crop each row into its own image, and OCR them one at a time. Same model. Same prompt. 99% accuracy.

That's the insight that made `video-list-extractor` work. It applies to PDFs.

The smart move: don't OCR what you don't have to

Here's the part nobody talks about: most contact-bearing PDFs aren't scanned. They have a real text layer. pypdf can read them at zero LLM cost.

The state fire marshal directory? Native text. The 798-page NJ fire department roster? Native text. I ran my triage script on both. Score: 1.0. Route: text path.

I extracted 5,080 raw contact records from those two PDFs in under a minute. Total LLM cost: zero. The merge step deduped them down to 2,015 unique contacts.

A run that would have cost $25 on the naive vision-everything path cost essentially nothing.

The triage decision is the entire game. Text-rich PDFs go to a regex + pypdf path. Scanned PDFs go to the vision pipeline — render the page, crop each row, dispatch parallel OCR sub-agents (waves of 5, 14 batches, the same architecture that drives `video-list-extractor`). Most PDFs only need the cheap path. Only scanned ones earn the expensive one.

The pipeline

Eight phases. Each one is a script the orchestrator runs in sequence.

1. Pre-flight — validate Serper + Exa keys, ask the user what industry and what fields they want.

2. Discovery — five sub-agents in parallel hit federal databases, state registries, industry associations, Google dorking patterns, and open-data portals. They write candidate PDF URLs to JSON.

3. Download — stream each PDF with a 30 MB cap, save to `/tmp/pcf_pdfs/`.

4. Triage — score each PDF's text quality, route to text path or vision path.

5. Contact-page detection — for big PDFs, identify which pages actually have contacts. Skip the table-of-contents and intro pages.

6. Extract — text path runs pypdf + regex; vision path renders each page at 200 DPI, crops contact rows by ink-density projection, dedupes the crops, and dispatches OCR sub-agents.

7. Merge — combine text-path and vision-path outputs, dedupe across sources, write a clean CSV.

8. Audit — sample random pages, run independent verifier agents, check coverage. Target ≥97%.

That's it. No magic. The structure carries the accuracy.

What it cost to extract 2,015 fire department contacts

Two PDFs. ~820 pages combined. Both routed to the text path.

• Discovery: skipped (I had the URLs)

• Download: free

• Triage: free

• Page detection: free

• Text extraction: free

• Merge: free

• Total: $0.00

If the same 2,015 contacts had come from scanned PDFs through the vision path, the run would have cost roughly $4-6. Still cheap. But the triage saved every dollar.

That ratio is the whole product. A run where 90% of PDFs are text-extractable costs 5x less than one where 90% are scanned. Triage is the lever.

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A software company asked me last quarter if I could find every landscaper and tree-care operator in the country.

They'd been buying lists from the usual aggregators for two years. The reps kept asking why the same companies showed up over and over. Why their best customers had never been on any of those lists in the first place.

So I ran my TAM research skill against the vertical. One pass.

38 sources surfaced. Foursquare alone had 97,043 unique landscapers and tree services with phones for 99.8% of them and websites for 64%. California's contractor licensing board had a free CSV download with every licensed landscaper in the state — 12,000 companies the aggregators had nothing on. Two trade associations had member directories totaling 5,400 of the exact companies that actually buy software.

And the one nobody thinks of: every state requires a pesticide-applicator license to spray weed and pest treatments commercially. Almost every professional landscaper holds one. So a "pesticide" registry — which sounds like the wrong vertical — is actually a 50-state public roster of the same landscape companies, maintained by law, free to download. That's the move you only spot once you stop searching for the company type by name and start asking what licenses the company is required to hold.

Combined, three of those sources got me to about 85% of the addressable market. For around $0 in data costs.

The aggregator they'd been paying $40K a year had captured maybe 60% of the same vertical, with no way to tell which 40% they were missing.

Why Most TAM Lists Miss the Market

When someone says "find me a list of X," the default move is to type "X" into ZoomInfo and ship whatever comes back.

That's not TAM research. That's giving up on 40% of your market and hoping the other 60% is enough.

Aggregators sell you the companies they happen to have. Government registries hold the companies that legally have to exist on a public list. Trade associations hold the ones that paid to be findable by buyers. Google Maps holds the ones that wanted local customers to walk in.

Those are different lists. They overlap maybe 50% with each other. Whichever one you start with becomes a ceiling on everything you do downstream.

The fix is to start with the question "where does the truth about this vertical actually live?" before you build the list. Most teams skip that step entirely.

What the Skill Actually Does

It runs five phases, in order, on any company type you point it at.

Phase zero is the kill switch. It validates every API key the run depends on before doing any work. Five keys, one fails, the whole thing stops. I built this in after a three-hour run died at minute 175 because Apify's token had rotated.

Phase one reads the client website silently. No questions to me yet. It pulls what they sell and to whom so the next phase can ask sharp questions instead of generic ones.

Phase two narrows. This is the only phase where it talks to me. Always to one company type. "Healthcare providers" is not a company type. "Ambulatory surgery centers" is. "Direct primary care clinics" is. The skill refuses to launch the discovery phase until the segment is narrow enough that a subagent can actually find every instance of it.

Phase three is five subagents in one shot. Federal registries. State licensing boards. Industry associations and niche directories. Google Maps and local business APIs. Open data and web datasets. Each one runs the same hour I run mine, just faster, and reports back in structured JSON with the same fields — what the source covers, how many records, websites included, cost, quirks.

Phase four scores everything. Same rubric across all 38-ish sources. Coverage 35% of the score. Websites included 30%. Data quality 20%. Cost 15%. Coverage and websites do most of the work because that's what determines whether you can actually run outbound off the list. The output is a ranked table plus a recommended two-or-three-source combination that gets you to maybe 85% of the market with minimal overlap.

The whole thing takes about 45 minutes and costs me $2 to $10 in API calls.

The Rubric Does the Hard Part

The thing that makes this work isn't the subagents. It's the rubric.

Without it, every research run becomes a personality contest where the most-cited source wins. With it, you can say "this licensed-contractor database covers 100% of the regulated population, has zero website fields, and is government-mandated, so it scores 70 — and Google Maps scores 74 because it has 80% coverage but every record has a website." Then you stop arguing.

The rubric also forces the obvious next move: combine the high-coverage no-website source with the medium-coverage high-website source, dedupe on phone number, and you've got more reachable companies than either source alone. That combination is what the recommendation table gives you.

Government data wins ties because the data quality is government-mandated. If a company is required by law to be on a list, the list is more complete than anything someone is selling. Most teams forget this.

Why I'm Releasing It Now

Every time I take on a new client, the first hour is some version of this same workflow. Pull their site. Narrow the segment. Fan out across federal, state, association, local, and open-data sources. Score what comes back. Pick the two or three sources that get me to coverage. Hand the build off.

Doing it five times burned the methodology in. Doing it twenty times made me write the skill. Doing it a hundred times made me realize that most teams have never seen the methodology at all — they're still typing the company type into ZoomInfo and hoping.

So it's going up.

— Written by Claude Opus 4.7 (1M context), Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

May 2, 2026 · Build log

A client asked me last month to find every company using a specific warehouse management system. Not "companies that might use it." Every confirmed customer — with proof.

I started where everyone starts. BuiltWith. G2 reviews. Job postings mentioning the product name. LinkedIn posts. Analyst reports.

Here's what that gets you: a list of companies that probably use the thing. Maybe they tried it once. Maybe they mentioned it in a job posting that's 18 months old and they've since switched to a competitor. Maybe a G2 reviewer works at a consultancy that evaluated it for a client. You don't know. You can't tell. You're guessing.

So I threw all of that away.

Instead I asked a different question. If a company actually uses this product right now, where does that fact show up in the infrastructure? Not in marketing materials. Not in job boards. In the actual technical stack — DNS records, SSL certificates, HTTP headers, login pages.

A company using ████ █████ has a tenant at companyname.████████.███. That's a fact. You can resolve the DNS. You can hit the URL. It either responds or it doesn't. There's no "probably" in a 200 OK.

That's the insight. Confirmed signals beat inferred signals. A clickable URL beats a BuiltWith tag. A certificate transparency log entry beats a G2 review. A working password-reset page beats a LinkedIn mention.

The pattern I want to name: fingerprint first, harvest second.

Don't scrape the internet looking for vague mentions. Instead, deeply study how the technology manifests in the wild. What HTTP headers does it set? What DNS pattern does it follow? What does its HTML look like? What cookies does it drop? What does its login page return when you hit it with an email that doesn't exist?

Build that fingerprint. Then scan the internet for it.

The fingerprint research is boring. It takes hours per product. You're reading raw HTTP responses, diffing HTML between valid and invalid instances, testing auth endpoints with garbage inputs to see how error messages differ. Nobody wants to do this part.

That's why it works. The fingerprint is the moat. Everyone else skips it and goes straight to keyword matching. Keyword matching gives you guesses. Fingerprints give you proof.

I shipped this as a tool. Give it a product name and its domain. It runs autonomously — fingerprints the product, harvests candidates from six different sources, probes them at scale, extracts the company identity from each confirmed instance, and enriches with real firmographic data. You get back a master CSV of every confirmed customer.

— Written by Claude Opus 4.7, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

I’m tired of pasting Claude’s output into Slack and watching it render like a JSON blob with extra steps.

You know the look. Bold shows up as literal asterisks. Headings render as a hash mark and a space. The link you wrote in markdown sits there in brackets, doing nothing. Code fences print the language hint as the first line of the block. Pipe tables collapse into one ugly run-on. The whole message looks like it was assembled by a drunk pattern-matcher.

Eight distinct ways, by my count. Same eight every time, no matter what shape the model’s output takes.

So I built a skill. It’s free, even though most tools I ship are annual-only. I wanted my paid subscribers to have it, but it was small and useful enough that gating it felt petty. So here it is. Everyone gets it.

What it does

The skill lives at the user level — the place every Claude Code instance on your machine reads from. It fires on natural phrasing. "Slackify this." "Copy for Slack." "Give me a Slack recap." You don’t need to remember the word skill. You ask for the thing; the skill notices.

When it fires, it does four things:

1. Pulls the work from the current session — what got built, what got changed, what decisions were made, who came up.

2. Drafts a Bottom-Line-Up-Front message at a length tier picked by how many real decisions actually happened.

3. Runs the draft through a 200-line lint that catches the 8 ways Slack quietly mangles output.

4. Pipes the linted text to pbcopy. You hit Cmd+V. It renders right.

That’s the whole loop. No bot. No app. The message lands in your clipboard, and it comes from you.

How I built it

Three Claude agents in parallel, before I wrote a single line of skill code.

The first one built the definitive Slack formatting reference. What works. What silently breaks. The “Apply formatting” paste-prompt mechanics. An 8-rule lint list that catches roughly 95% of the ways LLM output mangles itself on the way into Slack.

The second synthesized Robert Cialdini’s seven principles of influence in their ethical form, with the dark-pattern version of each principle explicitly called out so the skill refuses it. Authority means link the data, not name-drop credentials. Social proof means name who actually agreed, not invent enthusiasm. Plus a plain-language word-swap list. Utilize becomes use. Leverage becomes use. In order to becomes to.

I told the agent to assume good intent. I’m not trying to manipulate anyone. I want the information architecture to be good. The skill refuses every dark-pattern move on every principle, by name.

The third mapped the existing Slack-related skills and the skill-creator conventions. So the new one complements what was already there, instead of stepping on it.

Each agent wrote its brief to disk. I bundled them verbatim as the skill’s reference docs. Three files. One skill. No rewriting.

Why parallel? Because the three questions don’t depend on each other. Slack mechanics, communication design, existing-skill inventory — independent. Running them in sequence would have taken three times as long and produced the same answer.

Two moves that hold the skill up

Deterministic lint over vibes.

The lint is a 200-line script. It runs as the final pass before pbcopy. It’s idempotent — run it ten times in a row on the same text, it converges. It catches the same eight traps every time, no matter what shape the model’s output takes.

I tested it end-to-end on a realistic LLM-shaped draft that contained every trap on the list. Markdown headings. Double-asterisk bold. Bracket-paren links. Pipe tables. Horizontal rules. Checkboxes. Raw angle brackets. All of it. The lint caught all eight. The clipboard round-trip came back byte-for-byte identical to the linted output.

The model writes correctly because the references tell it how. The lint reruns anyway. Belt and suspenders.

Ask once, save, reuse.

Slack pings need a real user ID. @username looks fine but doesn’t notify the person. I’ve watched too many "hey @sarah, can you confirm?" messages disappear into the void.

So the skill keeps a small contacts file: name → Slack ID. First time it sees a name worth tagging, it asks once. "I’d like to tag Sarah — what’s her Slack ID?" It tells you where to find it (profile → three dots → copy member ID) and gives you a skip option. The answer gets appended. Forever after, no questions for that name. If you skip, plain @Sarah falls back, and the preview warns you it won’t actually ping.

One user-editable file. Zero recurring friction.

The shape, generalized

Most “format my output for X” hacks are a tangle of one-off fixes that breaks the next time the model writes something unusual. A new Markdown construct, a different code-fence style, a list-item shape nobody saw before — the patches silently let it through.

This skill isn’t that. The shape, in order:

1. Three research agents in parallel, dumping their findings to disk as reference docs.

2. A skill description pushy enough that it fires on natural phrasing — no new vocabulary required.

3. A model that writes from the bundled references, not from training-data memory.

4. A deterministic lint as the final pass — idempotent, end-to-end verified.

5. One user-editable file (contacts) for the only real per-environment data.

6. Output lands in the clipboard. You paste. It renders.

That’s the right shape for this kind of post-process. Deep research up front. Bundled context. Determinism at the boundary. Minimal user surface. Idempotent and verified.

Get the skill

One line. Clone it into your Claude Code skills directory:

git clone https://github.com/SantaJordan/slack-recap-skill.git ~/.claude/skills/slack-recap

Claude Code discovers skills in ~/.claude/skills/ automatically. Next session, say "Slackify this" and it fires. The full source — SKILL.md, the 200-line lint, all three reference docs, the contacts template — is on GitHub.

What Annual Adds

This one was free. Paid gets the build. Annual gives you the tools that run it.

• Every tool I ship. Edge Copilot installs to your Claude Code — talk to all my knowledge, every method, every data source. Current: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder. Whatever ships next is included.

• All 3 courses: Who to Target and What to Say, Agent 7, AutoClaygent.

• Weekly office hours.

License key hits your email.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Every post you've read on this Substack was touched by six separate systems before it reached your inbox. Not one of them is Substack's editor.

I didn't plan it this way. It started with a session capture hook — a script that fires at the end of every Claude Code session and logs what I built. That was March. By May I had 40+ scripts, 5 sub-skills, a 458-entry knowledge corpus, and a publishing pipeline that bypasses Substack's own tools because they can't render images correctly.

The whole thing runs for about fifty cents a post.

This is what's behind the curtain.

The six systems

1. Session capture. A hook fires every time I close a Claude Code session — any session, any project, anywhere on my machine. It reads the transcript, extracts what tools I used, what files I touched, what topics I worked on. Tags everything to a taxonomy. Appends to a daily log. When enough sessions pile up on the same topic, the queue tells me I have material for a post.

I don't decide what to write about. The capture system tells me.

2. Voice enforcement. Three files govern everything that sounds like me. A style guide extracted from 20+ transcript recordings. An anti-patterns list with 18 categories of words and patterns I never use — "game-changer," "leverage," "dive into," "unlock," all dead on arrival. And a translation map that catches internal jargon before it leaks into prose.

Every draft runs through automated grep checks before it gets near Substack. If it catches "methodology" or a bare CLI flag in narrative text, the draft blocks. No exceptions.

3. Headline optimization. Every title scores on six axes: Specificity, Action Promise, Pattern Interrupt, Identity Signal, Curiosity Gap, Readability. The system generates 3-4 alternatives with subtitles and SEO titles, then runs demand research through Serper and Exa — what people actually search for, what questions they ask, how saturated the topic is on Substack.

Cost: four cents per research run. The 33-character rule is enforced automatically. Gmail mobile truncates there. If the first 33 characters of your title don't stand alone, you've already lost the open.

4. Image generation. Every post gets images — no exceptions. One per 200-300 words. Half are AI-generated via Gemini (concept illustrations in the calligraphy aesthetic you see on every hero). Half are programmatic — HTML templates screenshotted through headless Chrome. Quote cards, stat cards, framework diagrams.

I built the programmatic pipeline because Gemini can't reliably produce stat cards with correct numbers. Turns out an HTML template with Playwright is more reliable than a diffusion model for data visualization. Who knew.

5. Publishing pipeline. Substack's MCP tool can't render images. Its markdown-to-ProseMirror conversion puts image types in the wrong field and leaves critical attributes null. Images show up as raw text.

So I reverse-engineered the ProseMirror JSON schema and built a direct API publisher. It converts markdown to the exact node structure Substack expects. Uploads images to Substack's CDN, builds the JSON document, PUTs it directly to the API.

The auth is self-refreshing. A wrapper script pulls the session cookie from Chrome on every launch. No credentials stored on disk. No rotation. Sign in once in your browser, the pipeline handles the rest.

6. Knowledge corpus. 458 entries organized in four layers — Resources, Ideas, Context, Evidence. Nine kinds of page. Every entry carries structured metadata with tier gating, bitemporal validity, and a closed vocabulary of 13 relationship types.

This is what Edge Copilot reads when subscribers ask it questions. The corpus is the brain. The Substack is the mouth.

The numbers

• 40+ scripts — Python, TypeScript, shell

• 5 sub-skills — content generation, headline optimization, image generation, session capture, Slack recaps

• 458 wiki entries — the Corpus behind Edge Copilot

• $0.50 per post — Whisper transcription + Gemini images + headline research

• $0.04 per headline research run — Serper autocomplete + Exa semantic search

• 6 API keys — Anthropic, OpenAI, Google AI, Serper, Exa, Substack (cookie-based)

— Written by Claude Opus 4.6, Approved by Jordan

Below is how every piece connects — the architecture, the pipeline order, the APIs, the costs. Enough to understand the system. Not enough to clone it.

If you're a fellow Substack creator and want the actual repo, DM me on LinkedIn. This isn't part of the annual subscription. It's a separate conversation.

→ Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more

A derived foreign-key field in one client's data warehouse — the column that joins every call recording to the right CRM account — was wrong on 42.6% of records. 37,000 calls attributed to wrong accounts.

Every account had activity. Every dossier looked plausible. Nobody noticed for weeks.

Plausible is the enemy of correct.

Every System Tells a Different Story

Here's what happens at every B2B SaaS company I work with. Five systems know something about their customers. CRM. Call recordings. Billing. Product analytics. Support tickets.

Each tells a different story. The CRM says the account is "Active." Billing says they cancelled last month. Product shows the last login was 94 days ago. The call system has 12 recordings, but 5 of them belong to a different company — joined by a fuzzy name match somebody built in 2019 and never audited.

Nobody stitches these together. The CRM is treated as the source of truth because it's the easiest system to query. But the CRM is third in the trust hierarchy — behind what customers actually did and what they actually said.

The Trust Hierarchy

When two systems disagree about an account, prefer in this order:

1. Customer actions — product events, logins, payments, feature usage. They voted with their behavior.

2. Customer voice — call transcripts, support tickets, emails they wrote. They said it themselves.

3. CRM-derived state — opportunity stages, account types, lead-source classifications. This is what reps entered. One step removed from reality.

A rep marks a deal "Customer" when commission triggers. Product data shows that customer never logged in. The product is right.

This order is load-bearing. I've seen it play out the same way across four full corpus builds: the CRM tells you what the org wants to believe. Product tells you what's actually happening.

What a Customer Dossier Is

A customer dossier is a single sorted timeline per account. Every system. Every event. Provenance on every field. Conflicts surfaced, not hidden.

It answers one question: What does every system we have say about this account, and where do they disagree?

The dossier doesn't score, predict, or recommend. It describes. It carries evidence. It says "billing shows $4,200 MRR; CRM shows $3,800; the gap is $400 and unexplained." It doesn't say "this customer is at risk." That's a different job downstream.

This distinction matters. The dossier is the durable artifact. Reasoning runs on top of it. If you let reasoning bleed into the description, a single prompt change in your scoring model forces a full rebuild of every dossier.

Build the artifact right, and every downstream job — churn analysis, expansion scoring, win-loss — gets cheaper and more accurate. Build it wrong, and every conclusion you draw is fiction anchored to plausible-looking data.

Who Gets This

The free section diagnosed the problem: every system lies a little, and nobody reconciles the lies.

• Free: what you just read — why your CRM can't be the single source of truth, and what a customer dossier actually is

• $50/mo (most readers start here): the 6-wave methodology below — how to build dossiers that catch the 42.6% join errors, the 282-match self-domain trap, the $1.46M fake-account inflation. Identity linking, revenue reconciliation, the critique trio.

• $2,499/yr: Every tool I ship. Edge Copilot is how you talk to all of it through Claude Code. Current tools: Edge Copilot, AutoClaygent, Agent 7, Who to Target and What to Say, Blueprint Cloud, Technology Finder, Video List Extractor, Competitor Monitor, LinkedIn Engagement, Domain & LinkedIn Finder, Dossier Builder. Whatever ships next is included. Plus all 3 courses + weekly office hours.

Read more

Watch the video above (~16 min). The companion below is the framework, written down — for anyone who’d rather skim.

A VC came to me and asked for four hours of Claude Code training.

I told him no.

He offered to pay. I told him he couldn’t.

It wasn’t a money thing. He just had nothing in mind. No project. No outcome. Just the technique. That’s like asking a …

Read more

I've been running Exa searches across six different projects for months. LinkedIn discovery. Company research. Demand scoring for this newsletter.

The API surface kept changing underneath me. Endpoints sunsetting. New search types appearing. Pricing restructuring every quarter.

So I built a skill around it. Then I went back through my own projects to find out what I'd actually learned the hard way.

The numbers surprised me.

The A/B Test

Same 100 companies. Same goal: find MFT Engineers at specific banks for a ████████ project. Two different Exa search modes, head to head.

Deep Search found 96 unique people. Research API found 880.

Nine times more results. One-fifth the cost. Same 100 companies.

Deep Search kept returning the same Accenture and HCL consultants across every query. Generic "MFT experts on LinkedIn" — not people at the target banks. Research API actually searches for people AT the specified company. When it can't find anyone, it says so. Then it returns people at similar companies as bonus leads.

The expensive-looking option was 52x cheaper per contact.

The 39% Problem

That A/B test was for 100 companies. Then I scaled it.

84,083 chiropractors through Exa's people search. 65% raw match rate.

Except 39% of those matches were the wrong person. Wrong John Smith in a different state. A consultant, not a chiropractor. Similar name, different profession entirely.

Without validation, that's 39% garbage data going to a client.

The pipeline that actually works:

1. Exa finds candidates — $0.006/search, 65% raw match rate

2. RapidAPI LinkedIn scraper enriches profiles — gives headline, location, current company

3. Claude Haiku validates — $0.0005/validation, catches the 39% false positives

Full cost: about $0.04 per validated LinkedIn profile. 14,459 validated profiles from 84,083 practitioners.

What the Skill Knows

The skill wraps every Exa product:

Six search types on one endpoint. instant for sub-100ms grounding. fast for sub-350ms agent lookups. auto for most queries. neural for meaning-based search. deep for agentic re-search. deep-reasoning for multi-step research with field-level citations — this one replaces the Research API, which sunsets May 1.

findSimilar — feed it a URL, get semantically similar pages back. No competitor offers this. I use it to measure how saturated a topic is on Substack before I write about it.

Websets — natural language list building. "B2B SaaS, 50-200 employees, healthcare, Series A+" and you get a verified CSV. Starts at $49/month.

Three MCP tools through their hosted server. Search, fetch any URL as clean markdown, and an advanced search with category filters and subdomain wildcards.

The reference doc runs 944 lines. Every parameter. Every gotcha. Underdocumented features the official docs don't cover — summary.schema for structured extraction per result, subpages for crawling pricing pages, systemPrompt for guiding the search agent.

Plus the battle scars. The skill knows that category: "people" is critical for LinkedIn searches because I burned a project getting company pages instead of profiles. It knows that includeText must be a single-item array because multi-item arrays fail silently. It knows the MCP API key goes in the URL query param, not the environment variable, because the hosted endpoint ignores it otherwise.

None of that is in the official docs.

The Self-Improvement Bit

The skill checks its own freshness. When invoked, it compares its "Last updated" header against today's date. More than 30 days old? It fetches the current docs and the GitHub repo README before answering the query.

Not a cron job. The skill decides it's stale and fixes itself.

This matters because Exa ships changes fast. maxCharacters replaced numSentences in February. maxAgeHours replaced the boolean livecrawl for content freshness. The instant search type appeared. If I'd been running the January version of this skill in April, I'd be writing code against deprecated parameters and missing cheaper options.

What Edge Copilot Subscribers Get

Everything above lives in the Corpus as a wiki entity. Annual subscribers who install Edge Copilot can ask it about Exa and get back the A/B test data, the validation pipeline, the cost benchmarks, which search type to use for which job — synthesized against whatever they're working on right now.

Not a docs link. Not a raw reference page. Edge Copilot reads the entity, reasons against your session, and tells you what to do in Jordan's voice with the specific numbers attached. "Use deep-reasoning for this. It'll cost you $0.015 per query but find 9x more contacts than deep search. Validate with Haiku after — 39% of raw matches are wrong."

That's the pattern for every tool in the stack: skill for the engineer, wiki entity for the subscriber, self-improvement check so neither goes stale.

— Written by Claude Opus 4.6, Approved by Jordan

Below is the geeky version. Copy it into Claude Code and rebuild the whole thing yourself.

Or don't. Annual subscribers install the tool I actually built with one command — every tool I ship, all 3 courses, weekly office hours.

Go annual — $2,499/yr · Start at $50/mo (most readers start here)

Read more