Imagine this. You’re mid-conversation with an AI. Suddenly, the responses get shorter. Sometimes, worse — the AI starts missing things you said three messages ago.

Congrats! You might’ve hit the token limit.

Most people start a new chat and lose context. We did too. That’s why we built a tool that shows you exactly where your tokens are going — and rewrites your system prompt to use fewer of them.

Set a timer for 90 minutes. We’re starting now.

But first, why do token limits get hit?

Every model has a context window. That’s the amount of information it can hold at once. Meaning input, output, system prompt, conversation history, all compete for the same space.

Here’s why.
1. Conversation history. AI re-reads the entire conversation from the top, every single time you send something. So a productive session hits 50,000+ tokens after just 10-15 exchanges.

2. Pasted documents and code. Simple rule: the bigger and more information-dense your document, the bigger your token count. A 50-page contract is roughly 75,000 tokens. A medium-sized codebase, 250,000. All that even before you ask a single question.

3. Context rot. Models start degrading at 60-70% of their stated window — responses get vaguer, instructions get missed. This is why your AI sounds dumber even when you have memory left.

4. Your system prompt. If it’s 800 tokens of loosely written instructions, that’s 800 tokens spent before you’ve typed a word.

Today, we’re building a tool to solve the last one.

What does the tool do?

It asks you to enter your prompt, tells you the number of tokens it’ll use, and suggests a more token-efficient prompt for you. We’ll build this entire setup using Streamlit, GitHub and Groq. If you’ve read our last edition, you’d recognise that we’d used the same system to build the pitch detector out. But if you’re new here, here’s the rundown of what each tool does.

- Streamlit: Helps us host the webpage
- Groq: This is the AI layer that actually compresses the prompt
- GitHub: This is where our code lives.
- tiktoken: OpenAI’s free library for counting tokens. Runs entirely on your machine. No API key needed.

Step 1: Create a GitHub repo.

1. Go to github.com. Sign in.

2. Click the + icon in the top right corner. Select New repository.

3. Fill in:

• Repository name: token-counter

• Description: skip it

• Set it to Public

• Check Add a README file

4. Click Create repository.

Step 2: Create the requirements file.

This tells Streamlit which libraries to install when it deploys your app.

In your repo, click Add file → Create new file.

Name it exactly:

Paste this as the content:

Scroll down and click Commit changes.

Committing is GitHub's way of saving. Think of it as hitting save, but with a record of every change you've ever made.

Leave everything as default and hit Commit changes again.

Step 3: Get your Groq API key.

1. Go to console.groq.com. Sign in or create a free account. No credit card needed, and the free tier doesn’t expire.

Once you’re in, click API Keys.

Hit Create API Key. Name it anything; even “token-counter” works. Copy the key. It starts with gsk_.

Keep this tab open.

Step 4: Create the app file on GitHub.

This is the file that actually runs your tool. It has to be named app.py. Streamlit looks for this exact name when it deploys.

What it does: takes your inputs, counts the tokens using tiktoken, sends your system prompt to Groq, and returns a compressed version with a before/after count.

So, head to your HitHub repo.
1. Click Add file → Create new file.
2. Name it app.py
3. Paste this code exactly.

4. Commit the file.

Step 5: Deploy on Streamlit.

Your code is on GitHub, but it’s not running anywhere yet. Streamlit reads your repo and turns it into a live app.

1. Go to share.streamlit.io. Sign in with your GitHub account.
2. Click Create app.

3. You’ll see a pop-up to enter details.
4. Select your token-counter repo under Repository. You should see a dropdown when you click the Repository section.

Fill in:

• Branch: main

• Main file path: app.py

Click Deploy. You’ll see a screen that says “Your app is in the oven.” Wait 60 seconds.

Step 6: Store your API key safely.

Your app is live. But it doesn’t know your Groq key yet. You’ll add it directly to Streamlit so it never has to live in your code.

1. In the bottom right of your app, click Manage app → Settings → Secrets.

You should see a pop-up.

2. Head to Secrets, delete the contents and paste exactly this. (Replace your groq API key with your actual API key)

3. Hit Save.

4. Now go back to your GitHub repo. Open app.py and replace this line:

With this:

5. Commit the change.

Streamlit detects it automatically and redeploys — takes about 30 seconds.

Step 7: Test it.

Paste this into the system prompt field — it’s a bloated example we used ourselves:

Leave conversation history and new message empty. Now hit the button. What do you see?

What’s next?
Streamlit, GitHub, and Groq are building blocks. Swap the compression logic for something else — a classifier, a formatter, a scorer — and you have a completely different tool. Same skeleton.

Try something. Break something. Tell us what you built.

Want to plug your brand into our newsletter?

Email us at collab@growthx.club

Ever spent a few hours perfecting a v1 of your idea? It looks perfect. Everything’s wired up just as you planned it. Heck, you even asked Claude to do the coding. Yet when the code runs, the result is wonky.

What just happened? Today, we’ll learn how to avoid that situation. Let’s get straight into it.

Before we begin.

We’re launching the Live AI Immersion Program where you go from idea to working product in 4 days. You’ll learn to scope ideas down before you start, shape your code as you go, and know when to trust the AI and when to check it. A live product. A public repo. Real feedback. A roadmap forward. It’s all in here.

Cohort 1 begins on July 30th.

Want in?

Why build a red flag detector when a prompt is enough?

A prompt can already tell you if a pitch sounds sketchy. Type it into ChatGPT, ask “does this look like a scam,” and you’ll get an answer. Ask the same question tomorrow, and you might get a different one. Why?

Because at every step, they’re picking the next word from a list of likely options, not the one guaranteed option. For a red flag checker, it’s a problem because you want a consistent verdict every time.

Plus, a prompt starts from zero every single time. It re-researches a rate range it already found last week. It looks up a company it already checked yesterday. Pays full price for research that hasn’t changed since the last person asked.

Our tool solves both those issues. It checks a database first — if someone already looked up what a content marketing role pays in India, the next person gets that answer instantly instead of triggering a fresh search. Same verdict, every time.

Cool, how do we build this out?

This tool has 4 components:

• A webpage (Streamlit hosted + GitHub for ) where you paste the pitch or DM you want checked

• An LLM with a built-in rulebook — Gemini reads the pitch and scores it across five dimensions: scope, rate, IP terms, timeline, and identity. The rulebook is what stops it from just vibing and calling it a verdict.

• A reality-check layer (Tavily) that searches the web for what the company actually looks like externally, and what the work actually pays. This is what separates a judgment from a guess.

• A database (Supabase) that remembers past searches so the tool doesn’t re-research the same thing twice, saving time and keeping us within free-tier limits.

Today, we’ll connect these components using code that’s already written for you. You’ll paste it into a file on GitHub (which stores it) and Streamlit will read from that file and turn it into a live webpage. Plus, every tool in this build has a free tier that doesn’t expire and doesn’t need a credit card. Set a timer for 75 minutes. We’re getting started now.

Set 1: Set up your accounts and collect your API keys.

1. Gemini API key
a. Go to aistudio.google.com and sign in with any Google account.

b. Click “Get API key” in the left sidebar.
c. Click “Create API key in new project.
d. Copy the key that appears. Paste it into a notes app. You’ll need this later.

2. Get your Tavily Key.
We picked Tavily because it’s the only search API that’s still genuinely free. Brave killed its free tier earlier this year. Google’s Custom Search API stopped taking new signups. Meanwhile, Tavily has about 1,000 free searches a month and no credit card required.

a. Go to tavily.com.

b. Sign up with your email.
c. Your key will be on the dashboard the moment you log in. Copy it in a safe place. We’ll use it later.

3. Set up GitHub.
This is where your code will live, and Streamlit, the tool that’s hosting our front end will read the code to build the live webpage from. To set it up:
a. Go to github.com. Create a free account if you don’t have one.
b. Click “+” top right → “New repository.”

c. Name it pitch-check. Set it to Public. Leave everything else as default.

d. Click “Create repository.”

4. Streamlit

This is what turns your code into a live webpage anyone can open.
a. Go to share.streamlit.io and click “Continue with GitHub” — it links straight to the account you just made.
b. Authorize it when prompted. And set up your account. That’s it for now — we’ll come back to actually deploy in Step 3.

Before moving on, you should have copied: your Gemini key, your Tavily key, a GitHub account with an empty pitch-check repo, and a Streamlit account linked to GitHub.

Step 2: Add your code to GitHub

Go to your ‘pitch-check’ repo. You’ll add two files here.

First, the requirements file.
This tells Streamlit which tools to install before running your app. Without it, the app crashes on startup.
a. Click ”Add file” → “Create new file.”
b. Name it exactly: ‘requirements.txt’
c. Paste this in:

d. Click “Commit changes.”

Now, we build the app itself.

a. Click ”Add file” → “Create new file” again.
b. Name it “app.py”.

Now, we paste the code. But before we do, here’s how we;re thinking about it.

What’s in a code?
Our code is a rulebook the tool follows every time it runs. Every new pitch gets scored across five dimensions, each with its own pass, caution, and fail conditions.

- Scope — does the ask match what’s being paid for, or is a large multi-part build being framed as something simple?

- Rate — is the offered pay within the real market range for this type of work, or is it equity dressed up as compensation?

- IP — does the sender want to own more than what they’re paying for?

- Timeline — is the deadline realistic, or is there artificial urgency designed to stop you thinking clearly?

- Identity — do the claims in the pitch hold up externally, or does the company not exist when you go looking?

Each dimension scores 0 for pass, 1 for caution, 2 for fail. Add them up and you get a severity score out of 10. That maps to a verdict: proceed, proceed with caution, significant concern, or ghost them.

You don’t have to write this code.
We generated it with a single natural-language prompt. If you want to understand exactly what you’re pasting, or generate your own version — here’s the prompt that produced it:

Here’s what your code should look like.

c. Paste the full code below into your ‘app.py’ file.

d. Click “Commit changes.”

Step 3: Set up Supabase.

a. Go to supabase.com. Sign up with GitHub

Supabase will ask you to set up a new organization first.

b. Next, add the project name, set a password, select the region closest to you and check the checkboxes as mentioned.

d. Wait about two minutes while it provisions. Normal, not stuck.
e. Once ready, go to Settings → API Keys

f. Copy the Publishable key.
g. Next, head to the General settings tab. Under Project settings copy the Project ID.

Now add this to find your project URL. Here (yourprojectid) should be replaced with your ID:

Let’s create a memory table for the time being.
This is where the tool stores what it’s already researched, so it never looks up the same thing twice.
a. Open your Supabase project. In the left sidebar, click the Table Editor icon (the grid)
b. Click “New table.”
c. Name it exactly: market_rates

d. Leave the two default columns — id and created_at — exactly as they are.

e. Click “Add column” and add these three, one at a time. Set the Type to text for each:

• job_type

• country

• rate_data

f. Click “Save.

Before running anything, turn off the lock.
Supabase locks every new table by default — nothing can read or write to it until you either set up access rules or switch the lock off. Our table only stores public rate research, nothing personal, so we don’t need those rules. We just need the lock off, or the tool will fail to save anything.

g. In the left sidebar, click Database.
h. Click Policies.
i. Find market_rates in the list and click “Disable RLS” next to it.

That’s your memory layer ready. The tool can now write to it, and read from it before every search.

Step 4: Deploy on Streamlit.

Your code is sitting in GitHub. Now Streamlit will turn it into a live webpage.
a. Go to share.streamlit.io. You should already be logged in from Step 1.
b. Click “Create app” in the top right.

c. It’ll ask what you want to do. Pick “Deploy a public app from GitHub.”

d. Now, you’ll see the deploy app pop up. Fill in the three fields:

• Repository: yourusername/repo

• Branch: master

• Main file path: streamlit_app.py

Before you hit deploy, add your keys.
Your code expects your Gemini and Tavily keys, but they’re not in the code for a reason. Why? Putting API keys directly in code that lives on a public GitHub repo means anyone can read them. Streamlit has a separate, private place for them.
e. So, click “Advanced settings.”
f. You’ll see a Secrets box with some example text in it. Delete all of it.
g. Paste your two keys in, exactly like this

GEMINI_API_KEY = "your-gemini-key-here"
TAVILY_API_KEY = "your-tavily-key-here"

Replace the placeholder text with your actual keys, keeping the quote marks.

Note:

This box uses a format called TOML, and it’s fussy in one specific way: it uses an equals sign, not a colon. KEY = "value", never KEY: "value". No curly brackets. No commas at the end of lines.

Also watch your quote marks. If you copied your keys through a notes app that auto-converts straight quotes (") into curly ones ("), TOML rejects them. Type the quotes fresh if you’re unsure.

h. Click “Save,” then “Deploy.”

You’ll see a screen with logs scrolling by — that’s Streamlit installing everything from your requirements.txt and starting the app. First deploy takes a minute or two.

When it finishes, you’ll have a live URL. Congratulations! Your tool is on the internet.

Step 5: Check if it works.

Open your app’s URL. You’ll see the title, a text box, a company field, and an “Analyze this pitch” button.

Paste this pitch or any other one you may have gotten.

Type Acme in the company field and hit Analyse.

The tool should work. But don’t trust it yet.

Step 6: Test it. Hard.

Your app ran. It returned a clean, colour-coded verdict. Except the output is something that’s not quite right.

So, how do you know what went wrong?

Test 1: Run the same pitch two or three times in a row.

Same pitch, same company name, back to back. Watch the verdict and the reasons.
Do they stay identical? Or does the wording drift, a flag flip, the score wobble by a point?

If it drifts, bingo, you’ve found a consistency problem. The model is picking slightly different words each run.

How to fix it? Set the model’s temperature to 0. Temperature controls randomness — 0 means “always pick the most likely answer,” which makes the same input produce the same output every time. It’s the line already baked into the code you pasted. If your generated version drifts, that’s the first place to look.

Test 2: Run three or four genuinely different pitches.
A scam gig. A real cold sales email. A legit-looking job offer. A full-time role posting. You’re not checking whether it flags the obvious scam — you’re checking whether it stays sensible across normal messages too.

Watch out for these failures:
a. It over-flags a normal pitch.
A legitimate offer gets treated like a scam means your rubric is too aggressive. Loosen the pass/caution/fail conditions.

b. The company search returns nonsense.
This one bit us. We searched the company name “Acme” and got back real complaints — for a grocery chain, a trucking company, businesses with nothing to do with the pitch.

The fix?
Told the model to first check whether the search results are even about the right company, and ignore them completely if they’re not. Real-looking data about the wrong subject is worse than no data.

c. The pay comparison is against the wrong kind of work.
We fed it a full-time role and it compared the salary against freelance hourly rates — an entry-level marketer in Germany versus a senior growth expert in crypto. Not what we want the tool to do.

So, what did we do?
Two things: First, a separate step figures out whether the pitch is full-time or freelance. Then the tool runs a different search depending on the answer — for full-time roles it searches real salary data and real job-description postings separately, so both the pay and the scope checks are grounded in the right kind of source. And we added an employment_type column to the database so those two kinds of lookups get cached separately instead of overwriting each other.

Test 3: Go check the places that fail silently.
If your tool writes to a database or calls a search, don’t trust the screen. Go open the database. Look at the actual search results. The app can look completely healthy while nothing is landing where it should.

Our database writes failed for a while. The app ran, the report rendered, everything looked done. But the table stayed empty, because the database had a security setting switched on that blocked every write without telling us. The only proof anything was wrong sat three clicks deep in a logs panel we almost never opened. Why would you check logs on something that’s working?

One more thing.
Your generated code won’t be identical to ours. You might use a different model, phrase the prompt differently, get a slightly different structure back. Which means your bugs won’t be identical either.

But they’ll largely fall into these same categories: inconsistent output, wrong-subject searches, mismatched comparisons, silent saves. The skill isn’t memorizing our exact fixes. It’s learning to run the thing repeatedly, watch what breaks, and match the symptom to the category.

That’s what separates someone who can prompt an app into existence from someone who can actually ship one.

Want to plug your brand into our newsletter?
Email us at collab@growthx.club

12:39: You’ve got one new email.

13:05: You’ve got one new email.

By 18:00, you’ve got fifty of them. Everything, including newsletters, has somehow landed up in the primary tab. The labels? Those only sorted newsletters by sender, not by urgency to reply.

A few days back, we almost missed a subscription renewal buried on page three of that list. That’s when we decided to build a triager tool for ourselves. Something that actually remembers what "urgent" meant to us. Today, we’re sharing that exact workflow with you. Set a timer for 90 minutes. We’re beginning right now.

1 month of Granola free. Start today.

We’ve tried several AI note-takers at GrowthX, and Granola has been our go-to for the past year. It gives us comprehensive prep notes before every meeting, near-accurate transcripts, and even makes follow-up tasks like emails and planning easy. Try Granola Pro free for 1 month by signing up using the link below.

Try Granola today

But first, what makes a good triage tool?

A good triage tool does three things. It reads your inbox continuously, makes a real judgment call on each email, and it remembers that judgment the next time, instead of scoring every email cold.

That needs 4 components:
a. something that watches for new mail
b. something that classifies and scores it
c. somewhere the decision gets stored
d. and a way to actually reach you when it matters.

The simplest version pairs two free tools. Apps Script is Google’s own automation layer, and Groq. Here, Apps Script acts as the execution layer, fetching emails, sending them to Groq for analysis, and then sending the Slack message via the webhook. Groq is where the actual thinking happens.

That works fine for regular emails. You set up rules for Groq to work with and the analysis happens accordingly.

But what happens when escalations come up on email? One hey-let’s meet up email. Followed by a “hey, just checking in” email from the same sender. You’d have to tighten the rules, a lot.

Hermes helps with exactly this pattern detection. It reads the email history itself and lets the model infer the pattern — the same four buckets, the same three tiers, just a lighter rubric underneath. The tradeoff? A hardcoded rule is predictable; you know exactly why it fired. An agent that infers from history is more flexible, but you can’t always explain why it decided something was urgent.

But going that route means a slightly more advanced setup: IMAP instead of the one-click Gmail access Apps Script gives you for free. But worry not, we’ll walk through it step by step.

Step 1: Installing Hermes + model.

Hermes runs from your terminal. This one command handles the whole install.

Here’s what you should start seeing.

Your computer will run for a bit. Once it stops, enter this prompt.

Now, you’ll see the set-up wizard pop up.

You have two options:
a. Quick Setup using the Nous Portal: Choose this, and you’ll get access to Hermes-supported models for free. The catch? You’ll need to create a Nous account and enter your credit card information.

b. Full Setup: This way, you can choose a model of your choice without entering credit card details and customise your setup.

We’ll go with Full Setup today.
Next, you’ll be asked to choose a provider. Select Google AI Studio. It’s free, doesn’t need a card and is enough for what we’re building today.

Now, you’ll be asked to enter the API key. For this:
a. Go to aistudio.google.com/apikey and sign in to your Google account.
b. Create a new API key, copy the code and enter it in your terminal.

Next, you will be asked to select a model. Check gemini-3.5-flash. This is the configuration we need for our Triage tool to work.

That’s it. Your basic Hermes setup is ready.

Step 2: Onboarding Hermes onto Slack.

Right after you pick a model, Hermes asks which tools it’s allowed to use: first for the CLI itself, then for each messaging platform you connect to.

Wait, what is CLI? Do we really need it?
CLI is the command line interface, or your terminal window. Configuring this will allow you to use Hermes natively within your Terminal. We don’t need this today since we’re building our Triager tool on Slack. But we’ll need to move past this flow to get to the Slack setup. Here’s what you do.

You’ll see a long checklist titled “Tools for CLI”.
Keep these checked: Terminal & Processes, File Operations, Code Execution, Memory, Cron Jobs, Skills.

The rest are unchecked. Why? Because the other options image generation, browser control, text-to-speech, etc. are for different kinds of projects. They don’t do anything for reading and sorting email, so there’s no reason to carry the extra weight.

Next, you’ll be asked to choose a terminal backend. This is where Hermes actually does the work, like reading and sorting your inbox. You have three options here:

a. Local: Here Hermes runs directly on your laptop, using its files and permissions. Runs when your laptop is active.
b. Docker: Hermes is sealed off from your computer’s files by default. Switches off with your laptop
c. Any cloud options: Hermes runs in the background 24*7.

Choosing messaging platforms.
This is where you’ll configure Slack during the setup.

a. Scroll to Slack using your arrow keys. Press Space to check it and then press Enter to confirm.

b. Create the Slack app
Hermes writes a Slack app manifest to a file on your machine and gives you the path.

c. Find this document in your files and copy it. This is how Hermes will be set up through Slack.

Now head over to Slack.
Go to api.slack.com/apps → Create New App → From an app manifest.

Select all the placeholder JSON shown and delete it, then paste in what you copied from your terminal. Click Next, then Create.

Get the App tokens
Go to the left-hand panel. Select Socket Mode from the dropdown.

In the app’s settings, go to Socket Mode and confirm it’s enabled. This is how the Slack app and Hermes communicate directly.

Create an app-level token.
Scroll down to Socket Mode and App-Level Token. Give it any name, and when asked for a scope, add connections:write. Click Generate. Copy the generated token to a safe place.

Install the app and copy your first key (Bot Token).
Click Install App in the sidebar, then Install to Workspace, then approve the permissions. On that same page, copy the token that starts with xoxb-.

Go back to the terminal.
Enter your Bot token (the xoxb- one), then the App-Level Token (paste the xapp- one).

Choose who can message the bot
You’ll be asked which Slack users can talk to this bot. Enter only your own ID, so no one else in your workspace can use it.

To find your ID:
Click your name in Slack → View full profile → the ⋮ menu → Copy member ID. It should start with U, not C — if it starts with C, you copied the wrong thing.

Decide where notifications go (Optional)
It may ask for a “Home Channel.” You can leave this blank and skip it — we’ll set it up properly later.

Turn on the always-running part
When asked if Hermes should run as a background service, choose Yes. This means Hermes keeps listening for Slack messages even when you’re not looking at the terminal.

Check point 1: Test your Hermes Slack Bot

Open the direct message with the Hermes app in Slack (not a channel, not a thread) and type “hello.” If it replies, everything’s connected correctly.

Before we continue.

You’ve got the build instinct already. Four days with us can catapult that 100x.

We’re launching the Live AI Immersion Program where you go from idea to working product in 4 days. You’ll learn to scope ideas down before you start, shape your code as you go, and know when to trust the AI and when to check it. A live product. A public repo. Real feedback. A roadmap forward. It’s all in here.

Cohort 1 begins on July 30th.

Want in?

Step 3: Connecting Gmail.

Today, we will do this with Himalaya: a separate, standalone email tool Hermes can operate from the terminal. Worry not, it only reads, lists, and organises. It never sends anything unless explicitly told to. That’s exactly why we are using it.

Step 1: Generate an app password
You’ll need 2-step verification turned on on your personal account to get this. How do you check? Simple: Go to myaccount.google.com/security and check. Once this is done, you should be able to set an App password on myaccount.google.com/apppasswords. You’ll get a 16-digit code. Copy it.

Note: You may not be able to set this up for your business account if your organization forbids it.

Step 2: Install Himalaya CLI

What this does: It fetches emails from your Gmail account using IMAP without the tedious process of etting it up.

Go to your terminal tab and run:

Confirm it installed correctly using this prompt

Step 3: Run the setup wizard
Type this in the terminal.

Now, you’ll be asked a set of questions.

• Email address — your Gmail address

• Account name — any nickname, doesn’t matter what you pick

• Full display name — your name, or just hit Enter to skip

• Downloads directory — hit Enter to accept the default, not something we need to change

Now you’ll be asked to configure IMAP and SMTP. Both are ways to read your inbox and send email. And both setups are password-protected.

Configure both as shown in the image. And when asked for passwords, here’s what you do.

For IMAP and SMTP, enter the 16-character app password generated previously.
Store both in the configuration file (it’s easier to retrieve this way, and everything stays on your computer).

Check point 2: Test if IMAP works

Once the wizard finishes and saves your config, check that it’s really connected to your inbox:

If it worked, you’ll see a real list of your most recent emails, including subject, sender, and date pulled live from Gmail. Like this.

Step 4: Creating the labels

Labels are how your emails get sorted in your inbox. We decided to create 5 for ours.

Action needed: Urgent emails
FYI: Good to know but not urgent
Noise: Marketing newsletters
Subscriptions: Payment updates
Needs Review: Emails that don’t get neatly filtered into any of the above buckets.

Creating them is simple. Just copy this prompt into your terminal. You can change label names as you see fit.

You should see a ‘Success!” notification in your terminal itself once the labels are created. Then you can go back to your linked Gmail account to recheck.

Step 4: Creating the Scoring skill

Creating a new skill in the right directory.
The last thing you want is to create a skill and have Hermes skip it entirely all because it was at the wrong place.

Here’s how you avoid that.

Hermes skills live at ~/.hermes/skills/<skill-name>/SKILL.md. We’ll create a folder and file here with this command.

Now we’ll add this content to the skill folder with the following command.

Next, confirm if the skill was genuinely added with this command in the terminal.

You should see the entire skill file in your terminal.

Added a fifth option: “not sure.” At first, every email had to land in one of four buckets, confident or not. We asked: what happens when it guesses wrong? So we gave it an out — if it’s not confident, file it under “Needs Review” instead of forcing a call.

Handle one email at a time: The tool fired off requests too fast, hit a rate limit, and gave up. So we added a simple rule: handle one email at a time, wait a bit between each, and don’t quit after one failed attempt.

Made sure it doesn’t check the same email twice: Emails that get moved out of the inbox are automatically safe — they’re gone, so they won’t get picked up again. But “Needs Review” emails stay in the inbox on purpose, which means without telling the tool to mark them as “already looked at,” it would re-read and re-sort the same email every single hour, forever.

Told it to stay quiet when there’s nothing urgent: Originally, every run sent a little summary to Slack. Fine once — annoying every hour. So now: only speak up if something’s actually urgent. Otherwise, say nothing.

Never reply to or delete anything: It only reads and sorts. And never make up details about an email it wasn’t sure about — better to flag it as unclear than confidently get it wrong.

Step 5: Make the triage tool fire every hour

Head to your Hermes chat on Slack and type this.

Check point 3: Run a test.

You can test the triage logic itself directly in Slack — just know this method won’t test the [SILENT] behaviour, since that’s cron-specific plumbing that only activates via a real cron trigger, not in chat.

In the actual Hermes DM (click Hermes under Apps), send:

What to watch for in the reply:

• It should tell you what it classified and where things got filed — that’s expected here, since this is a normal chat response, not a cron delivery.

• Check whether it followed the 15-cap rule correctly (it should say 5 or fewer, since you asked for 5).

• If anything’s High urgency, it should describe it clearly.

Then verify in Gmail directly — open the labels in your browser, confirm the emails actually moved/copied to the right folders, matching what it just told you.

And there you have it.

Go build this tool. Point it at your own inbox, watch what it gets right, watch what it gets wrong, and fix the rubric until it doesn’t. Then tell us what broke — reply to this email; we read every one. If your version of this looked different from ours, we’d love to hear that too.

Want to plug your brand into our newsletter?
Email us at collab@growthx.club

Imagine this. Your product launches in 3 days.

You tag @Claude: “Pull everything we’ve decided on positioning and draft a one-pager.” Claude reads three weeks of channel history and posts the draft.

Sneha immediately tags @Claude: “Update the hero copy in Figma to match.” Claude uses the positioning it just built and makes the change.

Then, Nirav, the copywriter, chimes in: “Hey, we tweaked the positioning on our last call. Here are the notes.” Claude listens, pivots, searches the transcript, and updates the Figma.

This could be how your team works on Slack right now. Say hello to Claude Tag.

1 month of Granola free. Start today.

We’ve tried several AI note-takers at GrowthX, and Granola has been our go-to for the past year. It gives us comprehensive prep notes before every meeting, near-accurate transcripts, and even makes follow-up tasks like emails and planning easy. Try Granola Pro free for 1 month by signing up using the link below.

Try Granola today

So, what’s Claude Tag?

Claude Tag is Anthropic’s newest way to work with Claude in your Slack Workspace. You grant Claude access to selected channels and connect it to whichever tools, data, and codebases you choose.

Then anyone in the channel can tag @Claude to delegate tasks while they focus on other work. It’s like an intern, but better.

What can Claude Tag really do?

Understand what you need in simple language and do the task. Claude Tag figures out the steps, does the work, and posts its work back in the thread for everyone to see.

Wait, how does Claude Tag remember all that?
Anthropic states that whenever Claude is working on a task, it creates a sandbox environment for itself. That Sandbox is deleted as soon as Claude becomes inactive in that chat. Any decisions Claude made during the conversation, as well as hard rules, are recorded in a separate memory file.

And how does Claude do any job beyond Slack?
Well, you extend its reach (repos, ticketing systems, data warehouses, custom tools) through connections, plugins, and skills, configured per scope: a channel, a workspace, or the whole org separately. Meaning independent of whether you’ve set those up on the Claude app.

4 reasons why Claude Tag legitimately changes how we work.
1. It’s shared.
There exists only one Claude per channel. Everyone can assign tasks to it, see what’s being worked on, and pick up where someone else left off.

2. It remembers.
The longer Claude is in your channel, the more it understands about your work, your decisions, your terminology, your context. Tell it once, and it remembers the next time.

3. It doesn’t wait to be asked.
When you switch this on, Claude will flag things like a thread going quiet, a task nobody has followed up on, or a deadline approaching on its own.

4. It works while you’re doing other things.
Tag Claude to do a task, close the thread, and go back to your day. Claude works through it and posts when it’s done. Just like a real person would. It’s that easy.

Want Claude to do a task just for you? DM it privately. Claude will use your personal tools and connectors to finish the job.

Cool, how do you set it up?

Note 1: Claude Tag is available on Team and Enterprise plans only (Free, pro, and Max don’t qualify.)

Note 2: You need to be a Slack admin and the Owner of your Claude plan to set this up. Or get hold of someone who is.

Note 3: It might be easier to setup Claude Tag on your browser at claude.ai instead of the desktop app since it’s still in beta.

Step 1 — Connect Claude Tag to Slack

1. Go to claude.ai

2. Open the left tab and click on your username. You should see a panel pop up.

3. Now, head to Organisation settings. You should see a section for Claude Tag. Click on it.

4. Now, in the Claude Tag tab, turn on the toggle to Enable Claude Tag for your organisation. Then Click Connect. Claude generates a pairing message. It should look like this.

Copy it, paste it into any Slack channel in your organisation. Claude will reply with a code. Copy that code, paste it back into the setup dialogue. Done. Your Slack workspace is now paired.

Step 2: Give Claude access

Skip this, and you’ll have Claude Tag only doing tasks within Slack. It’ll never do tasks that require it to access other tools or skills, or work how you want it to.

How to do it:

1. In the Claude Tag tab, find Claude Tag’s access. Under it, you should see a tab called All Apps. Click on it.

2. Now, you’ll see the option to create a new Access Bundle. This is how Claude will reach apps beyond Slack, access skills, store memory, and follow guardrails.

3. Click on the ‘+’ to create a new Access Bundle. You’ll see a tab pop up.

4. Name your bundle “General Agent” and then connect it to whichever tools you want Claude to reach: Google Drive, Notion, your CRM, whatever your team uses daily.

5. Add instructions for how it should behave across the whole workspace — tone, guardrails, how to respond.

Step 3: Add your own skills

By default, only Anthropic’s official plugins appear in the plugin tab. To use your own custom skills, you need to host them on GitHub first.

Here’s how to do it:

1. Open Claude Code on the desktop and copy this prompt:

   Help me build a skill marketplace with my skills on GitHub.

   Claude walks you through the steps and provides the links; it takes about 3 minutes.

2. Once your skill marketplace repo is on GitHub, go back to your access bundle.

3. Click ‘+’ under Repositories.

4. Connect your GitHub account, select your repo, and enable it.

Your general agent now has access to all your custom skills.

Step 4: Set up channel-specific agents

Why do you need it?
Ever asked a generalist to do a specialist’s job? They can do something — just never quite the right thing. A general agent is the same.

It has no idea your sales team needs a call brief every time a lead books in. It doesn’t know your marketing channel runs on Drive. It doesn’t know to watch for anything. It just waits to be told, every time, from scratch. Channel-specific agents fix that.

How to set one up:

1. Go to the Slack tab in Claude Tag settings.

2. Click ‘+’ to add a channel.

3. It will ask for a channel ID. (You can find this by right-clicking the channel in Slack) → Channel details → View channel details. The ID should appear at the bottom.

4. Paste it in.

Once the channel is added, you can assign a specific access bundle to it — different tools, different skills, different instructions than the general agent.

For example, a sales channel might have a lead researcher bundle with Calendly connected. A marketing channel might have a content bundle with your brand guidelines loaded, and so on.

Setting spend limits on Claude Tag

How does billing work on Claude Tag?
Adding Claude to Slack doesn’t add a per-seat charge. Channel and thread work is billed by usage instead. So, it draws from a usage balance. That’s the amount your Org Owner puts in your organisation’s billing currency.

You can add a spend limit to Clause Tag to control how much money gets used within a billing period. Think of it as a way to avoid draining your account balance when using Claude Tag.

Note: Direct messages don’t draw from this balance. A DM runs on the sender’s own claude.ai account and follows that seat’s usual usage limits.

The set-up.

Step 1: Fund the balance first
Check if your organisation has a launch usage credit to run a pilot on Claude Tag. If yes, you’d only need to fund the balance after that.

If your organisation has no usage credits, the spend limit step shows Buy usage credits instead with a Buy now button — load credits, then continue.

Step 2: Set the organisation-wide limit

Head to: claude.ai/admin-settings/usage/claude-in-slack.

Choose from $100, $250, $500, $1,000 (the default), Unlimited, or Custom — a US-dollar amount up to $1,000,000.

Note: Spend limits apply at the organisation and channel level. Usage analytics and per-channel spend breakdown live on the same page.

What happens when the limit is hit?

Simply put, Claude declines to do any work that would exceed a limit. Add the balance, and you can get straight back to work.

Best practices for working with Claude Tag

1. Work in the open
Claude works best when the work is in a place where the team can see, steer, and build on it. Anything your team writes down — decisions, conventions, postmortems acts as context for Claude.

Plus, a channel with more connections produces more useful results because Claude can integrate more sources.

2. Check access always
Before you ask Claude to do anything in a new channel, run:

Why? What Claude can do differs per channel. Without this check, you may ask for something it can’t reach and get a confused result.

3. Write tasks Claude can finish on its own
Claude only needs three things to close a thread without coming back to you:

• a clear outcome

• a condition that tells it when it’s done

• for anything recurring? Set a format that doesn’t need to be explained every time.

So, state the outcome first. “Post the project status and tag me when it’s up” gives Claude something to verify. “Look at this” doesn’t because it’s very open-ended.

Next, state the end condition. And make sure the end condition is something a real person can check.

For instance, you don’t need a real person to check that a CI passes, a PR is merged, or a query returns requests. Claude can access those things and close those threads itself.

But for tasks like “does this draft look alright?” Claude isn’t the best person to answer that question. You are. In this case, you need to specify that the task is only done when you give it a pass.

Notes:
1. Claude can only check what it can reach
So, make sure you connect Claude with everything it needs to finish the task based on your rules.

2. Avoid vague conditions
Rules like “Babysit this PR until it merges” doesn’t mean Claude will check review comments before merging. That’s because it sees “until it merges as the only condition.” If you meant approvals present AND comments resolved AND your sign-off, you needed to write all three. Claude executes exactly what you say, not what you meant.

3. Tell Claude explicitly what to remember
Claude won’t save preferences it notices in passing. Say it directly:

@Claude remember for this channel: keep replies to three sentences unless someone asks for detail. Then verify: @Claude what do you remember about this channel?`

---

What’s next?

Once Claude is in your channel, the first thing you’ll notice is that nobody has to context-switch anymore. A question gets asked in Slack, the answer comes back in Slack, and the whole team sees it.

What’s more, problems start getting flagged before anyone thought to raise them. A thread that went quiet. A deadline nobody followed up on. A lead that came in while the team was heads down. Claude surfaces everything.

Then one day, Claude Tag stops feeling like a tool and starts feeling like the team got an extra person. Except this one never misses a thread. See you in the next one.

Join us at the world’s largest Hermes Builathon!

The tickets for our biggest-ever buildathon backed by OpenAI, Convex, ElevenLabs, Linkup, Dodo Payments, Cloudflare, Hissa and Wispr Flow just went live. This time, in 5 countries, 10 cities all at once.

750K+ credits are up for grabs. Bring your most ambitious ideas this July.

Attend on July 11th
Paris- Register here
London- Register here
Singapore- Register here
San Francisco - Register here

Attend on July 12th
Gurugram - Register here
Mumbai - Register here
Pune - Register here
Bengaluru - Register here
Jaipur - Register here
Hyderabad - Register here

Want to plug your brand into our newsletter?
Email us at collab@growthx.club

In the last edition, we built three graders for a newsletter idea scraper. A hard filter. A scoring rubric. And a calibration loop that checked whether the scores meant anything.

You ran an idea through the scraper. The rubric scored it. You trusted the number.

Then you ran the same idea again. Lo and behold, a different score. With the same prompt, same rubric, and same idea! Here’s why that happens and two evals that fix it.

Want to be scary good at AI?

Workflow guides got you started. But they won’t get you ahead. The founders, PMs, marketers, designers and engineers using Claude, Lovable and even Cursor — everyone who’s actually shipping — are inside GrowthX, building every weekend.

Build-focused events, expert-led sessions, AI credits, feedback, and community. It’s got everything except the excuse.

Sign me up.

Even the best language models don’t think; they predict. Every time the model reads your rubric, it’s making a best guess at what the next word should be. In clear cases, the guess is nearly always the same.

On edge cases, where your rule could be read two ways, the guess changes. The evals we discuss today solve for that.

The bad prompt problem.

Say you have a prompt that scores newsletter ideas. It’s working. Then one idea scores wrong, so you fix the prompt. You run it again. That idea now scores correctly, but another one that was scoring correctly before looks off.

Why? The prompt applies the same rules to every idea. Change the rules broadly, and both scores shift.

The fix is to show the model how the rules apply to the specific idea that was breaking by adding a worked example with a one-line explanation. The lens stays the same. The model just gets better at using it.

But how do you know what broke?

What is a regression suite?

A regression suite is a fixed list of ideas with fixed expected scores, saved somewhere the prompt can’t see them. You run every prompt change against this list. If a score shifts by more than half a point on an idea you didn’t intend to change, something broke.

Here’s an example of a regression test in action.
When we were locking in rules for our in-house news scraper tool, we scored Indian startup and business news stories across six dimensions — role reversal, public strategy failure, repeatable template, platform crossing function line, macro India insight, and global precedent.

Originally, the rule was to apply the global precedent dimension to every item, with comparable economies such as China, Indonesia, and Brazil.

Here’s how the following news topics scored.

Then we updated the rules.

The update said: global precedent only applies to seed or pre-Series A companies, or genuinely new categories.

Why? Because established companies with proven traction in India don’t need a global precedent to validate their direction. Plus, applying that rule inflated scores for established companies needlessly.

Thanks to the frozen test set, we noticed Rapido’s ranking changed exactly as we wanted in the rules. That’s a good thing. But the test set also alerts you when things go wrong. Two cases:

1. The score changes when it shouldn’t. Something you didn’t touch got affected. That’s the regression you were trying to avoid.

2. The score stays the same when it should have changed. The rule you added didn’t actually work.

How to set it up:
Create a Google Sheet with three columns: idea name, expected score, and actual score after each run. Before you make any change to the prompt, copy the current version into a new row in a separate tab. Label it with the date. That’s your version history.

After every prompt change, run your test set. Compare actual scores against expected. And don’t use the new version until you’ve traced the regression back to the specific line that caused it and decided whether to keep it.

The regression suite tells you whether a prompt change broke something. But what if you haven’t changed anything, and the prompt is still scoring the same idea differently each time you run it?

This is what a consistency check helps with.

When to run a consistency test.

Say, your news curation scraper has a hard rule: only flag items that score strictly above 30 out of 35 when the Revenue dimension is skipped. It’s a mechanical threshold, no judgment required.

And here’s what a run shows.

The scraper flagged the Amazon Now news despite its lower score. That’s an inconsistency in the output given the set of rules.

Why did it happen?
On questioning, the model stated it saw more narrative interest in the topic, meaning it made a judgment despite the rules.

The fix?
Simple, tighten the rule. Instead of flagging scores above 30, flag news topics with scores 31 and above — never flag a story scoring 30 or below, regardless of how strong the story appears.

That’s it. The gap closes.

How to run it.
Take three items — one that should always pass, one that should always fail, and one that is borderline. Run each five times without changing anything. If a clear pass fails on any run, or a clear fail passes on any run, you have a consistency problem. Find the rule the model is treating as a suggestion. Make it mechanical.

Neither of the evals we discussed today is really catching errors in the model output. Instead, they’re exposing loopholes in the rules — the same way the Amazon Now flag exposed that “above 30” wasn’t precise enough. Precise rules make AI reasoning better. And prompt by prompt, your tool gets better too.

3 months of Wispr Flow free. Start today.

Wispr Flow makes writing quick and clear with seamless voice dictation. It is the fastest, smartest way to type with your voice. Our entire team has been obsessed with it since it launched. Try Wisprflow Pro for 3 months absolutely free by signing up using the link below.

Claim Wispr Flow Pro

So, what’s the deal with Fable 5?

It’s basically Claude if it really understood what you wanted from the get go.

If Opus is the brilliant colleague who needs check-ins, Fable 5 is the one who doesn’t. It understands the goal, holds every constraint you ever told it, even mid chat, and figures out the most efficient path on its own.

It pushes back if your approach is wrong, predicts how a change in one area breaks something three steps downstream, and makes the kind of tactical calls a senior person makes — all by itself.

Realistically, that means you’re going to be spending a lot less time correcting errors or waiting for the best responses. And it all comes down to prompting the model well.

The real reason we’re using Fable 5 today.

The one thing we’ve been trying to do for a while is automate the newsletter process. One of the biggest constraints has been research. Claude (Opus included) didn’t understand the level of depth we needed or how to capture actual business insight. Instead, it required a human-in-the-loop to guide the excavation of insights.

Fable 5 changed that. In testing, it met every constraint throughout the entire session and still produced research with sufficient depth to be useful. Today, we’ll show you exactly how we set it up.

The anatomy of a prompt.

First, let’s show you a glimpse of the entire prompt.

Why did we build such a long prompt?

Because we wanted the model to think like an analyst, not a summariser. We basically had to teach an AI something that came intuitively to experienced business writers.

Our current prompt has six distinct jobs, each one solving a specific failure mode.

1. The “when you have enough, act” instruction.
It looks like this.

Why did we build it?
To avoid overplanning, all the re-stating of facts, directions left untouched, and narration of reasoning.

2. The research ladder.
It looks like this.

Why did we build it?
Without knowing why depth matters, the model treats the first page of results as sufficient. So the prompt gives it a criterion to self-evaluate against: if every claim appeared in the first three searches, you under-researched. The VERIFIED / SOURCED / ESTIMATE classification system extends this — instead of making a credibility judgment on every claim, the model runs a decision procedure it already has.

3. The separation of analysis from the article.
It looks like this.

Why did we build it?
So that the model uses the reasoning and discards the response.

4. The sub-question sequence itself inside “Find the Engine.”
It looks like this.

Why did we build it?
To dictate an analytical path, the model can’t think on its own, so it doesn’t turn to the widely covered version of the story by default.

5. The prose-over-bullets rule.
It looks like this.

Why did we build it?
So that the output looks less like bullet points and more like an actual article.

6. The pre-delivery checklist.
It looks like this.

Why did we build it?
To turn self-review from a vague instruction into an auditable process. Every section names a lever. Every advantage attaches to a number or a named competitor. The opening is a fact-gap, not a hypothetical. These are criteria the model can check each claim against, not preferences it can override when brevity seems convenient.

The output you’ll get is structurally sound. The research will be deeper than anything a generic prompt produces. The analysis will have a named competitor, a real number, and a mechanism. But the voice won’t be perfect. Some sections will go too deep where they should sprint, too shallow where they should slow down. That’s not a prompt problem you solve once — it’s a calibration you run every time.

The process is simple. Run the prompt. Read the output against your own instincts. Find the one section that feels most off. Fix the instruction that caused it. Run it again. That’s all there is to it.

Today’s edition is brought to you by Wispr Flow.

Wispr Flow makes writing quick and clear with seamless voice dictation. It is the fastest, smartest way to type with your voice. Our entire team is obsessed with it since they launched. Try Wisprflow Pro for 3 months absolutely free by signing up using the link below.

Claim Wispr Flow Pro

But first, what are evals? (And why you need them)

One thing about LLMs — they don’t retrieve answers like Google does. They predict the most likely next word until the response appears complete. Meaning, they can be confidently wrong.

An external check solves this. The moment you show your LLM what a good output is, how to get to it, and what it looks like through an eval, the LLM runs the output against the standard every time. So you can see where things are breaking and tweak your AI to get a better response.

Today’s problem statement.

We recently built a scraper to help us source topics for newsletters. It did the job. It filtered topics from the right sources, ensured they were recent, and displayed a list in the format we’d specified.

But it didn’t tell us which topics would make good newsletters. Here’s what that output looked like.

Today, we’ll build an eval for this — so the scraper doesn’t just find topics, it finds the right ones.

Wait, what is a good newsletter topic?

For GrowthX, a good topic is one that makes readers stop and evaluate a business critically. We basically had to teach an AI something that came intuitively to us.

We started by defining what “good” actually means.
After a lot of whiteboarding and looking at newsletters that did well for us, we realised good isn’t a single thing — it has levels. A topic about a no-name brand in the news from a month ago sits at the bottom. A big consumer brand with an upcoming IPO and a broader market implication sits at the top. So we built a scoring rubric around that. L1 is the weakest, L5 is the strongest — across four parameters.

Plus, not every parameter is as important for making our business newsletter. For instance, a teaching moment matters more than revenue, time and industry/topic. After all, you want to take away something after reading a newsletter. Revenue matters more than timeliness because a big number means real stakes — you’re learning from a business that has already proven something at scale, not just one that happened to be in the news this week. So on, and so forth.

This is why we added weights to each parameter.

With this framing, the AI gives each topic a numerical score. Here’s what that looks like after a run (we’re showing you two topics that scored differently based on a rubric we just created).

Why a rubric alone isn’t enough.

See the SoftBank story above?

It almost ran in the newsletter. The problem? SoftBank is not a business builder. It’s an investor booking profit, not a business lesson a founder would like. The rubric had no way to catch this because the rubric only scores what’s there — it doesn’t check what’s missing.

Having a hard filter (code-based grader) helps here.
Before the rubric runs, every story passes through a set of binary checks. Just pass or fail.

In this case, a hard filter asks this: Is there a single named company at the centre of the story? Is it in a sector we cover? Did it happen this week? Is the primary actor a founder or operator — not an investor doing a transaction? If any check fails, the story drops.

The SoftBank story fails here — the primary actor is an investor, the transaction is purely financial, and there is no operating company strategy angle. Drop and done.

What happens if the eval still breaks?

Look closely at the PhysicsWallah article that passed.

Our AI model gave it a high score despite it not having a clear business learning. Why? The model used the rubric, which only said ‘broader market future prediction’ — and a single fine got inflated into a structural India signal. Vague language was producing a wrong answer.

Enter the calibration loop (human grader)
We updated the rubric. L5 now requires: a new law, regulation, or market structure shift. A single enforcement action does not qualify unless it creates a legal precedent that changes how all companies in the sector must operate.

After the update, the same story re-scored: L2.

Here’s what a good topic looks like now.

This is just the tip of the iceberg.

We covered three graders here. A hard filter, a scoring rubric, and a calibration loop. That is a working eval for a newsletter topic scraper — built inside a Claude project, no code, no infrastructure. It is also the simplest version of what evals can do.

The same logic applies to customer support agents, research tools, coding assistants, onboarding flows or any system where you need to know whether the output is actually good before it reaches a user.

There are also eval types we haven’t covered, such as regression suites, capability benchmarks, and multi-trial consistency checks. Each solves a different failure mode.

We’ll walk through a few more in upcoming editions. Stick around for the ride.

Subscribe now

Sign me up.

Today’s edition.

If you’ve used OpenClaw to set instructions that run routinely, you know OpenClaw is sort of terrible at retaining context. Persistent memory in OpenClaw requires manual setup, third-party plugins, and the right session configuration.

Hermes ships with memory on by default. It launched in February 2026 and crossed 140,000 GitHub stars in under three months because it does the one thing everyone wanted without asking: it remembers what happened last time.

Today, we’re using that to build a pricing monitor that runs periodically. No code. No server. No engineering ticket. Just plain English and 60 minutes.

But wait, why should we build a pricing monitor with Hermes?
A pricing monitor has three parts: a page reader, a comparison tool, and a logic that tells you when two versions of the page don’t match. Normally, that’s three separate tools, a database, and a developer.

Hermes collapses it all into one. It visits the page, holds the memory of what it saw last week, runs the comparison, and messages you on Telegram if anything moved. You don’t configure any of it. You describe what you want in plain English, and it figures out the rest.

Part 1: Install Hermes on your device.

1. Head to Hermes’ official website. Here’s the link.

This is what you should see.

2. Copy the install command.
3. Now, head to your Terminal and paste the install command. You should see a purple installer screen that says “Hermes Agent Installer”. This is the tool that installs Hermes onto your device. It takes about 4-5 minutes, so don’t close your window.

When it finishes, you’ll see a green Installation Complete screen with a list of next steps.

Part 2: Connect your AI model.

Hermes needs a brain. We’re using Google Gemini — free, no credit card, no expiry.

1. To get your Gemini API key, open aistudio.google.com in your browser and sign in with your Google account.

2. Click Get API Key in the left sidebar. Click Create API key, select a project from the dropdown, then click Create.
3. Copy the key somewhere safe and keep this tab open.

Run the setup wizard on your Terminal.
Copy the following exactly and hit Enter.

Next, select your AI provider.
A long list appears. Arrow down to Google AI Studio (Gemini models — native Gemini API) and hit Enter. Paste your API key when prompted, then press Enter. Then arrow down to gemini-2.5-flash and hit Enter.

The wizard will ask you to setup terminal backend next.
Keep current (local) selected. Hit Enter to confirm. This way, all commands run on your computer.

Now, set your working directory.
Hit Enter to accept the default [.] This is where Hermes sets commands to run periodic tasks.

Skip sudo.
Type N and hit Enter. This means Hermes cannot run administrator-level commands on your device.

Congratulations, Hermes now has a brain!

Heads up: Hermes runs on your device, so your laptop needs to be open and on for the monitor to work. It does not run when your Mac is shut down or asleep. If you want it running 24/7, you’ll need a cloud server. So, if you’re running a schedule, make sure you choose. time when you’re actually sitting on your laptop.

Checkpoint: If the installer gets stuck at “Trying SSH clone...”

Wait 60 seconds. If nothing moves, press Ctrl + C to cancel. Then run these two commands one by one:

This does the same thing as the installer — just takes a different route.

When it finishes and asks “Would you like to run the setup wizard now?”, type Y and hit Enter.

Connect Telegram to Hermes.

In the Terminal, run this:

A list of messaging platforms appears. Move to Telegram, get the Space button, and press Enter.

Paste your bot token when prompted and hit Enter.

How to get Telegram Bot token —
1. Open Telegram and search for BotFather
2. Type /newbot and follow the on-screen instructions.
3. Copy the HTTP API token.

Now move to the final steps.

Now open Telegram, search for @RawDataBot, and send it any message. Copy the number next to “id” in the reply. Come back to Terminal and paste it. Hit Enter.

When asked to use your user ID as the home channel, type Y and hit Enter.

When asked to install the gateway as a background service, type Y and hit Enter.

Congrats, your Telegram is now connected to Hermes!

Start the gateway to receive Telegram messages.

In the terminal, copy this exactly.

You’ll see Hermes confirm it’s running. It’s now listening for messages from your Telegram bot in the background.

Verify web search is on.

This will help our bot read pricing pages of the tools we mention on the web.

1. Run:

2. Select Configure CLI.
3. Scroll to the top of the list and confirm Web Search & Scraping has a [✓] next to it. If it does, hit ESC and move on. If it doesn’t, press Space to enable it, then Enter to confirm.

Part 4: Build the pricing monitor.

Everything is set up. Now you tell Hermes what to do — in plain English, on Telegram.

Open your Telegram bot. Send it this message, replacing the URLs with your actual competitor pricing pages:

Hermes will confirm the schedule and the URLs with you. Read it. If anything looks wrong, correct it in plain English.

Test it immediately. Send this to your bot:

Within 2 minutes, you should receive a Telegram message with everything Hermes found on the Notion pricing page.

If the message arrives, the monitor is live. Here’s my message for reference.

How to add or remove URLs.

The monitor starts with one URL. Adding more takes one message.

To add a competitor. Send your Telegram bot:

Similarly, you can remove competitors or even check the list of competitors to track. Just send a message to your bot.

What’s next?

You just built something most teams don’t have. The same setup runs a changelog watcher, a job-posting tracker, and a review-spike detector. Same Hermes. Same Telegram. All you need to do is add a different prompt.

Apply for access

Today’s edition.

Most people who use Claude or ChatGPT do so in the same way. They open a chat, type something, read the response, and close the tab. It’s a lot like how you’d talk to Google if it were a little bit ‘smarter’.

Claude also allows you to build apps on top of its chat interface with Instructions. Today, we’ll explore how to use this feature to build a Competitive Intelligence Brief Bot from scratch.

What are Instructions?

Claude allows you to set Instructions inside a Project. Think of Instructions as a rulebook — a fixed set of rules that the chat has to follow every time someone opens it.

That makes your Claude chat a workflow. The user has a text box to type into. Claude is the LLM layer that processes whatever comes in. The Instructions are the logic that connects the two. Put those three things together, and you have something that works a lot more like an app than a chatbot without writing a single line of code.

Part 1: Scoping the tool.

Here’s what a Competitive Intelligence Bot should have.

1. An input box to enter your own app to find reviews of similar tools
2. A way to get reviews
3. A way to analyse reviews

LLMs already serve as the analysis layer. And theoretically, you could use a scraper app to collect reviews, connect it to a form, and use an LLM to identify which tools to get reviews from.

The problem?
One, you’d get an extremely large response with hundreds of directions on what to build next. After all, G2 houses reviews for 1000s of apps. Besides, product managers already know which three or four tools are competing for the same customer they are trying to win. Those are the ones worth watching.

That made the scraper unnecessary.
G2 already generates a public RSS feed for any product’s review page. A product manager can open that feed in their browser, copy what is there, and paste it into Claude in ninety seconds. No scraper. No scheduler. No form. Just the reviews that matter, from the competitors that matter, processed immediately.

Part 2: Refining the tool.

Here’s the thing about reviews. They are an incredibly messy dataset.
They are written by people who felt strongly enough to spend ten minutes writing one, which means they are not a representative sample of all users. They skew toward extreme experiences. Someone who had a bad onboarding week writes about the entire product as though it is broken. Someone who got surprised by an invoice writes about pricing as though the company is dishonest.

Reviews also cannot tell you what the user tried before giving up, what they switched to after leaving, or whether the problem they are describing was fixed in a product update two weeks before they wrote about it. And because each reviewer is writing in isolation from every other reviewer, the same underlying problem can appear in ten different reviews described in ten completely different ways, making it look like ten separate problems when it is actually one.

The result is a dataset that is high volume, emotionally uneven, unrepresentative, lagging, and fragmented. Using it without any processing does not give you competitive intelligence. It gives you a list of complaints weighted by whoever happened to be angry enough to open G2 that week.

The fix?
We built a set of rules that run before any analysis happens. Think of them as filters that surface which data is worth paying attention to.

How do you know which rules to set?
Ask Claude. And keep testing the responses. Stop when you hit a passable response, with a good output format and the least tokens trifecta.

Here are the rules we settled on for our prompt:
1. Volume.
We limit the time window so that only recent reviews are included in the analysis. We set a minimum threshold so that a problem must appear more than once before it counts as a pattern. These two rules alone eliminate the majority of the noise.

2. Relevance.
We check each reviewer’s role and company size against the target customer's criteria before the review enters the analysis phase. After all, a review from the wrong customer is not a useful signal, regardless of how well-written it is.

3. Nature of the complaint itself.
Not every frustration represents a gap worth building for. We distinguish between a user who was annoyed and one who could not move forward, and only the second kind enters the brief. We also check whether the language suggests the user is actively evaluating alternatives, because that changes the urgency of the finding.

4. Honesty.
Every finding gets assessed against the PM’s own product to give a brief with relevant next steps. If the answer is unclear, the brief says so rather than defaulting to a reassuring conclusion.

None of these rules fixes every problem with reviews as a dataset. But together they narrow a large, uneven, emotionally driven corpus down to a small number of findings that are recent, relevant, and honest enough to be worth acting on.

Part 3: Instruction set up.

Once you land on an output you like, ask Claude to build instructions based on your conversation. Here’s the exact prompt you can paste into your chat to build instructions for your specific Competitive Intelligence Brief.

Want the Instructions for the Brief we worked on?

What next?

We have shared the complete brief and the full instruction set that powers it. But the best way to understand what it does is to run it yourself. Paste the instructions into a new Claude project, drop in a competitor RSS feed, and see what comes out. The output will tell you more about what the tool is doing than any explanation we could write here.

From there, tweak. If the findings feel too broad, tighten the ICP. If the brief feels too long, cut a card format field. If the one question at the end does not feel specific enough, adjust the instruction that generates it. The instruction set is written in plain English precisely because it is meant to be edited by someone who is not a developer. Every rule in it is a decision that can be revisited once you see how the tool behaves in practice.

That’s all there is to it. Happy building!

Most voice agents never leave demo. Solving cost, latency, and memory together is hard. Optimising it in a day — forget about it.

Up for the challenge? ElevenLabs is covering the credits. You pick the brain — OpenAI, Claude, or Gemini. We’ll give you the perfect focus room to build.

Sign me up. Now.

Today’s edition.

Your Slack’s going off all day. 100 notifications total. You need to focus so you hit Mark All as Read.

Boom. You just lost track of all your open threads.

Today, we’re building a Dependency Tracker for this exact issue. It scans your Slack workspace every 48 hours, finds messages you sent with no reply and direct mentions you haven’t responded to using AI, and posts a clean two-section summary straight to your Slack DM. All under 40 minutes.

Set a timer and open a new tab to view this email. We’re getting straight into it.

What you’ll need.
A Slack account with access to at least one workspace. Ideally, this should be the workspace where you could potentially have open threads. A free Groq account. This is our AI layer today, and it has a generous free tier. A Google Account. We’ll use it to test out code on Colab. And a Pipedream account (it’s similar to Make) to set up the actual scheduler and code.

Step 1: Get your Slack token

1. Go to api.slack.com/apps
2. Click Create New App → From scratch

3. Name it anything — Dependency Tracker works. Select your workspace and click Create App

4. On the left sidebar, click OAuth & Permissions

5. Scroll to User Token Scopes and add every scope in this list:

6. Scroll back up and click Install to Workspace
7. Copy the token that starts with xoxp- and save it somewhere safe

Step 2: Get your Groq API key

1. Go to console.groq.com

2. Sign up with your Google account — no credit card needed
3. Click the API Keys button at the top

4. Click Create API Key, give it any name, and click Submit

5. Copy the key and save it next to your Slack token

Step 3: Set up Google Colab (your test environment)

1. Go to colab.research.google.com

2. Click New Notebook and rename it — Dependency Tracker works
3. Click the key icon on the left sidebar to open Secrets
4. Add two secrets:

• Name: SLACK_TOKEN — paste your xoxp- token as the value

• Name: GROQ_API_KEY — paste your Groq key as the value

5. Toggle both secrets on

Step 4: Code testing in Colab.

1. Install the pip slack and groq libraries.
This installs the relevant Python packages for the Slack SDK and Groq so you can use them within Python. Here’s how you do it.
- Copy this line of code exactly into the first empty cell of your notebook and click on the small play button at the start of the cell.

You should see lines of text pop up on your screen and a small check mark next to your cell. This means your code ran successfully.

Next, add a new code block by clicking the Code button at the top.

Then, load your credentials. To do this, copy this code exactly into the new code block/cell and click on the play button to run the code.

If prompted, click Grant access. This pulls your tokens from the secrets panel into the script — they never appear in plain text in your code.

Step 4: Run the tracker.

Add a new cell by clicking the Code button, copy this code, and run it.

When it finishes the run, you should see ‘Posted to your Slack DM ‘ in the notebook, and the summary arrive in your Slack DM.

Step 5: Automate your code with Pipedream

1. Go to pipedream.com and sign up with your Google account — no credit card needed.
2. Click New Workflow and name it Dependency Tracker. Click on Create project and continue.

3. Set the Timeout to 300 seconds and click Create Workflow. Doing this gives enough time for your script to go through all your Slack messages and highlight conversations that need to be followed up on. Don’t worry, this 300s lag will happen in the background, so you’ll never really notice it.

4. You should now see your workspace with an Add Trigger button. Click on it.

5. Select Schedule, then click the Custom interval tab.

6. Set the interval to every 48 hours. This ensures your script runs only once every 2 days. Then set your time zone to your location.

7. Click the + below the trigger and select Run Python code.

8. Next, click on the Cube at the top of your screen. Go to Environment Variables in the left sidebar and add two variables:

• SLACK_TOKEN — paste your xoxp- token

• GROQ_API_KEY — paste your Groq key

9. Now, click on Dependency Tracker, navigate to the code step and click on it. Clear the editor, and paste the code below.

Click Test — you will get a Slack DM confirming it works. Then, click Deploy.

Try it and tell us what you think!

You’ve watched the tutorials. You’ve tried to follow along. Then the tutor says “just pip install the library” — and suddenly you’re in a whole new rabbit hole.

Building with AI is hard when you’re starting out. We make it easier by putting you in the same room as builders at the frontier — online and offline.

Check out GrowthX events

Today’s edition.

One week ago, Meta launched its official Meta Ads Model Context Protocol (MCP) server for Claude. And if you’re a marketer, that means your life just got a whole lot easier. Now, thinking, analysis, and creative direction can happen from within Claude.

Today, we’ll connect the Meta Ads MCP to Claude and build a simple ad validator that checks your new creatives against the patterns in your best-performing ads — and tells you exactly what to fix before you spend a single rupee on them in 60 minutes.

Set a timer and open a new tab. We’re getting straight into it.

What you’ll need.
A Claude Pro account (~ ₹1,900/month — use claude.ai on the web, not the app store, to avoid extra charges). You can access MCP only on a Pro or Max plan today. We recommend starting with the Pro. Your signed-in Meta Ads account has a few past creatives. That’s it.

Heads up: This works if you’ve got the Meta Ads MCP update only.

Step 1: Setting up the Meta Ads MCP

The official Meta Ads MCP endpoint is mcp.facebook.com/ads. Here is how to add it to Claude.

1. Open Claude — desktop app or claude.ai in your browser.
2. Go to Settings → Integrations (on Claude.ai) or Settings → Connectors (on Claude Desktop).
3. Click Add Integration and paste this URL. Enter the URL as shown and click Add.

4. You’ll see the Meta Ads MCP get added to your connectors. Click the ‘Connect’ button. Claude will prompt you to log in with your Meta Business account — the same login you use for Ads Manager. Click through and authorise access. Here’s what you should see.

Congratulations! You’ve connected successfully to Meta Ads MCP.

Step 2: Set up your Claude Project

A Claude Project is a workspace that remembers your brand permanently. Every time you open it, Claude already knows who you are, what you sell, and exactly what to ask you. You set this up once. You never repeat it.

Step 2a: Create a new Project.
Open Claude.
1. In the left sidebar, click Projects → New Project.

2. Name it something you will recognise — Ad Validator works perfectly.
3. You will see a field called Project instructions. Click on it. This is where the rulebook lives.

4. Head over to instructions and copy this prompt into your project.

5. Once you start a new chat inside the Project, Claude will ask you seven questions about your current campaign — one at a time. Answer them as specifically as you can. The more detail you give, the sharper the output. Claude will then check your Meta Ads account for live data. If your campaigns are active, it pulls everything automatically. If not, it walks you through finding your historical ads in Ads Manager step by step.

At the end, you will have three things: a plain English diagnosis of why your ad is not working, two ad copy options ready to use, and three image generation prompts you can paste directly into Gemini or OpenAI to produce your next creative. The whole process takes only ~15 minutes once the setup is done.

Try it, and tell us what you think.