Every morning, my inbox automation posts one triage report to Slack.

The report covers four Gmail accounts: personal, newsletter, business, and payments. Its sections change depending on what happened. One morning might include messages worth reading, payment alerts, emails that need replies, automated noise, and an infrastructure problem hidden inside an email.

Before this setup, I had two ways to handle the report.

I could open Gmail, click through each account, find every message, and move the work forward myself. That was tedious, and it was easy to miss something while jumping between inboxes.

Or I could open Claude, let it read the entire report, and ask it to work through everything with me.

That was easier at first. But then one Claude conversation started holding several completely different kinds of work. Claude might be helping me clean up promotional email, then investigating a failed automation, then capturing information for another project. When I returned to the first problem, its context was buried beneath everything that happened after it. And if I was outside or my computer was closed, the work had to wait.

The report was one document. The work inside it was several different jobs happening in different locations.

To solve this problem, I needed two-way communication where I could message Claude from a messaging app, separate each piece of work into its own conversation, and let Claude keep working in the cloud when I’m away from my computer. Claude’s questions, updates, and results would come back to the same Slack thread where that job started. The same kind of work I already do through OpenClaw and Hermes, but with a smoother experience.

Since then, I tried most of the messaging paths and ended up loving how easy and organized it is to use Slack with Claude.

In this article, I’ll show you:

• Turn One Morning Report Into Separate Claude Jobs From Your Phone

• Run Research, Content, and File Changes From One Slack Setup

• What is running behind the Slack thread

• A step-by-step guide to building a two-way work surface between Slack & Claude

  • Download the Setup Package

  • Before You Connect Claude to Slack

  • Connect Slack, GitHub and Claude

  • The Slack to GitHub to Claude Loop

  • Add Gmail Only After It Works

• What Claude in Slack Cannot Do

• Run Your First Bounded Job

• Bonus: a downloadable package with guides on how to set up Slack, Gmail, and GitHub, the workflow files that run them, plus a prerequisite checker and troubleshooting

Hi, I’m Jenny 👋
I believe anyone can thrive with AI, not by mastering the tools, but by building real things with them. I run Build to Launch and the Practical AI Builder program, where we go from experimenting to shipping. Come build with us.

If you’re new to Build to Launch, welcome! Here’s what you might enjoy:

• Everything in Claude

• Multi-Gmail MCP Guide

• AI Automations

Subscribe now

Turn One Morning Report Into Separate Claude Jobs From Your Phone

My four-account Gmail setup still produces the same morning report. I changed what happens after I read it.

I select one part of the report, give it its own Slack thread, and ask Claude to handle it there.

• A worth-exploring policy decision can become one conversation.

• An inbox cleanup can become another.

• Capturing the report’s action items in my TaskNotes can become a third.

The report stays one document. Each job gets its own conversation.

Inside one thread, I can question Claude’s reasoning, change the instruction, approve the next move, or return later to see what happened. Claude’s questions, updates, and result come back to the same place where that job started.

I can do all of this from my phone. Claude can keep working while I am outside or my computer is closed, without mixing every job from the morning report into one growing conversation.

One Slack thread becomes one unit of work.

A later follow-up came through Slack. I asked Claude to check gmail-personal and do the same there.

It found 658 unread Promotions messages going back to 2014, and told me the number before it touched any of them.

That is the part that caught me. I could see the size of the work from my phone, decide whether the scope was sensible, change the instruction, or stop.

This is where two-way communication changes an automation. The report no longer has to be the end of the process. It becomes the start of a bounded conversation.

Run Research, Content, and File Changes From One Slack Setup

The same Slack setup also helps me with work that has nothing to do with my inbox.

In one conversation, I asked Claude to improve the SEO description for one of my published articles. I gave it the recommendation, told it to change only that description, and asked it to report back.

Claude found the article, made the change, and returned in 34 seconds. Nothing else in the article was touched.

In another conversation, I asked Claude to create new Substack notes from my existing instructions.

Claude read my notes strategy through the pre-set Substack MCP, my best-performing notes data, and the published content behind those ideas. It drafted 16 new notes, saved them as a batch for me to review, and returned in 11 minutes 27 seconds.

It also told me that it could not send them directly to Substack from that run. It stopped at the reviewable batch and told me exactly what was missing.

A third conversation started with an idea that was still rough:

Explore how red team experiments impact normal users.

Claude searched the existing work behind that topic, checked whether I meant a content idea or an engineering task, and developed the idea from there. The result returned in 1 minute 5 seconds.

I did not have to remember which folder held the earlier work or explain the entire project again. Claude could read the context already attached to my work.

From there, I decide what deserves another question, what should become a separate job, and what I want to leave alone.

Each one has its own conversation. I can move among them from Slack without mixing their context together.

Slack is where the conversation happens. Claude Code is where the reasoning and work takes place.

What Is Running Behind the Slack Thread?

Slack carries the conversation. Claude takes the action. GitHub gives that chain of decisions a permanent workspace.

I want to explain GitHub a bit more because it might sound too technical here. If you are not familiar with it, my GitHub guide for non-programmers explains why GitHub is becoming relevant to your work, even if you are not a programmer.

I chose GitHub as the decision workspace for three major reasons.

First, GitHub preserves the history. Once Claude saves a change to the repository, you can see what changed, when it changed, and what the file looked like before.

Second, one GitHub issue gives each job a boundary. The issue holds your original request, Claude’s response, your questions, and every follow-up. You can return days later without rebuilding the conversation from memory.

Third, the GitHub has generous free tier. I never needed to pay to use it. You can create the repository, open issues, keep the change history, and build this working loop without adding another monthly subscription.

I’m betting on GitHub will become much more common for one-person businesses as AI takes on more work.

That creates the chain I use. A report arrives in Slack. I choose one part that needs work and continue it in its own thread with Claude via GitHub.

The paid section below gives you the complete build:

• Download the AI-readable setup package and check the prerequisites before Claude changes anything.

• Connect Slack to Claude.

• Connect GitHub to Claude through your subscription.

• Make Claude work with Slack through GitHub.

• Add Gmail after the conversation works

• With prompts that keep each action bounded and bring the result back for your review.

Download the Setup Package

Read more

You have heard people mention GitHub for years now. Developers live there. Your AI tools keep asking to connect to it. And every time you looked, the page said something about repositories and pull requests, and you closed the tab.

I did that too, for about four years.

Somewhere on your machine there is a folder with draft-final.md, draft-final-v2.md, and draft-final-ACTUAL.md in it. Maybe you have an AI assistant you like, and you still will not let it touch the files that matter, because what if it changes something and you cannot get it back.

People tried to make GitHub work for writers before, and it didn’t stick, because you had to learn Git. You don’t anymore.

That is the whole change, and it is smaller than it sounds. Git is the thing underneath, the part with the intimidating vocabulary. It used to be that a person had to operate it. Now an assistant does, and what is left is a website with buttons.

Which matters because of what was sitting under there the whole time. Last week I published a comparison of every way I know to run something on a schedule. Claude routines, Cowork, ChatGPT, Perplexity, Gemini, Copilot, n8n, cron, launchd. Ten of them. The one that had been quietly running my work all month was not in it, because I had never thought of it as a scheduler.

That missed piece is in this article.

Three things GitHub gives you that have nothing to do with code, and one small way to try it.

What’s inside:

• GitHub’s own page never says “code”: what the five words actually mean

• People tried this before: why it failed, and what changed

• It remembers: the version you regret, still there

• One job, one conversation: a thread with its own address

• A free computer: that runs when you aren’t there

• Five buttons, four words: the commands you never type

• Your first twenty minutes: from nothing to a file with a history

GitHub’s own product page never says the word “code”

Go to the pricing page and the headline reads “the complete developer platform.” Open the vertical they built for government and it says “Government Agency Software Development Solutions.”

They are talking to programmers. Loudly, and on every page.

Then look at the product menu, which is the part written by whoever had to describe what the thing does. Issues: “Plan and track work.” Actions: “Automate any workflow.”

Neither one says code.

That gap is the whole opportunity. The marketing was written for the audience they have. The product descriptions were written for what the product is.

The five words

Here is the vocabulary, one line each. Everything else you will ever read about GitHub is built from these.

Read that list again and notice how ordinary it is. A folder. A save. A thread. A scheduled task. A proposal.

The words sound technical because programmers named them, and programmers name things after the mechanism. If a writer had named commit, it would be called “save with a note,” and nobody would have been scared of it.

People tried this before, and it didn’t stick

I want to be honest about this, because it is the reason you have not already done it.

Penflip was GitHub for writers. It is closed. Authorea was GitHub for scientists, it raised real money, and it got absorbed into a publishing company. GitBook started out wanting to be the place books were written and now sells technical documentation software.

Three serious attempts, all of them building the same thing: a friendlier face on top of Git.

In 2013 two researchers at MIT published a paper asking why Git is so hard, and their answer was not that people are lazy. They found the difficulty is in the design. The concepts do not match what users are actually trying to do, so no amount of tutorial fixes it. A better button on top of the same idea does not help.

That paper explains every one of those closures. The interface was the problem, and they all tried to decorate it.

So what changed is not the interface. It is that you are no longer the one operating it. You describe what you want in a sentence, an assistant does the Git part, and you look at the result. The layer that defeated three companies is now somebody else’s job.

That is a real shift, and it is worth being suspicious of anyone who tells you the tool got easier. It did not. The tool is the same. You just stopped having to drive it.

It remembers every version, including the one you regret

Every save is kept. Not a backup of the current state, every state, with a note on each one saying what changed and who changed it.

Dropbox and Google Docs have version history too, so this sounds like a small thing. It stops being small the moment something other than you is doing the editing.

I asked Claude, through Slack, to count something in one of my files. It came back with 27, and cited the exact line range it had used. I opened the same file and counted 41. So I told it that it was wrong.

It went back, checked again, and held its ground. Still 27. Here is the heading on line 13, here is the next one on line 43, and the line you are looking at is inside a different section entirely.

It was right and I was wrong. My file had unsaved changes that pushed the section forty-eight lines further down. It was reading the committed version. I was reading the one on my laptop that existed nowhere else.

Two files, same name, both answers correct.

I had expected the failure mode of working with AI to be the model confidently making something up. What actually happened was the model being confidently right while I supplied it bad evidence and argued.

The history is what let me find that out in ninety seconds instead of never. And it is why “what if it breaks something” stops being the deciding question. You can see exactly what changed, and you can put it back.

One job, one conversation, one address

Think about how you use an AI chat now. One long session, a dozen unrelated things in it, and by Thursday you cannot find the decision you made on Tuesday.

An issue is the opposite shape. One thread, one piece of work, and a link you can send to a person or hand to an assistant. It holds the request, the evidence, your pushback, the answer, and the result. Then you close it and it stops being an open question.

Kent Gigger runs his whole practice this way. Client briefs, email templates, an editorial calendar, and a shared to-do list, all in a private repository his assistant reads and edits. He ticks the checkboxes from his phone.

His description of the setup is one sentence: “Everything is markdown. No database, no app, no SaaS tool.”

No project management subscription. No tool to migrate off in two years.

A free computer that runs when you aren’t there

This is the one with no substitute, and the one I had missed on my own list.

An Action is a computer GitHub starts for you, runs your instructions on, and shuts down. On a schedule, or when something happens. You do not own it, rent it, or keep it awake.

Two weeks ago I asked Claude, from Slack, to clear the promotional mail out of one of my inboxes. It found 23, marked them read, and reported back in 1 minute 13 seconds. Then I asked it to check the next account and it found 658 going back to 2014, and told me the size before touching any of it.

My laptop was shut the entire time.

The free allowance is 2,000 minutes a month, 3,000 on Pro. Worth knowing: that budget belongs to your account, not to each repository, so ten projects share one pool. Public repositories do not count against it at all.

Two honest limits. A schedule is best effort rather than a clock, and GitHub says plainly that runs can be delayed and some queued jobs may be dropped. And on a public repository, a schedule switches itself off after 60 days with no activity.

So it is excellent for a nightly job and wrong for anything that must happen at exactly 9:00.

The five buttons, and the four words you never type

This is where most guides lose people, so let me be direct.

The next twenty minutes need nothing installed. Every step in the following section happens at github.com in your browser. No terminal, no downloads, no Git.

Two things do take setup, and I would rather say that here than at the end. Connecting an assistant to your repository is a one-time step, and so is the computer that runs while you sleep. Neither is in your first session. Both are linked at the bottom of this piece.

The five things you will actually click:

New repository · Add file · Commit changes · Issues → New issue · History

That is the interface. Five buttons.

And the four words you will only ever read, never type:

• commit is a saved version, with a note

• push is sending it up to GitHub

• merge is combining two versions

• pull request is a proposed change, before it happens

You need to recognise these, because your assistant will report back using them. When it says “committed and pushed,” you want to know that means saved and uploaded, not deleted. That is the whole requirement.

What you say instead of typing any of it sounds like this:

Read the file I just added, fix the three broken links, and save it with a note saying what you changed.

Your first twenty minutes

Six steps. Nothing here can break anything you own, and step six is how you prove that to yourself.

1. Make an account

Go to github.com and click Sign up. Email, password, username, and a verification code. Free, no card, about two minutes.

The username becomes part of every address you make later, so pick the one you would put on a business card rather than a joke.

2. Make a private repository

On your home page, click the green New button, or go straight to github.com/new.

Three things on that form matter:

• Repository name. Lowercase, hyphens instead of spaces. my-drafts works.

• Private. Select it. Public means the whole internet can read this, and you can always switch later.

• Add a README file. Tick it. It gives you a file to look at instead of an empty screen.

Then Create repository.

3. Put one real file in it

Click Add file, then Create new file.

Name it something ending in .md, like notes.md. The .md means markdown, which is just text with a couple of formatting shortcuts. Then paste in something real. Not a test. A draft you are working on, a list you keep losing, notes from a call this week.

Now look at the bottom of the page, because this is the part that matters. There is a box asking what you changed. That box is the whole point of the system. Write a short honest sentence: “first draft of the launch email.”

Click Commit changes.

4. Change it, and save again

Open the file and click the pencil icon. Change one line. Anything.

Scroll down, write a different note in that box, and commit again.

You have now done the thing. Twice.

5. Look at what you built

On the file page, click History.

Both versions are listed, newest first, each with the note you wrote and the time you wrote it. Click either one and GitHub shows you exactly what changed between them: removed lines in red, added lines in green.

This is the view that makes the rest of it safe. Anything that ever edits this file, you, an assistant, or someone you invite, shows up here with their name on it.

6. Undo it on purpose

Do this one deliberately, while nothing is at stake.

From History, click the older version. You are looking at the file exactly as it was before your edit. Copy what you see, open the current file, paste it back over the top, and commit with the note “restored the earlier version.”

Nothing was lost. The change you undid is still in the history too, because nothing here deletes.

That is the step worth doing slowly, because everything else in this article rests on it. Once you have put something back yourself, “what if it breaks something” stops being the question that keeps AI away from your real work.

Then stop

That is the whole first session. Do not import your archive.

German federal law lives in a public repository. 1,916 people starred it, eleven contributed, and it has not been updated since November 2022. The equivalent project for US Congress is still going after thirteen years, with 44 contributors and 783 saves.

Same idea, same tools, opposite outcomes. The difference was whether anyone kept showing up.

So start with the one file you will actually open again next week.

Now hand it to your assistant

The point of putting the file there was never the folder. It was that something else can now safely work in it.

Once your repository exists, connect Claude to it and try a sentence like this:

Read notes.md, tidy the formatting, and commit it with a note saying what you changed. Do not change any wording.

Then open History and read what it actually did. That loop, ask, check the diff, keep or restore, is the whole working relationship.

Three guides in the Build to Launch library cover the connection itself:

• GitHub MCP Setup connects Claude to your repositories so it can read files and open issues from a chat.

• Run Claude from Slack With Your Laptop Closed is the version I use daily, where a message becomes an issue and the answer comes back to the thread.

• Run Local MCP Servers Inside GitHub Actions is the step after that, for when you want it running without you.

When something does not behave, GitHub’s own documentation is genuinely good for the interface itself.

Next Steps

What you can do today:

1. Put one real file in a private repository. Twenty minutes, following the six steps above. Change it once so you have a history to look at.

2. Restore the old version. Deliberately, while nothing is at stake. This is the step that changes how you feel about letting an assistant near your work.

3. Point your AI tool at it. Ask it to read the file and change one thing. If you want the bigger picture first, my guide on how to build an AI agent covers where this fits. Then read the history and see exactly what it did.

If you have been keeping AI away from anything that matters, that third step is where it stops being a reasonable fear.

If this read is useful, share this to the person you know who might benefit from reading it.

Share

If someone shared this with you, thank them, and subscribe so you won’t miss the next useful guide.

Subscribe now

What is the one file you would put somewhere that remembers it?

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

A few weeks ago, one of my subscribers sent me this question:

My first reaction was: I think I already answered this.

My Claude Code beginner’s guide walks through the setup and recommends creating a CLAUDE.md. I had also written about more general claude onboarding and token optimization.

But when I checked .claudeignore again, I found things had changed. I could no longer find it in the current Claude Code setup, which meant the advice in my earlier article was no longer valid. So I went back and corrected the article. I’ll come back to what changed later.

His question named CLAUDE.md and .claudeignore, but I think he wanted something deeper. He wanted Claude to recognize his project and what mattered in it without filling the context window with instructions for other work.

The token cost mattered. What worried me more was losing control of Claude’s behavior after I had already written the rule.

So I went through the current Claude documentation to see what had changed and what matters now.

The result is a five-layer map for deciding where each instruction belongs, along with the commands for measuring your own setup before and after a change.

What’s inside:

• Before you type: what is already in context, and how much of it you wrote

• The 5 layers: where an instruction can live, and when each one loads

• 200 lines: the size target, and why @ imports don’t beat it

• The ignore file: why yours does nothing, and the rule that works

• Your own number: /context, /doctor, and the hook that logs what loaded

• The audit prompt: the layer call /doctor leaves to you

• The complete project: where every file goes, what each one contains, and how to reload it

What Claude loads before your first prompt, and how much you control

A CLAUDE.md is a plain Markdown file Claude Code reads before it starts working in your project. If you do not have one, run /init. Claude reads the repo and creates a starter with build commands, test instructions, and project conventions.

There is no fixed template. After /init, the file grows with the project. You add a database note, a naming rule, then another instruction after Claude breaks something once. Claude loads the whole file again at the start of every session.

Depending on your setup, the project file may load alongside parent-directory CLAUDE.md files, your user file at ~/.claude/CLAUDE.md, CLAUDE.local.md, and auto memory. Together, they form the instruction stack already sitting in context before your first prompt.

(This guide focuses on Claude Code. Cowork handles standing instructions separately.)

To see how much of the context window you control, you first have to separate your files from everything Claude Code brings into the session. The context window documentation gives a representative 200,000-token session with this breakdown:

What Claude brings to the session:

• system prompt: 4,200 tokens

• skill descriptions: 450

• environment info: 280

• MCP tool names, with schemas deferred: 120

What comes from your setup:

• project CLAUDE.md: 1,800 tokens

• auto-memory MEMORY.md: 680

• user ~/.claude/CLAUDE.md: 320

Add the published numbers and the session starts with 7,850 tokens already in use, about 3.9 percent of the 200,000-token window. The 7,850 total and the 3.9 percent are my calculations from the individual amounts in the documentation.

Of those 7,850 tokens, 2,800 come from the three files in your setup. The project CLAUDE.md accounts for 1,800 by itself, which makes it the largest single item you control.

Those 2,800 tokens occupy the context window on every request, although prompt caching changes how much you pay for the repeated context.

Each request has three layers: the system prompt, your project context (CLAUDE.md, auto memory, and unscoped rules), then the conversation. The middle layer stays the same until you start a new session or run /clear or /compact. After the first turn, the repeated project context comes from cache at roughly 10 percent of the standard input rate.

Prompt caching lowers the price. The same 2,800 tokens still take up space in the window, leaving less room for the file Claude is working on during the rest of the session.

So I started sorting the instructions inside CLAUDE.md by when Claude needs them.

The 5 instruction layers, sorted by when Claude loads them

Take a rule about database migrations. You need it when you are changing the database, but Claude also loads it while you are editing a CSS file. The instruction is useful, but it is loading before the work needs it.

That leaves one question: when should Claude load each instruction?

The features overview compares CLAUDE.md, skills, MCP servers, subagents, and hooks by when they load. CLAUDE.md is the only one whose full content stays in every request. The others load some or all of their content later.

When I sorted them by when they load, I ended up with five groups. Most of the instructions in your own setup will also fit into one of them.

The always bucket is the one you already know. A rule file under .claude/rules/ lands here too if you forget the frontmatter, since the memory docs say a rule without paths: loads at launch at the same priority as .claude/CLAUDE.md.

Some instructions only matter in one part of your repo. Put them in .claude/rules/ and add the matching path:

---
paths:
  - "src/api/**/*.ts"
---

- Validate every API input.
- Use the standard error response.

This rule loads when Claude reads an API file. While you are editing CSS, it stays out of the context window.

Use a skill for instructions you only need sometimes, such as deployment steps or a review checklist. Claude loads the skill description at startup and the full instructions when the skill is used.

MCP follows the same pattern for tools. Claude sees tool names at startup, then loads the full schema when it needs a tool.

A subagent works in its own context window and sends back a summary. The files it reads do not fill your main window.

Most non-fork subagents also load the same CLAUDE.md hierarchy in their own window. A 400-line CLAUDE.md therefore loads again each time you spawn one. Explore and Plan are the documented exceptions.

The free bucket costs nothing at all. A hook runs outside the model, and it only spends context if it returns some.

Each skill, MCP server, subagent, or hook inside a plugin follows the matching row above.

A nested CLAUDE.md behaves differently depending on where you start Claude Code. Start above its directory and Claude waits to load it until it reads a file there. Start inside the directory and Claude loads it at launch. A paths: rule waits for a matching file either way.

This is also how Anthropic recommends reducing token use: keep workflow instructions out of CLAUDE.md when you only need them for certain tasks. Otherwise, those instructions remain in context even while you’re doing unrelated work.

Some rules still need to load in every session, so they have to stay in CLAUDE.md. The 200-line target gives you a practical limit for what remains.

The 200-line target, and why @ imports still take up context

Anthropic gives a practical target for a CLAUDE.md: keep the file under 200 lines. The memory documentation explains why: “Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.”

Line 201 does not trigger a cutoff. Claude Code will still load a larger file, up to 4 MiB. The 200-line target is about how reliably Claude follows the instructions as the file grows.

CLAUDE.md enters the request as a user message after the system prompt. Claude treats those instructions as context. No separate mechanism forces every rule to run. If two rules contradict each other, the documentation says Claude may choose one arbitrarily. A longer file gives Claude more instructions to weigh against one another.

This explains why repeating my rule made the problem worse. I added more words to a file Claude was already struggling to follow.

If a rule must run every time, move the rule into a PreToolUse hook. The hook runs before the matching tool action, so enforcement no longer depends on Claude remembering one sentence inside a long file.

Splitting a long CLAUDE.md into topic files only helps if those files stay out of the startup context. Pulling them back through @ imports organizes the files without reducing what Claude loads.

The memory documentation states this directly: “Splitting into @path imports helps organization but doesn’t reduce context, since imported files load at launch.”

A plain path pointer works differently. The pointer tells Claude where the file lives without importing its contents at launch. Claude reads the file later when the task needs it.

For the instructions remaining in CLAUDE.md, the best-practices page gives you a useful test: “Keep it concise. For each line, ask: ‘Would removing this cause Claude to make mistakes?’ If not, cut it. Bloated CLAUDE.md files cause Claude to ignore your actual instructions!”

Once you remove those unnecessary lines, the next question is what Claude loads on its own.

What Claude Code uses instead of .claudeignore

A Claude Code user opened issue #56997 after a .claudeignore file failed to block an .env file:

I added a .claudeignore... It didn’t work... There is no warning. No error. No mention in the docs. The file just sits there doing nothing, while I think my secrets are safe.

The issue was closed as a duplicate. The current Claude Code permissions documentation directs you to permissions.deny for controlling which files its tools read.

Add the rules to .claude/settings.json when the team should share them. Use .claude/settings.local.json when they only apply to your machine.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(./node_modules/**)"
    ]
  }
}

The rules use gitignore pattern syntax. A single * stays within one path segment, while ** crosses directories. Read(.env) and Read(**/.env) both match .env files at any depth below the working directory. In current Claude Code versions, a Read deny also blocks Edit and Write on the same path.

These rules cover Claude’s built-in file tools and file commands Claude Code recognizes in Bash, including cat, head, tail, and sed. The permissions documentation warns that they do not catch arbitrary subprocesses reading files indirectly. For secrets, treat the deny rule as one access control instead of the entire security boundary.

Three settings sound related, but each does a different job:

• respectGitignore keeps gitignored files out of the @ file picker. It does not stop the Read tool or Bash.

• ignorePatterns is deprecated. permissions.deny replaced it.

• additionalDirectories gives Claude access to directories outside the working directory. It does not remove access.

If you need to skip a CLAUDE.md from another part of a large repo, use claudeMdExcludes. Its patterns are matched against absolute file paths. A managed policy CLAUDE.md cannot be excluded through individual settings.

Moving instructions reduces what Claude loads at startup. Deny rules limit which repo files Claude reads later while working. The next step is checking whether both changes reduced your context.

Measure your instruction load before and after the change

Before moving anything, run /context. It shows what is using the current context window. Under Memory files, note which instruction files loaded and how much space each one takes.

Run /context all for the expanded breakdown, including connected MCP tools. This helps you spot a server using context even when the current task does not need it. Claude Code documents both forms of the command.

/usage measures something different. It shows session cost, plan limits, and activity. /cost and /stats open the same information. Use /context to inspect the window and /usage to inspect account usage.

Then run /doctor. In current Claude Code versions, it reviews a checked-in CLAUDE.md, proposes removing information Claude can derive from the repo, and suggests moving some remaining guidance into skills or nested instruction files. It shows you the plan and asks for confirmation before changing anything.

If you want a record of which instruction files loaded and why, set up an InstructionsLoaded hook. It runs when a CLAUDE.md or path-scoped rule enters context, including files loaded later in the session. The hook is for logging. It cannot block or change what loads.

Write down your /context reading before making changes. Run the same command in the same repo afterward. That gives you a useful before-and-after comparison without borrowing someone else’s percentage.

By this point, you know what Claude loads and where each type of instruction belongs. You have enough to rebuild the setup yourself.

The slow part is reviewing every line, resolving contradictions, and deciding which rules need enforcement. Claude does not warn you when one lands in the wrong place.

For paid members, I put together two gifts to handle that part:

• 🎁 The Claude Code Project Setup Kit includes a finished example project and blank files for your own setup: CLAUDE.md, path-scoped rules, skills, .claude/settings.json, and a working hook.

• 🎁 The CLAUDE.md audit prompt reviews every instruction, flags contradictions and vague rules, and recommends what should stay, move, or be removed before writing any files.

Upgrade to Premium

Read more

I wrote about using AI for SEO last year. Since then, my interest has only grown. I have been following how search affects both my Substack and my products.

There are plenty of tools that track visits and show how your pages are performing. But there is much more inside the raw data from Google Search Console.

Over the year, I have been giving that data to AI and using it to guide what I do next. It helped me see changes I had missed, understand how my pages affect each other, and find opportunities across both my articles and products.

So in this article, I am going to show you two best things I’ve learnt.

First, what changed when I started using AI for SEO and what new doors it opened for me.

Second, the complete setup you can use yourself: how to connect your data, what to give AI, how to prompt it, and which automations can run the monitoring for you.

By the end, you will have a system that keeps watching your pages and helps you decide what to do next, without manually going back and forth between reports.

Hi, I’m Jenny 👋
I believe anyone can thrive with AI, not by mastering the tools, but by building real things with them. I run Build to Launch and the Practical AI Builder program, where we go from experimenting to shipping. Come build with us.

If you’re new to Build to Launch, welcome! Here’s what you might enjoy:

• Everything in Claude

• SEO for AI: How to Make Your Product Discoverable by LLMs

What Changed When I Started Using AI for SEO

Once Claude could read my Search Console and Analytics data, I could ask it questions instead of opening another dashboard.

I started with the most practical one:

Which pages need my attention?

Claude separated the pages into three groups: act now, watch, and leave alone. One article was still ranking on page one and receiving thousands of impressions, but its click rate was far below the expected range. Another looked like a larger opportunity over 28 days, but its recent traffic had already collapsed. Acting on the older number would have meant fixing a page after the audience had moved on.

Then I asked:

Are any of my pages competing with each other?

The answer was yes. Across 11,473 search queries, 347 returned two or more of my own pages. Those searches had a 1.73% click rate, compared with 2.48% when only one of my pages appeared.

The clearest example was claude cowork. Three of my articles appeared for the same search, collecting 4,931 impressions and zero clicks between them.

The next questions became broader from there.

How does my Substack relate to my products?

Claude compared referral traffic across the publication and my product sites. It showed me which articles were sending readers onward, which products were being found through search or AI assistants, and where the connection between my writing and products barely existed.

Are outside sites competing with my strongest articles?

A dated search-results check found a competing site publishing the same types of Claude Code articles at a much faster pace. That gave me context for a ranking change that my own performance data could show, but could not explain by itself.

Finally, I connected the search data to my ideas list and asked:

Based on what is in my ideas list and the signals in my search data, what are the top three things I should write next?

Claude crossed 27 shortlisted ideas with real demand. It recommended a step-by-step Stripe integration article first because related searches had produced 11,963 impressions across 191 queries, while my existing page had converted almost none of that demand.

It also told me what to leave out. One topic was already working. Another needed consolidation rather than another article. Several ideas sounded promising to me but had little supporting demand.

No single existing product could answer all five questions so adaptively.

Then I put the questions on a schedule

Once these questions worked, I wanted the same analysis every week.

I had already built a shared AI second brain and given it scheduled tasks. That system could watch sources, collect information, and keep receipts of what ran.

SEO became the feedback layer.

Each week, the task collects fresh Search Console, Analytics, and Bing data. It checks whether the connections are healthy, asks the same questions, and returns one dated report.

The report ends with one of four actions:

1. Improve an existing page.

2. Create a missing page.

3. Change the product or message based on demand.

4. Leave it unchanged and keep measuring.

I can also connect it to Daily Intel. AI can compare the topics appearing in my research with the demand already visible in search and recommend what may be worth writing or building next.

This one turns observation into judgment. Not more numbers. A decision, with the reasoning shown and the evidence attached, arriving on a schedule.

Everything above is what the system found. The rest of this article hands it over.

Below, you get:

• the prompt set and the rules file as a download,

• the walkthrough for connecting your own publication to Google Search Console and Analytics.

• how to set up automated search data updates, so the data comes to you instead of you exporting it by hand.

• how to set up scheduled job that delivers one weekly report with suggestions.

• And how to widen it: add more properties, your product pages, and your social surfaces (tiktok, instagram, youtube, etc), including the one limit there that nobody else will tell you about.

Upgrade to Premium

First, download the SEO system package with the skills, prompts, scripts, weekly scheduler template, report examples and the setup guides for AI.

Read more

Before this, automation usually meant mapping the trigger, steps, branches, and exceptions in tools such as Zapier, Make, n8n, Marketo, cron, or code.

Now you can simply tell an AI, “Every morning, check this source and tell me what changed.”

That makes recurring work easier to start and more adaptive. It also makes the result less predictable.

The screens may all say “scheduled,” but they do not own the same parts of the job.

One task runs in a provider’s cloud. Another runs through your computer desktop app. A third lives only inside your open chat session.

That is a lot of scheduling options. It can feel excessive. It also creates many ways to hand over recurring work we might not even need.

After my last article about bringing recurring jobs into a shared AI second brain, made this thoughtful comment:

All looks amazing and powerful, but I can’t stop asking myself if all that produced information actually makes your work easier.

His question gets to the decision behind this map.

I gave him a whole thesis in reply, and we will return to it toward the end.

But first, I want to make the options easier to judge. We will compare AI-native scheduled tasks with workflow engines, agent gateways, and older schedulers such as cron and launchd.

By the end, you should be able to match one recurring job to the simplest option that can run it reliably and prove the result. That choice also avoids paying for more token cost or infrastructure than the job needs.

What’s inside:

• What Makes an AI Scheduled Task Run?

• The Four Ways AI Scheduling Is Packaged

• How Today’s AI Scheduling Options Compare

• What Is n8n, and How Is It Different From an AI Scheduled Task?

• What Can Go Wrong After You Add a Schedule?

• Which AI Scheduling Option Fits Your Job?

What Makes an AI Scheduled Task Run?

A scheduled AI task can sound simple: run this every morning.

That sentence contains five different responsibilities:

→ trigger
→ scheduler
→ executor
→ reliability controls
→ observation and recovery

Take a morning research brief.

The trigger is what makes the job eligible to start. Eight o’clock is a time trigger. A new email, a changed file, an incoming form, an API call, or a click on Run now can also be a trigger.

The scheduler is the running service that notices the trigger and starts the job. ChatGPT can own that service in its cloud. Claude Desktop can own it on your Mac.

The trigger is the condition. The scheduler is the service watching for that condition.

n8n (workflow automation) can watch a trigger and start the workflow. launchd (built into macOS) can start a local command on schedule.

The executor performs the instructions. It might be Claude, ChatGPT, Perplexity, a workflow, an agent, a Python script, or a command.

The reliability controls decide what happens when the prior run is still active, a connector expires, the network fails, the task finds the same item twice, or the output is incomplete. For a morning brief, the job can remember the last source it processed.

The scheduler or runner can refuse to start a second copy while the first is active. A result check can hold back an incomplete brief.

Observation and recovery tell you what happened. A useful record shows when the run started, which input it used, what it produced, whether the result passed, how to stop future runs, and what to do after a failure.

One morning brief might map like this:

The same five parts can look completely different on screen. Claude and ChatGPT group the instructions, cadence, status, and Run now controls inside a task page.

Claude also shows recent history there. A workflow engine such as n8n separates the trigger from the steps that follow.

The screens look different because each product groups the same five responsibilities differently. That gives us four practical families.

Share

The Four Ways AI Scheduling Is Packaged

AI-native scheduled work

AI-native scheduling is the easiest place to begin when the goal stays stable but the material changes, such as watching a source, preparing a brief, or reviewing a new report.

You can describe the job in plain words. The tradeoff is more adaptability and less predictability, so define what a useful result looks like before scheduling it.

Workflow engines

A workflow engine fits work whose handoffs matter. The graph can retrieve data, filter it, branch, call an AI, wait for approval, update a database, and send the result.

n8n, Make, and Zapier keep those steps and branches visible. The path is easier to inspect, but every connection and exception adds something you must maintain.

Agent gateways

An agent gateway fits several recurring jobs that need the same agent, Skills, tools, delivery channel, and run history.

Hermes and OpenClaw fit this shape. The gateway keeps that shared environment available, but it must stay healthy for every scheduled job that depends on it.

Operating-system schedulers

Operating-system schedulers make one more setup possible: the AI app does not have to own the schedule. On a Mac, launchd can start an AI command at the time you choose.

For example, this Unix cron entry calls Claude Code in non-interactive mode at 8:00 every morning:

0 8 * * * cd /path/to/project && claude -p "Summarize the new files in ./sources" > ./briefs/today.md

cron owns the clock. Claude does the work.

This fits jobs that need local files, or when you want the timing to stay outside the AI product. The tradeoff is that your Mac must be available, and you own the logs, overlap checks, result checks, and recovery.

You will see cron used in several places. Sometimes it means the Unix scheduler.

Sometimes it means only the timing expression another product reads. The expression may look the same, but the system reading it determines where the work runs, what context it receives, and what history remains.

Share

How Today’s AI Scheduling Options Compare

Claude alone now has Routines, Desktop scheduled tasks, /loop, Cowork schedules, and scheduled browser shortcuts. ChatGPT and Perplexity also expose several ways to schedule work.

I value these options differently. Some will probably change names, merge, or disappear as the products keep iterating and changing where scheduling belongs.

The easy part is creating a schedule. The difficult part is deciding whether its output deserves attention. I compare each mode by where it runs, what it can reach, and what kind of job it fits.

Claude Code Routine

• Runs in: Anthropic’s cloud.

• Can reach: Selected repositories, environment variables, network access, connectors, and Skills stored in the repository.

• Best fit: Unattended repository work while your computer is off. I share seven useful Routine jobs and starter prompts.

Claude Desktop Scheduled Task

• Runs on: Your computer.

• Can reach: Local files, apps, tools, configuration, and connectors.

• Best fit: Recurring work that needs files or software on your Mac. I compare Desktop tasks with Routines, Cowork schedules, and /loop in my Claude scheduling guide.

Claude /loop

• Runs in: Your current Claude Code session.

• Can reach: The conversation, files, tools, and permissions already available in that session.

• Best fit: Temporary polling or repeated checks during active work. My /loop guide shows how I use a stop condition to keep the repetition bounded.

Cowork Scheduled Task

• Runs in: A new Cowork session for each run. The task may run remotely or locally, depending on what it needs.

• Can reach: Connected services and, for local tasks, approved files and apps on your computer.

• Best fit: Recurring Cowork work that you want to manage from one Scheduled page. My practical Cowork guide covers setup, connectors, scheduling, and real uses.

Claude in Chrome Scheduled Shortcut

• Runs in: Claude’s Chrome extension.

• Can reach: Browser tabs and websites covered by the extension’s permissions.

• Best fit: Repeating a browser workflow after you have run and checked it yourself. My Claude in Chrome guide covers browser workflows and their failure modes.

ChatGPT Scheduled Task

• Runs in: OpenAI’s cloud.

• Can reach: Its saved prompt and the apps available to the account or workspace. Ordinary Tasks do not use project-file attachments.

• Best fit: Reminders, recurring prompts, briefings, and monitoring for changes.

ChatGPT Scheduled Web Workflow

• Runs in: OpenAI’s cloud.

• Can reach: Uploaded context, tools, Skills, plugins, or the current chat’s context, depending on the mode.

• Best fit: Cloud project work and recurring research. My shared AI second-brain guide shows how I keep context usable across ChatGPT, Claude, and Hermes.

ChatGPT Scheduled Desktop Workflow

• Runs on: Your computer.

• Can reach: A local project directory or an isolated Git worktree.

• Best fit: Scheduled work against local project files. I share four jobs I ran from the ChatGPT desktop app.

Perplexity Computer Scheduled Task

• Runs in: Perplexity’s cloud.

• Can reach: A fresh agent, configured connectors, or the originating conversation when attended context is needed.

• Best fit: Cloud research, monitoring, and connector-based work. My Perplexity and Claude in Chrome build shows this research shape across 177 products.

Perplexity Scheduled Searches and Tasks

• Runs in: Perplexity’s cloud.

• Can reach: Perplexity’s older recurring-search and notification system.

• Best fit: Recurring searches that still live in the legacy Scheduled Tasks area.

Gemini Scheduled Actions

• Runs in: Google’s cloud.

• Can reach: Gemini chat and the connected apps enabled for the account.

• Best fit: Personal summaries, reminders, and recurring updates.

Microsoft 365 Copilot Scheduled Prompts

• Runs in: Microsoft’s service.

• Can reach: Copilot Chat, Teams, Outlook, and the Microsoft 365 context available to the user.

• Best fit: Recurring work that already lives inside Microsoft 365.

This table is a snapshot. Several current limits are worth knowing, though they should not drive the whole choice:

• Claude /loop: The machine and session must stay open. Missed runs do not catch up, and recurring loops expire after seven days.

• ChatGPT: Active-task limits depend on the plan.

• Perplexity Computer: Stop deletes the task rather than pausing it.

• Gemini and Microsoft Copilot: Both set their own active-task limits.

These product limits will keep changing. To understand what stays the same underneath them, it helps to look at how scheduled automation is assembled. n8n is a useful starting point because it keeps the trigger and every step after it visible.

Share

What Is n8n, and How Is It Different From an AI Scheduled Task?

n8n is a workflow automation platform. You build a workflow from connected steps. An n8n Schedule Trigger can start it.

Make and Zapier use the same basic model. Make calls the workflow a scenario. Zapier calls it a Zap. I use n8n as the example here.

This model came before AI-native scheduled tasks. n8n was founded in 2019. ChatGPT introduced Scheduled Tasks in January 2025.

That history matters because AI brought scheduling into a conversation. You can now describe a recurring job in plain words without drawing every step first.

Suppose you want to process new lead forms every weekday at 8 AM.

For each lead, the job should research the company, check its CRM history, ask AI to classify it, wait for your approval, update the CRM, and notify sales.

You can write the complete job inside one AI instruction. You can also split the same job into n8n workflow nodes.

In Claude, the job lives inside the Instructions field. Claude chooses the smaller steps during the run. You review those steps later in the transcript or Receipt.

In n8n, the CRM lookup, AI classification, approval, and CRM update can each have their own node. You can inspect what entered a node, what came out, and where the workflow stopped.

n8n can still include an AI Agent or a Code node. AI handles the judgment. n8n shows the steps around it.

Anthropic describes the same difference: a workflow follows a path set in advance, while an agent chooses more of its own process.

That gives me a practical way to choose.

If I can describe the job as one instruction and judge one final result, I can begin with an AI scheduled task.

If I need to inspect the handoffs, pause for approval, control which app receives data, or restart part of the process, I use a workflow tool.

For this CRM job, I would use both. n8n would handle the schedule, lead retrieval, approval, and CRM update. AI would research and classify each lead.

The AI part can still change from run to run. It may use more searches, tools, or tokens when the input changes. My Claude Code token guide explains how that happens.

One routine in my Pipeline history shows the variation. Across 12 runs, Claude used 0 to 17 tool calls, took 2 seconds to 6 minutes, and wrote 0 to 3 files. One run stopped at the spend limit before using any tools.

That is why I set limits for spending, tool use, output count, and when the run should stop.

Next, we need to look at what can go wrong after the schedule starts.

Share

What Can Go Wrong After You Add a Schedule?

A scheduled job can fail in two ways.

1. The run may never start or finish.

2. It may also finish and produce the wrong result.

The major risks depend on where the work happens.

A cloud AI task can keep running while your laptop is closed. It can still lose connector access, hit a usage or credit limit, lose permission to a source, receive ambiguous instructions, or be paused by the product.

A local AI task can reach your files and apps. It can also miss work because the computer is off, the app is closed, the session ended, or the local environment changed.

An n8n workflow can show every node and execution. n8n can also start an error workflow when a step fails. It can still run at the wrong time because of a timezone setting, keep an unpublished change out of production, overlap with another run, or repeat an external action without a dedupe rule.

An OS scheduler can start the right command at the right time. It still cannot tell you whether the command produced the right answer.

That is why I keep two kinds of proof. Scheduler proof shows that the job started. Job proof shows that it produced an acceptable result.

One of my scheduled jobs created every file I expected, but two required checks failed. The schedule worked. The job did not.

One useful receipt records whether the job started and whether the result passed: when the job was due, whether it started, what it used, what it produced, which checks passed, and what should happen next. For AI work, I also keep tool calls, usage, accepted items, and the stop reason. When you turn the schedule off, the old run records should stay.

In my shared AI second brain for scheduled tasks, the job, each run, its output, and its receipt stay together.

Once you know what can fail and what proof you need, you can choose the scheduling option that fits the job.

Share

Which AI Scheduling Option Fits Your Job?

Start with one recurring job.

For example, I want a weekly brief from five public sources. The sources are online, the job should run while my laptop is closed, and I want one private result.

I can check it by requiring source links and a short list of required sections. That points to a cloud AI schedule.

Use the same test for your job:

When more than one row fits, start with the option that needs fewer services, connections, and always-on machines. Then check plan limits, provider credits, and anything that must stay available.

Manual is a complete decision. Keep the job manual until you know what a useful result looks like, how to check it, and how to stop it.

Before turning any option on, write down who owns each part:

Trigger:
Scheduler:
Executor:
Reliability controls:
Observation and recovery:

This brings me back to the response to ’s question.

Pick one recurring job and fill in those five lines before you open another product. If you cannot name the proof or the off switch, keep it manual.

Share

What is one recurring job you want to schedule, and which option fits it now?

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

OpenAI rolled out ChatGPT Tasks in January 2025. Anthropic added Claude Cowork scheduled tasks in February 2026. By July, Perplexity Computer supported recurring cloud tasks too.

By August 2026, Claude Code documented cloud Routines, local Desktop tasks, and session-scoped /loop. ChatGPT offered Tasks and Scheduled project workflows. Perplexity kept both Scheduled Searches and Computer Scheduled Tasks.

I have enjoyed seeing what each one can do. Every example made me think of another recurring job I could hand over.

So I started using more of them.

One job lived in Claude scheduled tasks. Another ran through Codex.

Others depended on local scripts or agent systems. Their outputs landed in different folders and chats.

I could no longer answer three simple questions from one place:

1. What is supposed to be running?

2. What did one Run do?

3. What came back?

Moving one job raised another question: what else would I disturb?

I wanted the job definition, sources, instructions, history, and results to stay together, even when I changed the scheduler or the AI doing the work.

So I added an automations layer to the same shared AI second brain.

It keeps recurring Job definitions in periodic_jobs/. It keeps retrieved items and Receipts in OUTPUTS/. It gives every Run a history I can open later.

I could finally open one place and answer those three questions.

That became the map for this article.

What’s inside:

• What Scheduled Tasks Look Like in My Shared AI Second Brain

• Connect Scheduled Tasks to a Shared AI Second Brain

• Schedule One Automated Intake, then add several more.

• Run the Automation with Claude or Codex, or another AI agent of your choice

• Follow the Automation Runs from Source to Receipt

• Decide the Automation Cadence

What Scheduled Tasks Look Like in My Shared AI Second Brain

Before I automate a job inside the AI second brain, I needed one place to see the recurring work I already had.

So I built a local dashboard called Pipeline.

Fleet answers the first question: what is supposed to be running?

It puts active routines and older paused definitions in one view. It shows each Job’s latest Run, Run count, recent status, and how many files it wrote.

Green means a Run passed. Amber tells me to take a closer look. Red means a Run failed or stopped, including when an account hit its spend limit.

Second, what did one Run do?

I can open an automation, see its history, and start the same Job with Run now. Opening one Run shows its input, tool use, outputs, and result.

The color points me to the Run. The Receipt explains it.

Third, what came back?

My Content Intelligence intake gathers material from followed Substack feeds, official platform news, Hacker News, Reddit, GitHub, email, websites, and YouTube.

The view below moves from all Source platforms, to the cards from one Source, to the details for one item.

I can start with a source, browse what arrived, and open one card. The card keeps the original source, the automation that collected it, the run that created it, and its receipt.

The scheduler can change. The AI can change. The job and its history still have a home.

This intake is one starting point. Later articles will follow the work into Synchronize, Analyze, Produce, Maintain, and Act externally.

Now, let’s get back to work.

First, download the shared AI memory starter packet here:

Read more

But small businesses still make up a huge part of working life.

The SBA’s February 2026 summary counts 36.2 million of them, employing 62.3 million people, or 45.9% of private-sector workers. Together, they produce 43.5% of U.S. GDP.

They can be easy to overlook when most of your attention stays online.

Just a few weeks ago, a teenage friend of mine built a website for a local restaurant and charged $500 for it. One useful project was sitting right there in his own portfolio.

As I relocated from New England to California earlier this year. The move opened a much larger set of questions.

Which local services could I trust?
Which business owners could I connect with?
Which events and communities could help me understand the place around me?

Researchers describe some cafes, markets, salons, and other local businesses as “third places”: social infrastructure where people form informal connections outside home and work.

Whether you have lived somewhere for years or arrived last week, local businesses shape how you find trusted help, relationships, work, and places you want to return to.

So I began with one route I could test: finding businesses with visible online gaps. I scanned 40 Austin landscapers. Ten had no real website. One had 4.9 stars from 19 reviews.

This article will show how I turned that scan into a ranked local opportunity board. Then map how the same local data can lead to website projects, service ideas, connections, events, and other opportunities you can explore in your own city.

What Local Business Research Revealed About the Opportunities Nearby

“Build a website for a local business” sounds simple. But it leaves out the decision that stops most people:

Which business is worth investigating?

I chose one signal I could verify from public listings: a business with visible customer demand and no website of its own.

That business became one clear candidate to inspect before I spent time building anything. The board gave me a starting point. Inspection, outreach, and a conversation with the owner would determine whether it became paid work.

A manual search works when you need to inspect one business once. The finder becomes useful when you want to repeat the search across categories or cities and carry every result through the same route.

One scan can lead to website projects, AI services, ranked market research, useful local connections, events, and ideas tied to your own interests.

Share

Next, we’ll go through the runnable automation step-by-step, following:

• the downloadable starter pack that AI operates for you

• the exact master prompt for the complete run and the prompts for every implementation stage

• the pre-requisite setup, and the cost that matters to you

• the raw data shape, ranked board, website audit, and finished private landing-page concept

• and three service offers to test and the prompt for opportunity-mapping

Upgrade to Premium

What you need to run the scanner

First, download the scanner kit. It contains the board builder, sample data, both prompts, and a local website example.

Read more

That was the skill I kept seeing people talk about.

Matt Pocock opened the GitHub repository on February 3, 2026.

By Aug 5, it had 204k stars.

Skills.sh listed 49 skills and 13.3M total installs. grill-me sat at the top with 751.6K.

But what made this 5 lines of instruction go viral?

I had been using it for my own work and seen magic happened. So I started taking Matt’s skills apart.

I wanted to know what each sentence controlled: where human decisions ended, what got written down, and what allowed the next skill to begin.

The length got my attention. The professional judgment underneath kept me there.

AI can perform more of the work. Your domain expertise determines whether it performs the right work.

Matt’s skills show one way to encode that expertise.

What’s inside:

• What grill-me took back from AI

• Why grill-me is so useful in any field

• What happens after decisions are settled

• What deep modules explain about AI work

• What changed inside my own skills

• What Matt skills you can use for daily AI work

• The prompt and professional terms I kept

• Turn one repeated correction into a skill

What grill-me Took Back From AI

This is the complete body of the original skill, separated into its five instructions:

1. Interview me relentlessly about every aspect of this plan until we reach a shared understanding.

2. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

3. For each question, provide your recommended answer.

4. Ask the questions one at a time.

5. If a question can be answered by exploring the codebase, explore the codebase instead.

The order of actions make a big difference.

Most of us have experienced the opposite process:

You describe an idea
        ↓
AI fills in the missing decisions
        ↓
AI starts making things
        ↓
You correct the assumptions after the work exists

The five instructions change the order:

You describe an idea
        ↓
AI finds the decision tree
        ↓
AI asks one question and recommends an answer
        ↓
You decide
        ↓
AI follows the next dependency

The first instruction gives the interview its depth.

Relentlessly does more work than a paragraph asking the AI to be thoughtful. It pushes the agent to continue until both sides can state the same plan.

The second instruction gives the interview an order.

A decision tree means one answer can create, remove, or change the questions below it. If you have not decided who the course is for, asking about the checkout page is too early.

The third instruction makes the AI do legwork.

A question alone hands the thinking back to you. A recommended answer forces the agent to look at what it knows, take a position, and still leave the decision with you.

The fourth instruction protects the feedback loop.

When AI asks eight questions together, your first answer may make the other seven irrelevant. One question at a time allows each answer to change what comes next.

The fifth instruction separates facts from decisions.

If the answer exists in the codebase, the AI should find it. Your attention belongs on the choice that cannot be retrieved from a file.

That is what grill-me took back from AI:

The current grill-me is a one-line front door to a grilling session.

grilling keeps dependency order, recommendations, and one-question pacing. It also expands the search from the codebase to the wider environment.

Facts stay separate from human decisions. After every question, the skill waits. It does not act until the human confirms that both sides share the same understanding.

The wording grew more precise. The central control stayed intact.

The AI must understand your decisions before it acts on them.

Share

Why grill-me Is So Useful in Any Field

That control travels because every field has choices that determine what comes next:

• In writing, settle the reader, argument, and evidence before drafting.

• In teaching, settle the learner, outcome, and progression before producing lessons.

• In research, separate facts the agent should retrieve from conclusions only you can judge.

• In product work, resolve the user, scope, and tradeoffs before implementation.

grill-me reached 751.6K installs.

Matt’s five-skills guide gives the method a useful scale. One course-editor feature took 16 questions. He says more complex sessions can reach 30, 40, or 50.

“One question at a time” can sound slow when you first read it. It does move more work into the decision stage.

I was integrating a contextual linking strategy into my SEO skills. Starting with /grill-me dug out the thinking I had only vaguely considered and never properly weighed.

Those decisions have to be made somewhere. When they are skipped at the beginning, they return later as rewrites, abandoned branches, and arguments with work that already exists.

That is why the skill transfers. It moves judgment to the point where changing direction is still cheap.

Once those decisions are settled, they still need somewhere to go.

As I went through several of those questions, I started to see the pattern and wanted more, faster. So I switched to the companion /batch-grill-me skill.

Share

What Happens After the Decisions Are Settled

A conversation contains early guesses, corrected answers, rejected branches, facts the AI found, and decisions the human made. A later agent can read all of it and still choose the wrong sentence as the current truth.

This is where to-spec begins.

Its job is simple: “This skill takes the current conversation context and codebase understanding and produces a spec.”

to-spec synthesizes what has already been settled: the user’s problem, desired result, user stories, implementation and testing decisions, out-of-scope boundaries, and further notes.

to-spec leaves out details that will age quickly. Exact file paths and working code snippets usually change faster than the decisions they record.

A small prototype can stay when it preserves the decision more precisely than prose. This is the volatility boundary: durable decisions stay, while fast-changing implementation details stay out.

The agent still has one bounded question to settle. It explores the repository, identifies the highest useful test seams, and asks the human to confirm them.

That does not reopen the product decision. It confirms where the promised behavior will be visible later.

For example, imagine that the settled requirement is: a paid member can download a course worksheet after checkout.

The conversation may contain dozens of details. The specification preserves the durable ones:

• who the member is;

• what successful access means;

• which states must be handled;

• what remains outside the work;

• where a test can observe the result.

When the issue is published and labeled ready-for-agent, the next stage can begin without asking the human to reconstruct the whole conversation.

One good example I particularly love: as I settled my decisions on the video generation pipeline, /to-spec turned them into one durable spec. That single spec fanned out into the 13 tickets the work actually needed.

That handoff with spec is the point where conversational understanding becomes durable state.

Share

What Deep Modules Explain About AI Work

A large amount of AI work can involve vibe coding. That makes software faster to produce. It also makes structural decisions easier to multiply before you have named them.

One of Matt’s most useful coding skills gave me the professional term for a pattern I had been trying to describe: a deep module.

A deep module places a large amount of useful behavior behind a small, stable interface. A shallow module exposes a large interface while hiding very little.

Depth is a property of the interface: how much behavior the caller receives compared with how much implementation the caller must understand. It does not mean “put everything in one giant file.”

This matters when you work with AI because every public method, helper, adapter, and cross-file convention becomes another thing the agent has to hold in context.

A deep module gives the agent a clean seam. The caller knows what goes in, what comes out, and what failure looks like. The implementation can change behind that test surface without forcing every caller to change with it.

Matt’s tdd skill follows the same order:
First, agree on the public seam.
Second, derive the expected result from an independent source.
Third, test one complete behavior.
Watch it fail before making it pass.

A stronger vibe-coding request is:

Design this as a deep module with the smallest stable interface. Place the seam where the promised behavior can be tested from outside. Keep implementation choices local to the module.

The AI now has three design constraints: small interface, local complexity, observable behavior.

The deletion test makes the difference concrete. If removing the module forces many callers to recreate its behavior, the module had depth. If removing it means deleting a few pass-through calls, it was probably shallow.

Professional vocabulary names the design, but module shape affects AI too. A deep module gives the agent fewer public concepts to trace and a clearer place to change and test.

It cannot guarantee the right code will be found. It reduces the cross-file reasoning once the agent reaches it.

Share

What Changed Inside My Own Skills

After I applied these skills, the change I appreciate most is simple. I can pick up a half-done job from anywhere, see the state of the work at a glance, finish with far less iteration, and end up with a much cleaner setup.

I applied the same principles to my article system.

Now I can open a new AI chat session from anywhere and pick up right where the work stands, because the state travels with the work instead of living in one chat.

My video lifecycle got a lot shorter too.

On a laptop without the improved skills, six versions got rejected and none of them satisfied me. With the skills, one round is already good enough for what I need right now.

The comparison was observational across different machines and projects. But it showed me what changed when my accumulated decisions traveled with the work.

My preferences are now captured inside the workflows and the first pass can already reflect how I think.

This is where AI can perform more of the work. But your choices determines whether it performs the right one.

In the paid section, I pull apart the Matt skills that helped me make this improvements. They control the next move, bring in your judgment, make failure observable, and keep quality on the table.

• The skill teardowns: how to apply them to writing, teaching, learning, research, product building, and your own workflow building.

• The prompt I used: to settle decisions and produce the right durable first version.

• The terms you can borrow: directly from Matt’s skills and from what I collected while building my own system.

• The steps: turn one repeated correction into a skill.

Upgrade to Premium

Read more

That is insane.

Substack built its payments system on Stripe from day one. Circle connects community payments to Stripe. Calendly lets coaches and consultants charge for meetings through Stripe. Gumroad uses Stripe to process all credit-card payments and bank payouts. Stripe is already sitting under newsletters, communities, services, and digital products.

If you’re making money online, it’s hard to avoid Stripe.

For an AI builder, the machine layer is even more interesting. Stripe has a structured REST API, a command-line interface, and an MCP server that supported AI clients can connect to. Those surfaces make Stripe unusually well suited to work with software and AI agents.

That convenience is why I kept building on it. Over years, one Stripe account filled with subscriptions, software sales, digital products, memberships, one-on-one payments, and private services.

Charging worked. The transactions arrived where they were supposed to.

But when tax season came around, or when I wanted to check growth, the account became too busy to read. I could see payments, but I could not quickly answer which product each one belonged to, how each part of the business was doing, or what had changed.

I needed my own view. It had to show the overview first, separate the revenue into useful categories, let me move into the details, and surface the payments that needed attention.

So I built it.

What’s inside:

• What the dashboard shows, and what this build taught me

• How to safely set up Stripe with AI access

• The complete product map, plus the prompts that refine it

• Five workflows for managing revenue and improving the system

• Step-by-step agent instructions, templates, and checklists for building the dashboard

• How to adapt the system to your own business

Subscribe now

What the dashboard shows, and what this build taught me

What the dashboard shows

The finished private dashboard has four main views:

• Revenue by brand

• Revenue by product stream

• Monthly gross or net revenue

• Failed payments and a searchable ledger

The overview lets me move from a total into the category behind it. The ledger keeps the underlying payment visible, including its status and classification confidence.

Failed payments stay separate because they do not have settled revenue. The exact figures were redacted for privacy reasons.

The agent can inspect the code, propose the map, and run the checks. I approve the business labels, live account access, and every financial conclusion.

In the paid sections below, the post unfolds the complete system behind the dashboard:

• 4 ways to give an AI safe access to Stripe data, with my recommendations

• The complete product map and prompts to build the product end-to-end

• 5 workflows that help managing revenue and improving the system

• Step-by-step instructions for AI agents, templates and checklists for building the project

Upgrade to unlock everything

Read more

My list includes Claude, ChatGPT, Antigravity, Cursor, Hermes, OpenClaw, and Notion. I have phased many others out of my daily work.

Every new tool promised another useful capability.

It also arrived with another onboarding job.

Another preference file, instruction set, skill library, memory, and schedule to maintain.

So I resisted adding new AI tools to my system.

Trying a tool was easy. Teaching it how I work was the expensive part.

I recreated preferences and references. I rebuilt skills and copied schedules. Then I had to remember which version was current.

Each new tool required enough benefit to justify rebuilding that setup.

I was not alone in feeling the cost of separate AI brains.

To resolve that, I gradually built up one maintained AI second brain for my AI tools.

I wanted every new AI tool to begin with one instruction:

Onboard to my AI second brain.

Now I can add an AI tool without rebuilding my operating context inside it.

My approved skills, specifications, schedules, preferences, and procedures stay current in one place. The AI tool finds what it needs for the job.

What’s inside:

• Why AI context drifts across tools

• What a shared AI second brain looks like

• Download the Shared AI Memory Starter Packet

• Learn how the starter packet is organized

• Onboard a new AI tool with one prompt

• How to share skills across AI tools

• How to route AI tools to the same project state

• How to keep one periodic job accessible to any AI tool

• How to improve one skill from any AI tool

• Test your shared AI second brain in 10 minutes

• Know when the shared system needs an upgrade

• By the end: a shared AI memory setup that Claude, ChatGPT/Codex, and Hermes can read from one maintained source

Why AI Context Drifts Across Tools

The drift is built into the way the tools work.

Claude Code, Codex, and Hermes each have their own places for instructions and working context. Their skill systems overlap, but skill availability, permissions, memory, and scheduled work still follow tool-specific rules.

So the same working preference can become three separate instructions. A useful skill can exist in one tool and be invisible in another. Feedback can improve one copy while the other two stay stale.

I had already seen how much maintenance one skill library requires when Claude skills stop triggering or drift. Adding more AI tools multiplies every durable change.

Without a shared layer, I become the synchronization system.

What It Looks Like With a Shared AI Second Brain

You can use the same skill files across all AI tools without maintaining duplicate copies.

One AI skill appeared in all three tools

You can confirm the shared source from each tool’s own interface.

I wanted to create a set of carousels with my btl-canva-kit skill inside ChatGPT/Codex.

Claude found the same skill.

Hermes found it too.

The skill existed once. Each AI tool reached it through its own discovery path, so I could maintain one source without reconciling three copies.

Feedback moved with the skill

You can capture skill feedback in one AI tool and let the next one continue from the same note.

I used Codex to record feedback on three parts of the video workflow in my Obsidian second brain.

The notes covered the cold opening, thumbnail ownership, and the boundary between long-form and short-form video. Codex attached them to video-code-pipeline and video-script-write without changing either skill.

Later, Claude found the same feedback logs and used my skill-evolver procedure to fold in the approved changes.

Hermes then returned the revised cold-opening rule from video-code-pipeline: reuse recorded body takes and keep the cold open around 20 to 35 seconds.

The same feedback path moved from Codex to Claude to Hermes without creating another skill copy.

The same layer carries into project work

You can apply the same routing pattern to projects, workflows, tools, and connectors.

I use it to avoid rebuilding my setup when I onboard Claude, switch to Codex, or start using another agent.

For project work, the shared layer points each connected AI tool to the state, decisions, specifications, and working conventions in the project itself. The project stays where it already lives, so you do not have to reorganize it or maintain a second copy.

The remaining work is connecting your own AI tools without creating another set of copies.

In the paid section below, is the exact setup for building this shared memory layer.

You get the setup steps, folder templates, and prompts that guide your AI through installing and maintaining one system. Any AI with access to the shared source can work from it.

You will get the complete setup files, tool-specific pointers, prompts, privacy safeguards, update procedure, and 10-minute test inside this article.

Upgrade to Premium

Download the Shared AI Memory Starter Packet

Read more

ChatGPT helped me find my first way to make money online.

It talked me through the apps I was too unsure to build. It made the consistent hero images that still sit at the top of everything I publish.

But this year, I mostly lived inside Claude. The native file system did something no chatbox could. It let an AI read and write the actual files on my machine.

So I stayed. Real files beat clever answers when you are trying to ship.

That changed on July 9, as Codex folded into the ChatGPT desktop app.

I was already running Codex inside my own agent pipeline, with results I trusted. So the merge was not a surprise to me. It was a workflow I had been waiting to run.

Over two years of using both established their roles differently in my world:

• Claude is the strategist, logical, neutral, effective.

• ChatGPT is the creative one. The mentor that reframes the problem, the collaborator that expands the idea, the tool that generates the image.

Codex brought the part builders already trusted: a strict engine that follows instructions to the letter. The merge bolted that onto ChatGPT’s creative sense, the exact thing I kept reaching for in Claude and not finding.

So I finally stress-tested it. Four types of job I had fought with, or overpaid for, in Claude.

A video. A podcast. A workflow I could finally see, and a small one that quietly saves me money every week.

What’s inside:

• What the ChatGPT app and Codex are, and what just shipped

• Use ChatGPT app to produce a YouTube video

• Use ChatGPT app to re-purpose a video to podcast

• Use ChatGPT app to create stunning prototypes

• Finding any task inside ChatGPT app

• The interface details in ChatGPT give an unparalleled user experience

• Do you move or stay

Subscribe now

What the ChatGPT App and Codex Are, and What Just Shipped

Let’s start with what most of us are familiar with:

• Plain ChatGPT talks back.

• Codex does the work on a real computer.

A little bit more about Codex:

It reads the files and repositories on your machine, runs terminal commands, tests the code, and hands you the changes as edits you accept or reject.

It runs in a few places. A command-line tool, a code-editor extension, the cloud, and now the ChatGPT desktop app.

You give it a goal, and it can work for hours, breaking the task into steps. More than 5 million people use it every week, and over a million of them for work that is not coding at all.

Since July 9, the app opens with a picker at the top-left: you choose ChatGPT or Codex, each with its own history.

Under ChatGPT you toggle Chat, the normal conversation. You toggle Work, an agent for long knowledge jobs that pulls from your connected apps and files and builds finished documents, slides, and sheets. Codex is the separate view: the coding agent that touches your local files, repositories, and terminal.

If you came from the old Codex app you call it the Codex app, and if you came from ChatGPT you call it the ChatGPT app, but it is the same download.

Chat talks, Work does business work, Codex does software. All of it runs on every plan, including the free one.

The reason it is worth your attention right now is the pace. In about a month, this shipped:

• June 2. Sites lets you build and deploy a website, dashboard, or web app that OpenAI hosts for you.

• June 9. Import to Codex brings your existing setup straight over from Claude Code and Claude Cowork.

• June 18. Record and Replay turns a task you demonstrate once on your Mac into a reusable skill.

• June 25. Codex Remote reached general availability, so you can start or continue work on your Mac or PC from your phone.

• July 9. Codex moved inside the ChatGPT desktop app, with in-app code editing, GitHub pull-request review, multi-repo projects, and the current GPT-5.6 model.

• July 16. A Codex CLI release got better at catching dangerous terminal commands, like forced rm, before running them.

That is a lot of surface area for four weeks. What matters is not the changelog. It is which of your real jobs it can now finish, start to end.

I built four things with it in one week. Here they are.

Share

How I Made My First YouTube Video Without Touching an Editor

I had never made a long-form video. Never appeared on YouTube, never edited a clip, no idea what the roles or the beats even were.

So I spent a day just exploring. The app walked me through A-roll and B-roll, then fonts, tags, frames, and captions, until the vocabulary I had been missing made sense.

Then together we made a video-processing pipeline.

I recorded in small passages. While I filmed the next take, the app watched the drop folder and processed the last one, reaching into the files already on my desktop and stitching them into finished segments.

I never touched an editor. When I disliked a result, I went back to the same task, named the problem, and the fix went into the handoff notes and back into the skill.

The part I did not expect was the visuals. Codex designed the thumbnails and generated the images inside the app, so I never switched to a browser tab and never spent an extra API credit. Image generation is included in the subscription.

The result was my first video: 14 minutes, published with chapters, captions, and a thumbnail.

Later, turning the video into Shorts took the same path. The app cut the captions and decorations, and I approved the takes.

Not all of it was smooth. The rendering hit real bugs. At one point it produced an invalid video file, and once it nearly treated a half-written file as finished.

I caught both only because the app shows me every file it touches. That was the shape of the whole build: strong at the work, safe because I could see and check it.

So the takeaway is not that the app is flawless. It is that you do not need to already have the video skill. You need a system that will build the skill with you on the first real job, catch its own mess when you are watching, and keep the skill for the next one.

Share

Turning That Video Into a Podcast on Apple and Spotify

I wanted the video be accessible to people while they commuted or did the dishes, not only when they could sit and watch a screen.

So I gave ChatGPT one thing: an approved MP3 from the video project, and the outcome I wanted, which was a show on Apple Podcasts and Spotify.

It did the rest in one build. It researched what each directory requires, then set up the storage, a server that streams the audio, the RSS feed, the episode format, a one-command publisher, and the tests.

I did not stitch any of that together. I control one feed, and Apple Podcasts and Spotify both read from it.

This is the clearest instruction-following I have seen from an agent. I gave it a real project, a named input, a defined output, and a way to check its own work. It returned deployed infrastructure, not a suggestion.

The full build is documented in this article:

Build to Launch

How I Built a Podcast Self-Publishing System in 13 Minutes

Last Saturday, I spent an entire day creating my first long-form YouTube video from my Hermes guide and finally published it…

Read more

a month ago · 21 likes · Jenny Ouyang

The honest limit is that it did not invent the audio. I handed it the MP3, and it did everything after.

An idea became a live show. Next I wanted to visualize a workflow I had never got around to build.

Upgrade to Premium

3 Clickable Prototypes for a Workflow I Could Never See

My Substack Notes engine runs on files, skills, schedules, and sources. It works, but it is invisible. When a Note does not go out, the cause could be a weak source, a failed intake, an expired login, a scheduling clash, or a broken worker, and I cannot see any of it.

I had been building this way for months. Workflow after workflow, automation after automation, but no visualization I’d actually look at. So I asked ChatGPT to show me the process before wiring anything to the backend.

It built three working prototypes side by side, all running the same real Notes data.

• First, a Daily Desk, an attention-first queue.

• Second, a Source Flow board that traces where each Note came from.

• Third, a Calendar Studio for scheduling the week.

These were not pictures. I could type into them, move cards, review a Note, and drag an approved one onto a day.

So I picked. I took the operating behavior from one and the warm editorial look from another, and the app merged them into the single design I signed off on.

Then it began making that design real, connecting the interface to the live engine, its 27 Notes and 79 sources, behind a read-only path first so nothing could break by accident.

There was a bonus I did not plan. Because Codex follows instructions so strictly, I can call it from inside Claude Code and use Codex for the rule-following and Claude for the reasoning.

It works the other way too. I get both wings instead of choosing one.

It got me most of the way, fast, and the last stretch is still human work. That is exactly what I wanted from it: something to see and steer, not a magic finished product.

A workflow I could never see is now a surface I can click. Which points at the smallest win of all, the one that quietly saves me the most.

Share

How Codex Finds Any Task Again and Runs My Pipeline for Free

The most token-efficient way to run AI is to keep chats short. One task per conversation, then a new one. It saves tokens, and it leaves you with dozens of little tasks you can never find again.

I accidentally archived the task where I was planning this very article. So I opened a new one and described the conversation I had lost.

Codex found the exact archived task, restored it, opened it, and pinned it to the top of my sidebar. It even checked the wrong task first, took my correction, then landed on the right one.

Task history stopped being a list I scroll. It became something the agent operates for me, and it can locate the task a conversation lives in, plus the smaller tasks I spun off it, without opening or changing anything.

The other quiet win costs nothing extra. I run a pipeline in Hermes, my own agent runtime, where I drop in tasks and let workers keep going in the background.

I set a ChatGPT model as the driver, so the quality stays high. Because I reach it through my ChatGPT subscription, that background work does not bill me per call the way an API key would.

This is not flashy. It is the leverage you only feel after a week of real use.

Share

The Small Interface Details That Make Codex Nicer to Use

Those four builds explain why I picked up the app. The small interface details are why I stayed in it.

Inside a chat, Codex spins up parallel agents, the same way Claude does. The difference is that you watch them work. Each one shows up with its own job, and you can open any of them to read what it is actually doing.

When three agents grade a draft at the same time, I click into one and read its reasoning without losing my place. Elsewhere that work is a wall of text. Here it is a panel I open and close.

There is even a pet. Click your name, choose “Show pet,” and a small pixel character pops up carrying the live status of every task Codex is running.

It is cute, and it is genuinely useful. One glance tells me what finished and what is still running, without opening a single thread.

The best part is the detail I kept wishing Claude had. Open a file in the sidebar, select one part of it, and a small menu offers “Add to chat.”

That selection drops straight into the thread, so Codex keeps working on the exact block I pointed at. No copying a file path. No pasting a snippet and then explaining where it came from.

The same move works inside the conversation, and this is the one that won me over. Highlight any part of a reply, add a short comment, and it attaches as an annotation.

Instead of retyping or copying what I struggled with, I highlight it. The composer carries a “2 annotations” chip, and Codex reads each one as the exact line I mean and what is wrong with it.

The piece I rely on most comes at the end of a task. When Codex finishes editing, it lists every file it touched, with the lines added and removed, and lets you open any of them, review the diff, or undo.

You see which files it changed, and even which files it only read, so the thinking is visible instead of hidden. I am not guessing what the model did. I open the files and check.

That is the whole point. When you are the human in the loop, the one making the judgment calls, this is the interface the job needs. For day-to-day work, that is where it pulls ahead of Claude for me.

Those are the small wins that add up. Which leaves the real question.

Share

Should You Move to ChatGPT and Codex Now, or Stay on Claude?

First, the honest cost of moving. Everything carries over, and that is expensive.

When I imported my workspace, it also dragged in a fleet of old MCP servers I no longer needed, the same process pile-up that once had my computer overheating. I wrote the full fix in a separate guide; the short version is to route repeated servers through one shared porter so the app is not launching ten copies of the same thing. Audit your MCP setup before you import, not after.

On usage, size the job to the plan. Bounded projects ran cheaply for me early in the week. But later, I had three long-running tasks, with large histories, high reasoning, and many agents, used most of my weekly allowance in a single day.

The lesson is to match the model and reasoning level to the task, not to read one early number as the price.

So, move or stay?

If you are deep in Claude and have never touched Codex, I am not going to push you. Claude is a strong strategist, and it will keep doing that job well.

But if you want what Codex is good at, or the cost of your current setup is starting to sting, it is worth trying yourself. Start at twenty dollars a month. That is enough to actually drive Codex and feel the agentic side, without overpaying to find out.

For the work I do, the honest verdict is that the new app is no longer behind Claude Code. It follows tasks, calls tools, runs skills, coordinates agents, and holds project history, and its visual output is stronger than what I expect from Claude Code. A clean head-to-head still needs matched tasks run side by side, so I am not turning one week into a scoreboard.

So did I move for good? Honestly, no. I kept both.

The same skills, MCPs, and scheduled tasks run across Claude and ChatGPT. Underneath them I keep one working second brain, a single source of truth that any AI provider plugs into instead of starting over.

You do not have to pick the tool when you own the system underneath it. If you want to see how that shared second brain works, tell me in the comments and I will write it up.

Leave a comment

Before you decide, run this quick check:

1. Do you have a file-backed workspace, with real files, skills, and instructions on your machine? If yes, the move is low-friction.

2. Are you paying per-call API costs for background or agent work? If yes, a subscription may cost you less.

3. Does your work need strong visuals, like images, thumbnails, or interfaces? That is where this app is strongest.

4. Before importing, audit your MCP servers so you do not carry process debt across.

5. Start on the twenty-dollar plan and match the model and reasoning level to each job.

If this helped, share it with the one person you know who is still deciding.

Share

If someone shared this with you, thank them and subscribe so the future build walkthroughs land in your inbox.

Subscribe now

What is the one job you would build with ChatGPT first?

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

That was fun.

But with a brand-new channel and only single-digit subscribers, I couldn't expect much engagement. So I started wondering: how could I extend its reach?

For many people, video isn’t the preferred format. They don’t sit down to watch, they listen.

YouGov found that 49% of American podcast listeners listen while doing household chores, 42% while commuting, and 29% while working out. During those hours, a video they can't listen to may as well not exist.

The obvious solution would have been to open a Transistor Starter account for $19/month and let it host the audio feed.

There was another option much closer to home: Substack now supports podcasts. But Substack is where my readers read.

Publishing the same idea twice, once as the article and once as an episode, clutters the inbox relationship the newsletter runs on. What I wanted was a listen button on
the work I already publish, not a second publication.

So the night the video went live, I sat down with my coding agent.

The audio was already finished. Earlier that day, Claude and Codex had cut a podcast version directly from the video.

Now it just needed somewhere to live.

I wrote a single prompt to store the audio and generate feed for Apple and Spotify.

Then I watched it work.

The machine did its part in 13 minutes. From building to testing to publishing.

The human work took about an hour. Not engineering, but all sorts of paperwork, and me understanding concepts.

By the end, the podcast was live on both platforms:

Transistor’s Starter plan costs $19 a month, or $190 when paid annually. My agents built a solution with $0 billable usage.

The next step is converting my older free posts into podcast episodes. Many of them work well in audio form, and now every approved episode is just one command away from being published.

Below in the paid content is the complete packet reconstructed from the build, with each stage separated by the points where you make a decision, approve something, or verify an account.

The master prompt is the exact one I used. The seven checkpoint prompts turn the real build process into a reusable handoff.

Give the technical sections to your coding agent. Keep the human steps for yourself.

By the end, you’ll own your RSS feed and have everything you need to publish on Apple Podcasts and Spotify.

Upgrade to Premium

Read more

MCP servers are the plug-ins that give AI apps their tools: email, web search, scraping, payments. Most AI app on your machine (Claude Desktop, Claude Code, Cursor, ChatGPT) starts its own private copy of every one you configured, once per session, and most of them never clean up.

You installed 15 servers. Your machine is running hundreds.

I lived in that state for eleven weeks. This is the whole story of fixing it, told in the order it happened. By the end you can run the same diagnosis on your own machine, and know exactly what has been running your fan.

What’s inside:

• Why Your Desktop Runs Hot With AI Apps

• How to Check the Root Cause of an Overheating Desktop

• Why the Same MCP Server Multiplies

• How to Fix the Problem for Good

• The MCP Health Kit

By the end you can run the census, move every server behind one shared daemon, and prove the count stays flat the next day.
The MCP Health Kit (the diagnostic, the runbook, the working files): paid members claim it at the end.

Subscribe now

Why Your Desktop Runs Hot With AI Apps

For eleven weeks my Mac kept running out of memory. I ran a health check 37 times, and it came back CRITICAL in 29 of them.

Free RAM sat under 200 MB for weeks at a stretch, the compressor held 6 to 10 GB, and the fan ran constantly while I did nothing heavier than write markdown.

You know the surface symptoms. The fan spins up while you type. Apps beachball on switch.

Activity Monitor says 23 of 24 GB used, and when you scroll the process list you find dozens of identical node processes you never launched and cannot name.

Every standard fix helps for a while, then stops. Restart the app: good for a day. Remove unused servers: good for a week.

Close Chrome tabs: good until lunch.

I tried each of those more than once across those eleven weeks, and the reports kept coming back CRITICAL, because the advice treats the symptom while the process count climbs right back.

The cause has a number attached. Mine was 797.

How to Check the Root Cause of an Overheating Desktop

Before any theory, get your own number, because the number is what makes the rest of this real.

Run this before you read further:

pgrep -f mcp | wc -l

That counts every process on your Mac with MCP in its command line. Then see who they are:

ps -eo command | grep -oE "npm exec [a-z0-9@/._-]+" | sort | uniq -c | sort -rn

The morning I finally counted, it said 797.

One gmail server, 123 running copies. Together they held roughly 13 GB of RAM, which on a 24 GB machine explains the 59 MB of free memory the health check found that morning.

Nothing was broken. Every process was healthy, idle, and waiting for a session that had already closed.

Your number will be smaller if you run one app with three servers. It will not be 15 if you have 15 installed. Hold onto that gap between 15 and 797, because closing it is the whole story.

Share

Why the Same MCP Server Multiplies

A number that strange demands an explanation, and mine had three separate layers, each of which made sense to somebody.

First, the protocol layer. MCP’s default transport is stdio: the spec says the client launches the server as a subprocess and talks to it through stdin and stdout. Those pipes belong to one parent.

A stdio server cannot be shared, by construction, so every new session spawns a fresh copy of every configured server. Ten servers, four sessions: 40 processes, working exactly as designed.

Second, the cleanup layer, and this is where it goes wrong. The MCP lifecycle spec says the client SHOULD shut the server down when the session ends. SHOULD, not MUST.

When an app skips that step, the orphaned copies keep running with no client connected to them. This is a known open issue in Claude Code, and the same bug lives in Copilot CLI. The leak shows up across tools because the spec only recommends the cleanup, it does not require it.

Third, the layer nobody expects: your AI apps read each other’s configs. ChatGPT’s Codex engine imports Claude’s MCP configuration and spawns the same fleet on its own.

I watched it happen. Three minutes after I cleaned the fleet out of my Claude config, ChatGPT spawned a fresh copy of all ten servers from a snapshot it had taken at launch. Configure a server once, and three apps each run their own copies of it.

A normal working week: 14 sessions across 6 projects, three still running, the oldest open for two days. In the per-session world, every row in that sidebar owned a full copy of every server. (UI reconstruction from the app’s design system.)

Now the math behind the 797. I had five gmail accounts configured as separate servers.

Multiply by the sessions I opened across a working day, then by the apps importing the same config, and 123 gmail processes stops being mysterious. It is arithmetic.

Why killing them never holds

The obvious move is to kill them all, so I did, and measuring what happened next is what taught me the real shape of the problem.

A SIGTERM sweep of the whole fleet freed 5.1 GB in seconds: free RAM went from 173 MB to 5.3 GB, and the machine was fast again.

Eighteen hours later the census read 474. The processes were back because the architecture that spawns them was untouched. Every new session rebuilt its private fleet, and closed sessions kept failing to reap.

Cleanup scripts have a second, quieter problem: they hunt for orphans, and there are none. The classic definition of a leaked process is one whose parent has died, leaving it reparented to the system.

Across all 37 reports, the orphan count was zero in 21 of them, report after report, while the machine kept running out of memory. All 797 processes had a living parent process. They were legitimate child processes, not orphans, and orphan-hunting logic cannot see them.

Sometimes the honest fix is deletion, not architecture. For me, a Cloudflare MCP server with 87 tools pinned a CPU core near 100% for five and a half hours, twice.

I replaced it with the wrangler CLI, which covers the same platform on demand with zero idle processes. If a heavy server duplicates a CLI you already have, remove it and keep the CLI.

For everything else, the fix is structural.

Share

How to Fix the Problem for Good

Everything above is the diagnosis. This is the repair: the architecture that ends the multiplication, the tool that packs it into one install, and the exact steps to move every server behind it and prove it held.

The fix is architecture: one server, many clients

Once you see the problem as multiplication rather than leakage, the fix follows directly, and the computing world solved this problem decades ago.

Unix solved shared-service access with daemons: one long-lived process, with many clients connecting through a single socket. Databases repeat the pattern with connection poolers like PgBouncer. MCP’s ecosystem is converging on the same pattern, and the pieces sort into three groups.

The first group is daemons and brokers, which keep one instance of each server alive for every client that asks.

The second is transport bridges, which translate a stdio server into the kind that can be shared over a local address.

The third is framework proxies, which bundle several servers behind one endpoint in code. What every one of them does, underneath, is replace many private copies with one shared instance.

The daemon shape works because MCP’s second transport allows it. Streamable HTTP servers run as one independent process handling many client connections, each carrying its own session.

So the design becomes simple to state: run every server once, expose each at a local address, and point every AI app at it. Clients that speak HTTP spawn nothing of their own. Clients that only speak stdio get a thin shim, a pipe adapter of a few dozen MB, instead of the full server.

Who built mcporter, and why it fits

Before you install anything, it helps to know who made the tool you are trusting with every server on your machine. The provenance here is unusually good, and it explains why the tool fits so well.

I built mine on mcporter, from OpenClaw creator Peter Steinberger. He built the agent and its MCP layer together, rather than bolting one onto the other, and it shows.

The daemon, the HTTP bridge, and the stdio shims all live in one installed tool that already knows how they fit. That is why one tool covers the whole job here, instead of three stitched together.

There is a second reason I trust the pattern, and it is the most convincing kind. Two of my agents never had this problem at all.

If you run Hermes, it uses mcporter as its MCP layer by default, so it started life with the shared architecture this whole fix builds toward. OpenClaw centralizes its own server definitions too, which keeps its duplication surface small, though its registry is its own rather than mcporter’s.

The point stands either way. Every client above broke in its own way precisely because each one keeps its own copy of the wiring. The two that keep none stayed clean the whole eleven weeks, while my Mac overheated.

Set up the mcporter daemon

Start with one server and prove it works before you touch a single existing config, because a shared daemon becomes a dependency for every client and you want to trust it first.

The commands below pin mcporter 0.12.3, the version I tested. Newer releases may change the config format, so check the docs before mixing a newer package with this exact block.

Install it, and confirm the version:

npm install -g mcporter@0.12.3
mcporter --version

Define one server in ~/.mcporter/mcporter.json, copying the command, args, and env straight from one of your existing client configs:

{
  "mcpServers": {
    "tavily": {
      "command": "npx",
      "args": ["-y", "tavily-mcp"],
      "env": { "TAVILY_API_KEY": "YOUR_KEY" },
      "lifecycle": { "mode": "keep-alive" }
    }
  }
}

That file holds credentials, so lock it down with chmod 600 ~/.mcporter/mcporter.json.

Start the daemon, then expose every server at one local address:

mcporter daemon start
mcporter serve --http 8848

Each server now answers at http://127.0.0.1:8848/mcp/<name>, and mcporter list tavily verifies it end to end by returning its real tool names. Run that check on every server as you add it. Mine caught a search server that had been silently broken in every config for months, because its package had renamed its binary and nothing had ever tested it.

Make it survive reboots with a LaunchAgent, so the bridge starts at login and restarts if it dies. Mine respawned in four seconds when I killed it as a test, and the plist ships in the kit.

One warning before you wire any clients in. I lost about an hour each to three separate traps.

One is a config key that gets silently ignored.
One is a behavior where the bridge does not see new servers until you restart it.
One is a fallback mode where a client spawns its own copy anyway if the daemon is not ready when it starts.

Each has a fix, and all three are written up in the kit’s runbook. The path above works; the traps cost time when you do not know they are coming.

Connect Claude, Cursor, and ChatGPT

Move one server at a time, verify it with a real call, and only then delete its old entry, so a working client never breaks mid-migration.

Each client speaks to the daemon differently. Claude Code and Cursor both accept a plain local URL, so they connect to the shared server and spawn nothing of their own. Claude Desktop only validates stdio entries in its config, so it gets a thin shim: a small adapter that forwards to the daemon instead of starting a full server.

ChatGPT is the one to get right, and it is where the migration broke for me. On my build, a plain URL in ~/.codex/config.toml produced an error that blocked the thread from resuming at all: url is not supported for stdio. The fix that worked was the same shim Claude Desktop uses, pointed at the daemon with the full path to mcporter:

[mcp_servers.tavily]
command = "/absolute/path/to/mcporter"
args = ["serve", "--servers", "tavily", "--stdio"]

Finally, comes the step that actually ends the sprawl: delete the old stdio entries from every config, keeping a backup first. As long as one config still defines a server the old way, sessions on that config rebuild it, and ChatGPT will faithfully import and copy whatever you leave behind.

Prove it held: the soak test

A fix that survives an afternoon proves nothing, since mine already regrew from 23 to 474 processes in eighteen hours once. The real test is the next morning.

Run the census test again a full day after you migrate. Three signs tell you it held: the count stays flat instead of climbing, mcporter daemon status shows your servers connected with recent activity, and no app shows its own npm exec servers after a relaunch.

One pattern is not a failure, and it is worth knowing so you do not misread it. ChatGPT threads you created before the migration carry their old config and respawn the old servers when you reopen them. Those die when the thread closes, so judge the soak by whether new sessions stay flat, not by what an old thread brings back.

Here is the gap I asked you to hold onto at the start, closed. The 797 processes are 15, and the 13 GB is under 1.

The health check that came back CRITICAL 29 times out of 37 came back clean, and stayed clean through a full day of the same work across all four apps. Same servers, same machine, same load. The only thing that changed is that each server now exists once.

Run the census tonight. If your number is close to your server count, you are fine. If it is ten times that, you now know exactly what has been running your fan.

Share

The MCP Health Kit

You can rebuild everything above by hand, from the census to the LaunchAgent. If you would rather drop it in, the MCP Health Kit is the apparatus as working files.

It has three pieces.

The system-health skill is the diagnostic that generated this article’s 37 reports. It drops into Claude Code, and you run it monthly to catch the next round of multiplication before it heats your Mac.

The migration runbook is the ordered walkthrough, with all five traps documented and fixed. Those are the silently-ignored config key, the snapshot that hides new servers, the shim that spawns a duplicate, the ChatGPT parser that rejects a URL, and the old threads that respawn their birth config.

The working files are the parts you would otherwise write from scratch: the mcporter config template, the LaunchAgent that keeps the daemon alive across reboots, and the copy-paste wiring block for each client.

Claim it with your paid-member account here.

Upgrade to Premium

Next Steps

What you can do today:

1. Run the census now: pgrep -f mcp | wc -l. If the number is far above how many servers you installed, you have the sprawl.

2. Stand up the shared daemon with one server, verify it with a real call, then move the rest over one at a time.

3. The next morning, run the census again. A count that stays flat is your proof the fix held.

If this made your hot, slow Mac make sense, pass it on to someone who runs several AI apps and cannot work out why their fan never stops.

Share

And if someone shared this with you, subscribe free so you catch the next guide.

Subscribe now

What did your census return the first time you ran it?

— Jenny

If you work in AI, odds are you have heard of Hermes Agent.

Not the Hermès handbag. But it is trying to earn the same kind of permanent place in your daily rotation.

You may already use ChatGPT, Claude Code, or OpenClaw. Each can give you that fantastic agent feeling: hand it real work, step away, and come back to progress.

So why add Hermes?
Is the setup another project?
What can it do that the agents you already use cannot?

To answer those questions, I gave Hermes the work that tripped me up most often. The tedious jobs that kept blocking whatever I wanted to do next.

By the end, Hermes had earned a permanent seat in my crew.

This article shows you the three runs that changed my mind, where Hermes failed, and the prompts you can copy into your own setup. Run the same tests, then decide whether Hermes belongs in your stack.

What’s inside:

• What Hermes Agent is, and how it compares to your current tools

• Hermes Agent runs on your existing subscriptions

• Hermes Agent keeps work moving across sessions

• Hermes Agent improves its skills through use

• Is Hermes Agent good? My honest verdict

• Run X research with 1 Hermes Agent prompt

• Keep a rolling job moving with 2 prompts

• Limit unattended Hermes Agent work with 1 setup prompt

• The 3 ways Hermes Agent will burn you, and the rules that stop it

• The Hermes Agent Prompt Kit: grab it at the end

Subscribe now

Build to launch is on Youtube now!

Watch the free portion here:

What Hermes Agent is, and how it compares to your current tools

Long chats slow down. Context gets expensive. So you clear the session and explain the work again as the tool forgets your instruction.

Hermes, built by Nous Research, takes the opposite bet by persisting chat sessions. That persistence runs on three mechanisms:

• Bounded memory.
  A USER.md capped at 1,375 characters and a MEMORY.md capped at 2,200. When the files are full, Hermes must consolidate and decide what to keep.

• Skills it writes itself.
  Every ~15 turns, a background process replays the session and asks whether a completed workflow is worth keeping. If permitted, it writes the procedure as a SKILL.md and loads it next time instead of re-reasoning from scratch.

• Recall you can query.
  Every conversation lands in a local searchable session database. Past work comes back by search, not by you re-explaining it.

On top of being a CLI tool, Hermes now also ships as a desktop app. On my Mac, I downloaded it, dragged it into Applications, and opened it. The terminal install is still there if you prefer one curl command.

That setup was much shorter than the one I used for my OpenClaw series.

My install opened with 27 built-in toolsets, 18 of them enabled: browser automation, code execution, macOS computer use, cron jobs, cross-platform messaging, and more.

The gateway was running. The model picker sat in the status bar. Sessions, skills, messaging, and artifacts each had their own pane.

In my stack, Claude Code, Codex, and Cursor center the active work session.

Hermes and OpenClaw add memory, schedules, messaging, and state that survives the chat.

OpenClaw is gateway-first. One long-lived process handles scheduled events and messaging. Its skills come from a marketplace.

Hermes adds an agent-managed learning loop. It writes skills from completed work, then loads them the next time the same job appears.

Hermes also lets me choose the provider. I ran it on my ChatGPT and Grok subscriptions instead of sending the work through metered APIs.

Share

Hermes Agent runs on your existing subscriptions

Direct X API calls were costing me about $1 a day for light scraping.

Hermes moved that work onto the Grok subscription I already paid for.

I connected Grok through xAI OAuth, then asked Hermes to research Marc Lou’s product portfolio. It used native Grok x_search, while my personal X API stayed on the unused-tools list.

The full pass spent zero X API credits.

Hermes mapped 20 to 30 products and isolated the five receiving real attention. It kept @zilvestro’s customer story beside the claim and marked a viral “government ban” post as satire.

It was faster than any X API workflow I had run. It also returned a research trail already separated into founder claims, user claims, and jokes.

That is the 1+1>2 effect: one subscription became both the search layer and the reasoning layer.

Share

Hermes Agent keeps work moving across sessions

Marc Lou is just one person I track. The rest sat across GitHub repos, product pages, posts, and experiments.

Most of them were parked in a browser tab I swore I would get to.

One Chrome profile held 20 tabs. Several profiles were open at once. The laptop ran hot enough that I could hear the fan.

Closing them felt like losing work I still wanted to read, test, or run. So the pile stayed open.

This time I handed the pile to Hermes. It collected 76 tabs across four Chrome windows.

I narrowed them to 47 tasks: read this article, scout that method, test the skill, tear down the repo.

Then I gave Hermes one rolling job to work with.

Across fresh runs, Hermes executed code, trialed a skill against a sample folder, and surveyed 159 repos. It reached 15 of 47 tasks before I called it.

Below is an example of how it tested an instagram skill I had parked in my trial list for too long:

And after that are the statuses of each of the 47 tasks.

Incomplete. Still moving.

Getting the cron to fire on its own took one fix. Before that, I was the heartbeat.

Once the pile became a ledger, I closed the 76 tabs and let the laptop cool.

The ledger helped me close the learning loop I had always wanted: queue the work, run it, decide what to do with the result, then move to the next task.

Share

Hermes Agent improves its skills through use

The learning loop had one more thing to prove. Could Hermes correct a bad procedure after the work exposed it?

The session exploring vidIQ MCP gave it the chance. VidIQ MCP is built for Youtube analytics, I wanted to use this to help me explore youtube in batches.

Hermes found the vidIQ MCP configured but disabled. It enabled the server, hit a 401, switched to OAuth, opened the browser flow, and verified 46 tools after authorization.

It checked. Failed. Fixed. Confirmed.

Then the skill told me to run /reload-mcp.

That command did not exist.

Hermes checked the official command reference and patched its own SKILL.md while I watched. The corrected instruction held for the rest of the session.

That is what makes agent skills useful here. The skill kept the working route, the dead end, and the correction that replaced it.

The same loop can overwrite a skill you set by hand. With learning enabled, Hermes writes new skills and edits existing ones in the background.

Turn on write approval. Then every proposed change waits for your sign-off, and the record shows exactly what Hermes tried to rewrite.

Share

Is Hermes Agent good? My honest verdict

Hermes is strongest when the work needs to outlive one chat. It can run through models you already pay for, resume a job from files, and correct a skill after the procedure fails.

I use it inside the wider AI agent system I run in production. I still supervise the result.

Three things will bite you. All are fixable.

• It can mark the wrong result done.

• An enabled cron job does not prove the gateway is running.

• Its chat history does not give you a clean job status.

I run it as supervised autonomy. The agent grinds, I keep the verdict and every release action.

Starting the run is easy. Making it reliable takes the real work. You need to know it used the right provider, resumed the right job, and produced something safe to trust.

The paid section gives you the step-by-step setup and exact prompts for four jobs:

• Run X research through Grok

• Keep a job moving across fresh sessions

• Bound unattended work

• Catch false completion

The Hermes Agent Prompt Kit packages the complete setup into one folder.

Upgrade to Premium

How to run X research with 1 Hermes Agent prompt

Read more

Claude runs my Substack growth now. For a long time, the thing slowing it down was me.

Not the strategy. Not the tools. Me.

I knew what to do to grow on Substack. I just could not keep up with doing it.

In the last six months, I moved houses twice. Twice.

Every writing cadence I had set, every posting schedule, every plan, I dropped most of them because I was living out of boxes.

On top of that: a full-time job and two little kids. There is not much spare time in that, and there is even less spare energy.

I kept coming back to the Pareto principle, the old 80/20 rule. Most of a job is the mechanical, repeatable, trackable part, call it 80%. The meaningful part, the judgment and the voice, is the 20% left over.

So I started asking simple question about Substack: what can I hand off, and what do I want to keep for myself? The answer turned into eight workflows.

Gradually, I took the parts of Substack growth I cannot realistically keep track of, and handed them to Claude. And only kept the parts I enjoy.

Of course, Claude did a much better job than I could (before March).

All Claude handled were just eight workflows that took over the 80% I used to grind through by hand. This session will break down all of them.

What’s inside:

• The 3 stages everyone on Substack moves through

• The one MCP that runs all eight workflows (it is already included in your subscription)

• The full live build, all eight workflows in Claude:

  • How to turn your entire subscription inbox into one scannable read

  • How to size a niche before you spend a month on it

  • How to tear down exactly how a top creator wins: their titles, their SEO, their cadence

  • How to turn one post into a week of notes in your own voice

  • How to schedule a week of notes and walk away

  • How to find the utility winner, the note that quietly did the work

  • How to rank your posts on real conversion and pull your next article ideas

  • How to read the subscribers you already have and see who actually converts

  • The complete loop, where measurement feeds the next week of writing

  • Live from the session: the workflow that broke on camera, how I debugged it, and what the room is using Substack for

• What to do this week, in order

• Session timeline with timestamps

🎁 The full recording, the deck, and all eight workflow prompts are in the Build to Launch community portal.

The Three Reasons You’re on Substack

I opened the session with one question in the chat: what are you using Substack for?

One, to learn and read. Two, to build your own publication. Three, to grow toward monetization.

Four people answered, and I got four different stages.

One was mostly here to learn. One was building his own publication. One named brand, one picked all three at once.

That spread is the point. Most of us do not live in one box. You start by reading, you drift into building your own voice, and eventually you want the work to pay you back.

The engine has three stages because the path has three stages, and it meets you at whichever one you are standing in.

This is the same arc I laid out in everything I have learned about growing on Substack. The difference now is that the manual clicking runs as workflows instead.

What I Hand to Claude

Across those three stages, I run eight workflows. Here is the whole set, in the order I reach for them.

1. Subscription Brief turns my entire subscription inbox into one short, themed read. Reach for it when you follow more than you can keep up with and want the two worth opening today.

   

2. Landscape Explorer sizes a niche before I commit a month of my life to it. It is for weighing a topic or a pivot: how crowded it is, whether anyone pays, before you write a word.

   

3. Creator Study tears down exactly how a top creator wins. Use it when someone in your lane is clearly working and you want their real playbook: their cadence, their titles, what they gate.

   

4. Notes Engine turns one long post into a batch of notes in my voice. This is daily visibility without daily writing: one article becomes a week of notes.

5. Scheduler queues those notes so I write once and walk away. It is for when you can write but cannot keep showing up.

6. Notes Performance tells me which notes worked, and which quietly did the work. Reach for it when likes are lying and you want the note that pulled clicks and subscribers.

7. Posts Performance ranks my articles on real conversion and hands me what to write next. Good for the blank page: your next ideas, each traced to a post that already converted.

8. Subscriber Study reads the readers I already have and shows who converts. Use it when you are chasing new subscribers and forgetting the list you already own.

You do not need all eight to start. You need the first one today, and the rest as each stage becomes practical for you.

The full live build

Here is what we built, step by step.

Read more

You have read that open-source AI is catching up.

DeepSeek beat this. Qwen beat that. Llama is free and everywhere.

That story is real. It is also hiding two things that change what you should do about it.

The first: almost none of it is open source. The second: the free models are not a gift. They are a weapon aimed at whoever charges you for AI, and in 2026 the weapon changed hands.

I went looking for an open model to run a high-volume job cheaply. I expected to spend the afternoon comparing benchmarks.

Instead I spent it figuring out which “open” models I was actually allowed to build on. Why the one topping the leaderboard is Chinese. Why the same model charged me four different prices depending on where I clicked run.

The landscape is not confusing because the technology is hard. It is misleading because three different things wear the same word. A license, a strategy, and a hosting bill all call themselves “open,” and nobody separates them for you.

So here is the map, in the order it actually matters.

What’s inside:

• The Open-Source LLM Field Guide: Five Buckets for Every Name: the map that sorts every lab, model, license, host, and metric, so no name is left homeless.

• Open-Source vs Open-Weight: Why Most “Open” LLMs Aren’t Actually Open Source: what “open” really means, and the license clause that can bill you.

• Who Ships Open Models Now, and Why the Leaderboard Went Chinese: the current map, and the surprise at the top of it.

• Why Would Anyone Give Away a Frontier Model? Open Weights Are a Weapon: the strategy behind free models, and what makes them survivable.

• How to Read an Open Model’s License Before You Ship: the pre-build check that keeps a “free” model from becoming a legal problem.

• How to Pick Where Your Open Model Runs: Groq, Together, Bedrock: same model, different physics, and how to choose.

• How to Decide Between an Open Model and Claude or GPT: when open saves real money, and when closed still wins.

• The Open-Model Decision Card, and Why Your Moat Is Never the Model: the one-page call sheet, and where durable value lives.

By the end: you can pick an open model, its license, and its host for a real project, and know when not to bother.

Subscribe now

The Open-Source LLM Field Guide: Five Buckets for Every Name

The map has five layers, and every name you are about to meet sits on one of them.

They stack in an order, so start at the top.

A lab trains the model: DeepSeek, Meta, Alibaba’s Qwen team, Mistral, Moonshot.

What they ship is a model, an actual file of trained weights, usually a family in a few sizes: DeepSeek V4, Llama 4, Qwen3, GLM-5.

Every model ships under a license, the fine print on what you are allowed to do with those weights. This is where “open” gets slippery enough to fill the next section.

Then comes the layer that decides your build. You never need to download a frontier model onto your laptop, so it runs on someone else’s GPUs behind an API, and that someone is a hosting lane. There are five of them, and picking one is discussed in depth below.

The last layer is the measuring sticks you judge lanes on. A token is a chunk of text, very roughly three-quarters of a word, and it is the unit everything is priced in. The rest are dollars per million tokens, tokens per second for raw speed, and time to first token for lag.

Five layers, one order: a lab trains a model, the model ships under a license, you run it through a host, and you judge the everything on a few numbers.

Open-Source vs Open-Weight: Why Most “Open” LLMs Aren’t Actually Open Source

Open source has a definition, and most “open” models fail it.

The Open Source Initiative sets the bar: release the weights, the training data information, and the code that built it. The license must let anyone use, study, modify, and redistribute it for any purpose.

Open weight clears a much lower bar. You get the finished weights, a license, and little else.

That gap is not academic. The OSI looked at Llama and ruled it out: “Meta is confusing ‘open source’ with ‘resources available to some users under some conditions.’”

Some conditions. Here is one.

Llama’s license has a ceiling at 700 million monthly active users. Cross it on the model’s release date, and you must request a license from Meta, granted “in its sole discretion.” A size exists at which your right to use the model switches off.

There is another place. Llama 4’s multimodal rights are not granted to companies based in the European Union, and every Llama 4 model is multimodal. A European company installing Llama 4 to train on images is outside the license before it writes a line of code.

The traps are not only Meta’s. MiniMax M3 sits near the top of the open leaderboard, yet its license grants use “for non-commercial purposes”. Commercial use above $20M a year needs “separate, prior written authorization.”

A model everyone calls open, and you cannot legally build a business on it without asking first.

For contrast, look at what fully open looks like. AllenAI’s OLMo 2 ships the weights, the training code, the checkpoints, the logs, and the actual dataset, under Apache 2.0.

You can rebuild it. Almost nobody else lets you.

That is the real cost of open weight. Without the data and the recipe, you cannot audit the model for what it was trained on, you cannot reproduce it, and you inherit whatever legal exposure is buried in data you never saw.

You are not owning open source. You are renting a black box under a EULA. Read the license before the benchmark.

Who Actually Ships Open Models Now, and Why the Leaderboard Went Chinese

The roster changed faster than my mental model.

Here is who ships a current open-weight flagship as of July 2026:

On Artificial Analysis’s open leaderboard, the top open models are GLM-5.2, MiniMax-M3, DeepSeek V4, and Kimi K2.6.

Surprisingly (or not), every one of them is Chinese. Meta, Google, and Mistral trail.

The companies that made “open” a marketing word are quietly walking away from it.

Meta shelved Llama 4 Behemoth, its biggest model, and in April 2026 shipped Muse Spark, its first closed, API-only frontier model. Alibaba kept its small Qwen tiers open and made its flagship, Qwen3.7-Max, proprietary.

Read those two moves together and a pattern falls out. Leading on open is now a challenger’s play, not an incumbent’s. The labs that already have distribution are hedging back toward closed, while the labs trying to take share give their best work away.

Which raises the obvious question.

Why Would Anyone Give Away a Frontier Model? Open Weights Are a Weapon

Nobody spends nine figures training a model and releases it out of generosity.

Mark Zuckerberg said the quiet part in his 2024 open-source letter. Meta open-sources so it is “not locking into a competitor’s closed ecosystem where they can restrict what we build.” He compared it to being “constrained by what Apple will let us build on their platforms.”

Strip the framing and the logic is simple. Push the price of one layer to zero so you can sell or protect the layer next to it.

Meta’s real business is apps and ads, not model API calls. A free frontier model does two jobs at once: it commoditizes the paid product that OpenAI and Anthropic sell, and it keeps Meta off anyone else’s platform toll.

Meta never needed to sell the model. It needed the rival’s version to stop being worth paying for.

Then the weapon changed hands.

Once Meta had ecosystem share, it started hedging back to closed. Meanwhile the Chinese labs picked the weapon up and aimed it at everyone. DeepSeek V4-Flash runs at $0.09 per million input tokens, and Chinese open weights now make up around 61% of the top-model token traffic on OpenRouter.

When your capability is a commodity, giving it away costs you little and costs the incumbent charging for it a lot.

That only works if serving the model is cheap. The design decision that makes it cheap is the mixture-of-experts architecture.

DeepSeek V3 has 671 billion parameters, but only 37 billion are active per token. A router picks a handful of expert sub-networks for each token, so the compute and the memory bandwidth you pay for scale with the active count, not the total. The model holds 671B worth of knowledge and serves at roughly 37B worth of cost.

That decoupling is the reason frontier-grade output costs pennies in 2026 and could not in 2023, when a dense model computed every parameter for every token.

One more number deserves a second look. You have seen the claim that DeepSeek trained V3 for $5.6 million.

That figure is the final training-run compute only, about 2.788 million GPU-hours at $2 each, and the paper says so plainly. It excludes the research, the failed runs, and the hardware.

SemiAnalysis put the real server bill closer to $1.6 billion, noting the headline number “does not include research and development, infrastructure, and other crucial costs.” Same lesson as the license. The number everyone repeats is not the number that is true.

That is the strategy and the economics. You can see the game now: open weight, not open source, and a price war nobody is calling a price war.

The rest of this guide is the part you can act on: which license won’t bite you, where to run the model, and whether to use an open one at all. It all comes together in the Decision Card at the end.

How to Read an Open Model’s License Before You Ship

The license, not the benchmark, is what can stop your product. Read it first, and read it for four things.

First, a user or revenue ceiling. Llama switches off above 700M monthly active users; Kimi K2’s Modified MIT adds attribution duties above 100M users or $20M a month. You will likely never hit these, but “likely never” is a business decision, not a default.

Second, a geographic carve-out. Llama 4 excludes EU companies from its multimodal rights. If your users or your servers are in the wrong place, the license is already broken.

Third, a commercial gate. MiniMax M3 is non-commercial unless you get written authorization. This is the one that surprises people, because the model is free to download and still not free to sell against.

Fourth, attribution and naming. Llama makes you display “Built with Llama” and prefix any model you train on its outputs with “Llama.” Minor, but it is a contract term, not a suggestion.

Sort every model into one of three tiers and the decision gets fast.

Apache 2.0 and MIT models ship freely: Mistral Large 3, Gemma 4, DeepSeek V4, GLM-5.2.

Open-weight-with-limits models need a ceiling check: Llama, and Qwen’s larger tiers.

Non-commercial models like MiniMax M3 you skip unless you plan to ask.

One trap: licenses change per version. Gemma 1 through 3 shipped under Google’s restrictive terms; Gemma 4 moved to Apache 2.0. Check the version you are shipping, not the family you remember.

How to Pick Where Your Open Model Runs: Groq, Together, Bedrock

The same open model is a different product depending on where you run it. Speed and price swing wildly with the host, and picking one is a real decision, not a detail.

Take gpt-oss-120b. In July 2026 on Artificial Analysis, identical weights run at 1,987 tokens per second (raw output speed) on Cerebras. They run at 480 on Groq.

DeepInfra serves it at about $0.05 per million tokens. Their summary: a 314% speed spread and a 2.6x price spread on one model.

Step back, because the word host hides the mechanics.

An open model is not something you download and wrestle onto your laptop. It sits on someone else’s GPUs, behind an API endpoint you call over the internet.

The question is whose GPUs, and that comes down to your workload:

• Just starting: a serverless API. Together, Fireworks, or DeepInfra keep the model running and bill per token, from roughly $0.09 to $1.74 per million. You grab a key and you are calling it in minutes.

• Latency is the product: speed silicon. Groq and Cerebras run open models on custom chips, several times faster for a small premium.

• Regulated: a cloud bundle. AWS Bedrock, Vertex, or Azure run the same models on the invoice you already pay, next to your data and behind the IAM you already set up.

• Past ~100 million tokens a month: self-host. Rent GPUs and serve with vLLM, or run a smaller model locally with Ollama; a fixed GPU bill finally beats per-token pricing.

• Don’t want to choose: an aggregator. OpenRouter fronts seventy-plus of these providers behind one API key, so you switch hosts by changing a string.

Prices swing by host and model: the same DeepSeek V3 runs from $0.38 to $0.89 per million tokens across hosts. Artificial Analysis has the exact figure for every model on every host, so check it before you commit.

Whichever you pick, using it looks almost like using Claude or GPT. You get an API key and point your code’s base_url at the host’s endpoint. Most are OpenAI-compatible, so the call you already write barely changes.

Now, why the spread? Same outputs, different physics underneath, and it comes from hardware, not quality.

Groq’s LPU keeps the model in on-chip SRAM, runs deterministically with no runtime scheduling, and drops the high-bandwidth memory that GPUs rely on. That buys latency and gives up capacity, so the model has to be sharded across many chips. Cerebras makes the same trade at wafer scale.

The GPU hosts, Together and Fireworks and DeepInfra, batch many requests on H100s and B200s. That maximizes throughput per dollar and raises the time to first token.

So fast and cheap are not two quality tiers. They are two design philosophies, and you pick by your workload: real-time voice needs the fast lane, bulk overnight processing wants the cheap one.

The cloud bundle looks overpriced until you see what it sells. AWS Bedrock runs open models at a premium to Groq, but it is not selling the model. It is selling unified billing, IAM, no data egress, compliance, and keeping inference next to data you already store on AWS.

For a regulated team, that bundle is the product and the model is the loss leader.

Notice the move, because you have seen it before. The provider’s margin on the model itself is racing toward zero, that $0.38 floor barely above the cost of serving it. They give the model away at cost to sell the thing beside it: raw speed, custom silicon, or the cloud bundle.

It is the same play the model labs ran, one floor up.

How to Decide Between an Open Model and Claude or GPT

Start with the honest part. At the frontier, closed still wins.

The best open models trail the best closed ones by a 3 to 6 point Intelligence Index gap, down from about 13 a year ago but not gone. The gap widens on the hardest reasoning and agentic tasks, and closed models hallucinate less. If your product lives or dies on the single hardest 5% of requests, pay for the closed model and move on.

Everywhere else, open has real, specific wins. There are four worth knowing.

The first is cost at scale.

The crossover sits around 100 million tokens a month; below it, a managed API is usually cheaper once you count ops. One team that moved two high-volume pipelines to self-hosted Qwen cut costs from $1.50 to $0.15 per million tokens, 90%, and still warned that below roughly 100k requests a day the managed API wins.

The second is privacy.

If you cannot send data to OpenAI at all, a self-hosted open model is the GDPR-clean path, and there is no closed equivalent.

The third is latency.

For real-time work, Cerebras serves Qwen at about 525 tokens per second against roughly 92 for a standard closed API.

The fourth is control.

You own the weights, so no vendor deprecates your model out from under you, and migrating is a change of base URL.

What working builders do is route by task. Send bulk, private, and high-volume work to an open model, send the hardest reasoning to a closed one, and keep a closed fallback wired behind a feature flag.

The question was never open or closed. It is which job, at what volume.

The Open-Model Decision Card, and Why Your Moat Is Never the Model

Everything above collapses into one page. Save it for your references:

THE OPEN-MODEL DECISION CARD  (as of July 2026)

1. LICENSE: check before the benchmark
   - Apache 2.0 / MIT: ship freely (Mistral Large 3, Gemma 4, DeepSeek V4, GLM-5.2)
   - Open-weight + limits: check the ceiling (Llama = 700M MAU + no EU multimodal;
     Qwen large tiers = 100M MAU)
   - Non-commercial: needs written OK (MiniMax M3). Skip unless you'll ask.
   - Grep the license for: user/revenue ceiling, geographic carve-out,
     commercial gate, attribution.

2. HOST: same model, different physics
   - Need speed (real-time, voice): Cerebras / Groq (specialized silicon)
   - Need cheap (bulk, batch): DeepInfra / Together / Fireworks (GPU batching)
   - Need the bundle (already on AWS/Azure, compliance, data-gravity):
     Bedrock / Vertex
   - Compare the same model across hosts on artificialanalysis.ai first.

3. OPEN vs CLOSED: which job, what volume
   - Under ~100M tokens/mo, no privacy need: closed API usually wins
   - Over ~100M tokens/mo, or on-prem/regulated, or need sub-0.3s latency: open
   - Hardest reasoning / agentic / multimodal: closed, still (3-6 pt gap)
   - Default: route by task, keep a closed fallback behind a flag.

Now the part that outlasts the card. The same logic that made the model free is already eating the layer that runs it.

Gartner expects inference on a trillion-parameter model to cost over 90% less by 2030. In 2023, a16z argued that infrastructure was capturing the value in AI. By 2026 that flipped: the durable moats are proprietary data, deep workflow integration, and distribution, and “model selection is closer to a commodity choice than a competitive advantage.”

Which tells you where to spend your effort.

So pick the cheapest model that clears your quality bar, run it on the host that fits the workload, wire a fallback, and stop treating the model like the asset. The model is the commodity. What you build around it is the company.

Next Steps

What you can do today:

1. Pull the license of the open model you are eyeing and check it for the four clauses: a user or revenue ceiling, a geographic carve-out, a commercial gate, and attribution.

2. Drop one model into artificialanalysis.ai and compare it across a fast host and a cheap host before you commit to either.

3. Write down the monthly token volume where you would move a task off Claude or GPT to an open model. That number is your switch point.

If this made the open-model landscape navigable, share it to someone who will also benefit from reading it.

Share

And if someone shared this with you, subscribe free so you don’t miss the next guide.

Subscribe now

Which open model are you reaching for first, and what are you running it on?

— Jenny

Why Upgrade · Practical AI Builder Program · Claude Hub · AI Agents

For a long time, I was my AI’s memory.

Not because it had none. It had plenty. ChatGPT remembers. Claude remembers. My agents on OpenClaw remember.

The problem is the kind of memory.

It’s linear. A running log. Each new thing pushes the old ones down, then out. It keeps what’s recent and drops the arc.

So it can’t answer the question I actually care about. Pull up one topic across my whole history. What I thought, what I researched, what others said, how it evolved, where every file lives.

A log was never going to hold that shape.

You could make the AI read back through everything, every time, to find what connects. I tried. It is slow, and the token bill is brutal. You can’t afford that on every lookup.

So what you need isn’t a better log. It’s a second brain.

A connected store of everything you know and have done. You land on one idea, and everything tied to it comes up with it. Across your whole history. Without re-reading it all.

That’s the thing I was missing.

I got there sideways. Every time I asked AI to read or write my work, it kept pulling me toward markdown. Plain text files.

And markdown is the first thing Obsidian is built on.

So the jump was small. Put my notes where the AI already reads best. Then connect them.

I went through every question I had about Obsidian until it clicked. Then I wired it to Claude.

That was the day I stopped being the memory.

This is the build, start to finish. The notes, the connection, the setup.

What’s inside:

• What makes Obsidian so good

• Why Obsidian and AI work together, and the tools that extend it

• What a connected Obsidian + Claude second brain looks like

• How to connect them: the bridge

• How to set up Claude to run it

• How to keep the vault organized so Claude finds the right note

• By the end: an Obsidian vault Claude Code reads, updates, and interlinks as your second brain

• The obsidian second brain kit: grab it at the end

🎁 The Obsidian Second Brain Kit: the pre-built vault, the context-file templates, the bridge setup sheet, the self-updating skills, and the cleanup checklist.

Subscribe now

What Makes Obsidian So Good?

Obsidian is a free notes app that stores every note as a plain .md file on your own computer.

No cloud account. No database you can’t open. If Obsidian disappeared tomorrow, your notes still open in any text editor.

It has three parts:

1. A folder, also called vault, is where all your notes are saved;

2. .md files, also called notes, is the format that stores your notes, one idea at a time;

3. A graph, shows the connection between all saved notes.

The connection and relation of files are made possible by two built-in features:

1. Links.
   Also known as wikilinks after the wiki-style brackets. Type a note’s name in double brackets in another note, [[Example Note Name]], and the two are connected.

   

2. Properties
   They are custom fields at the top of a note: status, source, project, date. Written as plain YAML, they let Claude read the note as data, not just prose, and you can sort and filter on them like a table.
   Tags are a special type of property, they are searchable and clickable in Obsidian.

   

The links + notes build a graph view, which turns your vault into a picture.

Every note is a dot. Every link is a thread.

A vault with no links is dust: notes floating, nothing touching. Add links and it clusters. You can see which ideas belong together and which are stranded.

The search within Obsidian is cheap and crazy fast.

A developer tested it on a 4,663-file vault. Finding the disconnected notes by brute-force grep took 15.6 seconds. Through Obsidian's index: 0.26, about 60 times faster. Have an AI do the same scan by reading every file and it burns roughly 7 million tokens. Through the index, about 100. Same answer, 70,000 times cheaper.

Why?

When your vault loads, Obsidian reads every note once and builds an in-memory index called the metadataCache: every link, tag, heading, and property in the vault.

After that, it works from the index. A link resolver maps every [[wikilink]], so backlinks and orphans surface instantly, with no full-vault scan.

Your notes are still plain .md files. The index sits on top. You get database speed without trapping your notes in a database.

You made the connection once. Next time you land on one idea and the connected ones come with it, because the connections were stored once and the index keeps them ready.

That is the Obsidian side.

Now you may say, sure, Obsidian seems powerful in note-taking and graph-drawing, but what makes it so special with AI?

Share

Why Do Obsidian and AI Work Together?

If you’ve been building with AI for a while, you already know the pattern: Markdown files are first-class citizens.

Obsidian treats Markdown files the same way.

Same foundation. That is why the pairing works.

Obsidian gives Claude four things at once: readable files, a steady stream of source material, writable memory, and paths to follow.

Put those together and you get the shape of a graph memory agent: your vault as long-term memory, Claude as the part that reasons over it.

Reason 1: Claude can read it

Obsidian’s rules happen to match what Claude reads and writes best:

• Markdown gives it clean text.

• Wikilinks give it paths between ideas.

• Properties and tags give it filters.

• One idea per note gives it the exact thing, not a 5,000-word file to wade through.

You do not have to teach Claude a new format. Obsidian already speaks it.

Reason 2: the vault keeps getting fed

Obsidian is built for capture.

Your own ideas, meeting notes, book quotes, articles, and videos can all land in the same vault.

The online half is the Web Clipper, Obsidian’s official browser extension. Click once on an article and the page lands in your vault as clean markdown. On YouTube, the same button saves the page in a stripped-down read mode. Highlight as you read, and each saved sentence keeps a link back to the exact spot.

Everything you read and watch becomes something Claude can reason over.

Reason 3: Claude writes back

Open a normal AI chat, solve a problem, close the tab.

Tomorrow the work is gone.

A vault breaks that. Claude is not read-only here. Every session can write what it worked out back into your notes.

What you figured out today is there tomorrow.

That creates the flywheel:

• The AI writes better notes.

• The better notes give it more context.

• The next answer is sharper, and that gets saved too.

Your knowledge compounds instead of evaporating. After a few weeks, the vault stops feeling like storage and starts feeling like it’s thinking with you.

Reason 4: Claude can navigate without drowning

Claude does not need to read the whole vault.

It reads a small map first: a short file that says what exists and where. Then it follows the links to dig only where it needs to.

Ask it, “Which of these people haven’t I followed up with?” It reads the list, follows each link to that person’s note, checks the last date, and answers.

The map gives it orientation. The vault gives it depth. The index keeps every link ready, so following one is near-instant, even across thousands of notes.

The ecosystem extends it

Plugins extend the vault in two directions: how you see it, and how you talk to it.

• Copilot lets you chat with your own notes.
  (I’ve written about how Obsidian Copilot works well with the concept of RAG and building a second brain here)

• Smart Connections surfaces related notes by meaning, even ones you never linked.

• Dataview turns your notes into a database you can query and lay out any way you want.

You need none of them to start. They’re there when you want them.

What that looks like in real work

Once wired, the vault can:

• Pull one topic across your whole history: what you thought, what you researched, how it changed.

• Answer “what did I decide about this?” with the note where you decided it.

• Draft from your own past work instead of a blank page and generic advice.

• Read across everything you’ve saved on a subject and hand back the patterns and the gaps.

• Surface a note you’d forgotten, right when it’s relevant.

Your version will depend on what you feed the vault and how you connect the dots.

Mine became a working memory layer. This is what that looks like.

Share

What Does a Connected Obsidian + Claude Second Brain Look Like?

My vault went through several versions before it settled into this.

Now I use it for five things, all from the same connected vault.

Pull one topic from everywhere

A connected vault lets me ask one question across my whole history.

I can ask, “What did my vault say about SEO?” and Claude pulls the answer from strategy docs, draft notes, GSC data, and old decisions. It gives me the point, then shows the file each piece came from.

No folder-hunting. No rereading everything.

When I want the raw cluster, I can search by tag instead. obsidian search query="tag:#mcp" pulls 428 MCP notes across articles, short-form posts, programs, and products.

One question gives me the synthesis. One tag gives me the whole cluster.

Turn a cluster into a dashboard

A tag search is useful, but 428 notes is still a wall.

So I asked Claude to build me a Base. The structure was already there: status, category, date, tier, tags, folder. Claude turned those fields into a sortable table in one pass.

Now the MCP cluster is a dashboard. I can sort by status, scan stale drafts, filter by category, and decide what to do next.

The notes stay the source of truth. The table is just a view.

Let the graph connect itself

I did not link those notes by hand.

Claude linked as it worked. The graph changed from scattered dots into clusters, then those clusters started connecting across topics.

That is the part I wanted: the vault getting more useful every time work passes through it.

Turn the same cluster into a map

Same notes, different shape.

I asked Claude to lay the MCP cluster out as a mind map. Because the links were already in the vault, it could build the map from the structure: central topic, themes, and the articles under each theme.

Every title is still a real note. Hover to preview. Click to open.

The map is not separate from the vault. It is another way through it.

What changed in my day

The screenshots are the easy part to show.

The real change is the workday.

Before, I was the memory. I guided the AI step by step. I reminded it where to look, what mattered, and what connected.

Now I hand more of that to Claude. It files the note. It links what relates. It pulls old decisions back when I need them. When I write, it drafts from my notes, my past work, and my voice instead of a blank page.

And it does it cheaply without burning tokens, because the index does the work instead of a full re-read.

That is the second brain working.

Something that remembers for you.

Share

You have seen the shape now: Obsidian gives Claude a memory it can read, update, and move through.

The rest is the build.

• Connect Claude to your vault: the setup that lets Claude read your notes through Obsidian’s index.

• Give Claude the right jobs: the prompts that connect, clean, and organize the vault without breaking it.

• Install the skills: so Claude knows how to search, link, write, build Bases, and make maps.

• Set the vault structure: folders, hubs, tags, and note shapes that still work after hundreds of files.

• Keep it alive: the output contract and cleanup loop that stop new captures from becoming clutter.

The Obsidian Second Brain Kit packages that system: the pre-built vault, the skills, the prompts, the setup sheet, and the weekly cleanup. Build it by hand from the steps below, or start from the kit and customize it from there.

Upgrade to Premium

How Do You Connect Obsidian and Claude?

Read more

I lost one entire afternoon arguing with Claude over one rule.

It was right there in my CLAUDE.md. Bold, clear, impossible to miss. Sitting in the middle of a long file.

Claude broke it anyway. So I wrote it again, lower down. Then a third time, louder.

It got worse.

My wording was never the problem. My placement was.

The model doesn’t read your file top to bottom.

It parses it.

It scans for boundaries and weighs position. A rule buried in the middle gets the least attention of all.

I write skills files, prompts, and Substack posts for AI every week. The same placement hides a rule from Claude, and a line from AI search.

Once you see text the way the model sees it, the fix stops being guesswork.

The same move every time: clear boundaries, the important part where it looks.

It works on a prompt, an agent file, and a post you want cited. We walk through all three.

What’s inside:

• Why does it matter if AI can read your writing?

• How does AI read your text?

• How do you write so AI follows it?

• What formats do LLMs like to read: Markdown, XML, JSON, or YAML?

• How do you get cited by AI?

• By the end: you can format any prompt, CLAUDE.md, or post so the model actually uses it

• 🎁 The LLM Format Decision Cheat Sheet: grab it at the end

Subscribe now

Why does it matter if AI can read your writing?

Your words have two readers now. You, talking to the AI. The AI, talking about you to everyone else. Most people write for one and forget the other, and the formatting is what decides whether either one lands.

Three reasons it is worth getting right.

So the AI does what you actually asked. When the model can parse your prompt, you stop running the same request three times to get one clean answer. The fix is small, and it pays off on every prompt after it.

So what you build on top of AI holds up. Wire a model into an agent, an automation, or a workflow, and it only runs reliably when it reads its instructions the same way every time. Readable instructions are a reliable system. Sloppy ones are the bug you cannot reproduce.

So AI can find you, understand you, and recommend you. More people ask ChatGPT or Perplexity now instead of Google. If a model cannot parse your post, your product page, or your site, you are invisible in the one channel that is growing. Format it so the machine reads cleanly, and you become the answer it hands back.

The first two are AI as your tool. The third is AI as your audience. Same move, pointed two ways: write so the machine can parse it. That starts with seeing how it reads.

How does AI read your text?

It scans for structure and pulls out the parts it can find. It does not read top to bottom the way you do.

Picture how you read a page. Left to right, line by line, holding it all in your head. A model does not do that. It breaks your text into tokens and leans on the cues that mark where one thing ends and the next begins. A heading. A blank line. A bullet. Those boundaries are what it grabs.

There is a mechanism under this. A 2025 study called SepLLM (arXiv 2412.12094) found that separator and punctuation tokens pull a disproportionate share of the model’s attention, more than the meaningful words between them. The model leans on your dividers to find its place. A boundary is not decoration. It is a handhold the attention actually grabs.

So a wall of text and the same text broken into labeled sections carry different amounts of signal, even when the words are identical. The prose version makes the model guess where the parts are. The structured version tells it. That is the first thing the model does with your text: it organizes by the boundaries you give it.

But position matters even more than structure. Researchers named this “lost in the middle.” A 2023 study from Stanford, Berkeley, and Samaya AI (arXiv 2307.03172) tested models on long inputs and found a U-shaped curve. Information at the very start and the very end gets used. Information in the middle falls off by more than 20 points of accuracy.

A bigger context window does not fix this. It adds more middle. NVIDIA tested 17 long-context models on a benchmark called RULER (arXiv 2404.06654). Most degraded as the input grew, and only about half held up at 32,000 tokens. A 2026 analysis (arXiv 2603.10123) argues the curve is baked into how a causal transformer attends, present from the start of training, which is why a longer window does not erase it.

The cleanest proof that position alone moves results comes from Anthropic. They buried one fact in a long document and asked Claude 2.1 to find it. Recall sat at 27%. They changed nothing in the document. They added one line near the end, “Here is the most relevant sentence in the context:”, and recall jumped to 98%. The same lab found that on complex inputs, placing your question at the end, after the context, improves quality by up to 30%.

Same model. Same document. Same question. The only thing that moved was where the model was pointed.

That is the model you are writing for. It organizes by the boundaries you give it, and it spends its attention on the edges, not the middle. Once you can picture that, writing for it stops being mysterious. You are not learning some AI dialect. You are making the model’s job easier, and it comes down to a handful of rules.

Share

How do you write so AI follows it?

Give the model clean boundaries, and put the important part where it looks. That is the answer, in five moves. No new research here, just what the section above tell you to do every time you write a prompt.

Separate the kinds of information. Instructions in one block, context in another, examples in a third, not fused into one paragraph. There are a few ways to draw those boundaries. The lightest is Markdown headings:

# Instructions
# Context
# Examples

OpenAI’s GPT-4.1 guide says to start there. When the blocks get long or you need harder walls, XML tags do it:

<instructions> ... </instructions>
<context> ... </context>

Anthropic recommends exactly this so Claude can parse each block “unambiguously.” There are no magic tags. Any consistent label works. The point is the boundary, not the syntax.

If Markdown and XML are new to you, do not worry about the syntax yet. You have only met them in passing here. The next section introduces all four formats properly, with what each one actually is.

Put your most important instruction first. This is the CLAUDE.md from the start of this piece (if you have not set one up yet, I’ve written a Claude onboarding guide that covers it). My rule did not fail because it was wrong. It failed because it sat in the middle of a long file. Top of the file, first line under the heading, not buried three rules deep.

For a long input, repeat the key ask at the end. The model reads the edges best, so bracket your request: state it before the context and again after. That is the move behind the jump from 27% to 98%.

Do not strand one critical line in the middle. If something has to live deep in a long document, lift it out. Put it at the top, or wrap it so it reads as its own block. The middle is where attention goes to die.

Keep your formatting consistent. Pick one structure and hold it across the prompt, instead of mixing headings, tags, and loose lists. Which structure to pick, Markdown, XML, or JSON, is exactly the next question.

Share

What formats do LLMs like to read: Markdown, XML, JSON, or YAML?

Four of them: Markdown, XML, JSON, and YAML. Markdown and XML are for talking to a model; JSON and YAML are for handing it data.

You met the first two in passing last section, so time to meet all four properly, definitions first, because the names hide what they are.

Markdown is a lightweight way to format plain text with a few symbols. Simply put: # for a heading, - for a list item, ** for bold. It was built to stay readable as raw text and to convert cleanly into web pages. It is the format you are reading right now.

# Task
- Tone: friendly
- Length: under 50 words

XML (eXtensible Markup Language) wraps every piece of content in a named, nestable tag: <thing>...</thing>. You invent the tag names yourself, which is the “extensible” part, so you can label each piece exactly.

<task>
  <tone>friendly</tone>
  <length>under 50 words</length>
</task>

JSON (JavaScript Object Notation) stores data as key-value pairs and lists, inside braces and brackets. It is the default way programs pass structured data around, and the model reads and writes it natively. OpenAI calls it “highly structured and well understood, particularly in coding contexts,” though it found JSON “performed particularly poorly” as a wrapper for many documents, and every brace is a token.

{
  "task": "write a description",
  "tone": "friendly",
  "length": "under 50 words"
}

YAML (YAML Ain’t Markup Language) holds the same key-value data as JSON, but uses indentation instead of braces, which makes it easier for a person to read and edit. It is what most config files are written in.

task: write a description
tone: friendly
length: under 50 words

Now the split is easy to see. Markdown and XML are how you talk to the model. JSON and YAML are how you exchange data with it. The four side by side:

All three labs land in the same place: structure beats no structure, and the choice matters less than staying consistent. Gemini’s guide puts it in one line, “choose one format and use it consistently within a single prompt.” Mixing Markdown headers, XML tags, and loose JSON in one prompt is worse than picking one and holding it.

Does format actually change accuracy? On older or smaller models, yes, a lot. A Microsoft and MIT study (arXiv 2411.10541) found GPT-3.5-turbo’s accuracy swung up to 40% on the same task from the template alone, and on one task JSON beat Markdown by 42 points. A separate study, FormatSpread (arXiv 2310.11324), found up to 76 accuracy points of spread on Llama-2-13B from formatting choices a person would call cosmetic. Bigger models are more robust. More robust is not immune, and you do not always control which model runs your text.

On token cost, the honest version. There is no authoritative per-format table, so be wary of confident percentages. As a feel for the spread, a quick tiktoken count of the same content lands plain text and Markdown lowest, then YAML, then JSON (in one run, roughly 65, 76, 98, and 117 tokens). The order is solid. The exact numbers are not.

When does structure backfire? When you over-constrain. Forcing a model to answer inside a rigid schema can cost it reasoning room: a 2024 study (arXiv 2408.02442) found stricter format restrictions hurt performance on reasoning tasks. The counter, from dottxt, is that structure matched or beat free-form when you let the model reason first and convert to the format after. The takeaway holds either way: structure your input generously, but do not strangle the output into a tight schema before the model has thought. Let it reason, then format.

That covers what each format is for. The decision, on one page:

Two of those carry a number worth keeping. On a complex prompt, Anthropic found that putting the question last, after the context, improves quality by up to 30%. And on a CLAUDE.md, lean wins: a 2025 benchmark (arXiv 2507.11538) found per-rule adherence drops as instructions stack, to about 68% at 500 instructions, the model favoring the earliest. The “under 200 lines” rule of thumb (techsy) points the same way.

That is writing to a model. The other direction is getting a model to quote you, and that is where the last format finally comes in.

Share

How do you get cited by AI?

Structure a page the way a model likes to read, and you are far more likely to be the source it quotes.

When someone asks ChatGPT or Perplexity a question, it pulls from pages it can parse cleanly and lift in pieces. Same physics as your prompt: boundaries it can find, answers it can extract. The pages that get cited are the ones built like lookups.

This is where HTML finally earns its place. You strip it out when you feed a page to a model, raw HTML is mostly markup, and converting to Markdown can cut the tokens by roughly a third or more. But when you publish, HTML is how a model finds you. Semantic HTML, real headings, lists, and tables, with structured data underneath, is the boundary system a crawler reads. Same principle as everything above, pointed outward.

A few patterns show up again and again in citation studies. These are correlations from SEO and vendor research, not promises from the model makers, so hold them loosely:

• Tables get pulled. Nectiv’s study found ChatGPT citations were 2.3x more likely to include a table than Google’s results, 30% against 13%. A comparison table is a pre-chunked answer.

• Comparison listicles lead. The Digital Bloom’s 2025 report put comparative listicles at 32.5% of all AI citations, the single most-cited format.

• Short answers win. kime.ai found self-contained passages of 40 to 75 words cited about 3x more than longer ones. State the answer, then explain it.

• How-to beats opinion. Presence AI’s data shows how-to pages cited 54% of the time and FAQ pages 58%, against just 18% for opinion pieces. Teach a step; do not just take a stance.

One honest limit, since the question is what crawlers actually parse best. These studies measure content structure, the table, the short answer, the how-to. The narrower question of file format, plain Markdown versus semantic HTML versus JSON-LD, has much thinner public data. The safe read: publish clean, semantic HTML with structured data underneath so the crawler can tell a heading from a caption from an answer, and shape the content itself as answer-first chunks. Structure at both levels, since only one of them is well-measured.

Notice the mirror. To feed a model, you strip a page down to clean text. To get cited by one, you publish structure the crawler can read. Same goal from both ends: make the boundaries legible.

This article is built that way on purpose. Plain question headers. Short answers up top. A table you can lift. That is the thesis in practice.

You have the physics, the formats, and the publishing side. One move ties them together.

What’s next for you

Open your CLAUDE.md right now and move your single most important rule to the top.

That single move uses everything above: position (the top, where attention lives), a clean boundary (one Markdown line), and the rule that outlasts every format debate.

Here is that rule, the one under all the others. Models do not read, they parse. So write for the parser: give it boundaries it can find, put what matters at the edges, and say what to do instead of what to avoid. That last part is its own small fix, and it is measured: a 2026 study (arXiv 2601.08070) found “don’t do X” instructions failed far more as the pressure rose, and when they failed, the model was attending to the forbidden word more than to the “don’t.” So “use sentence case” lands better than “do not use title case,” because “title case” is a phrase you just handed it.

The jump from 27 to 98 at the start was not a smarter model. It was the same model, finally pointed at the right place. Your prompts, your CLAUDE.md, and your posts each have a right place. Now you know where it is.

If this article made AI feel a little more predictable, pass it on to someone who’s still fighting with prompts instead of building with AI.

Share

And if someone shared this with you, subscribe free so you don’t miss the next guide.

Subscribe now

What is the one rule your AI keeps ignoring? Move it to the top, and tell me in the comments if it finally sticks.

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

Canva is one of the most-used design tools in the world. Hundreds of millions of monthly active users, creating everything from social posts to presentations to infographics.

Even on the free plan, you can make professional-looking designs.

But I could never master Canva the way I wanted. Getting an idea out of my head and into a finished graphic meant arranging the layout, adjusting the spacing, replacing elements until it felt right.

For over a year, that was where I got stuck.

Too many panels, too many buttons, too many decisions. I could picture what I wanted. I just couldn’t get there fast.

Now that’s changed.

Instead of designing inside Canva, Claude builds the design and imports it straight into Canva as a fully editable file.

Give Claude one article, and it generates:

• An infographic

• A 9:16 story

• An Instagram square

• A YouTube thumbnail

• A 7-slide carousel

Every one arrives as a real Canva design you can edit and export. All on the free plan.

That’s what caught my attention. Canva’s own AI tools cap out at ten generations, lifetime. The import has no cap at all. Generate as many as you want, no credits burned.

So I tested how far a free Canva account actually goes.

What’s inside:

• What the Canva MCP gives you

• Creating infographics, carousels, and charts from one article: all on a free plan

• The skill that makes the Canva MCP effortless: the kit and the exact prompts

• Run it, step by step: to your first finished kit in about 20 minutes

• Make it yours: your brand, every design coming out on-brand

• Forty tools, five that matter on free: the tool calls the whole workflow rides on

• Where the free plan stops: the Pro walls, and the free path around them

• By the end: a finished, exported, on-brand visual kit from Claude on a free Canva plan.

• 🎁 The Free-Plan Visual Kit: grab it at the end.

  • The skill, the on-brand templates, the prompts that run it in your own Claude, plus the tool reference, the by-hand recipe, and my test log of what a free plan does and doesn't do.

What the Canva MCP Gives You

An MCP is a connector that lets Claude operate another tool directly.

The Canva one lets Claude build designs inside your Canva account and hand them back as real files. PNG, PDF, a full slide deck.

Not a flat AI image with the text baked into the pixels, where fixing one typo means regenerating the whole thing and hoping it lands. A Canva file you own, reopen, and change one element at a time.

Setting it up takes two steps, both free:

1. Register on Canva.com. I just log in with Google.

   

2. Connect Canva to your AI. In Claude, add it under Connectors. It works the same from ChatGPT and other assistants that support connectors.

Creating Infographics, Carousels, and Charts From One Article

First, to get familiar with it, I started with the simplest input I could: one plain page. No design, just the content from a single article. I asked Claude to bring it into Canva.

It came back as a real, editable Canva design.

That verified the workflow. Time to explore what it can actually make.

Every format I’d post

Formats are the finished shape, sized for where it gets posted.

I tried the formats I was actually interested in with one article:

• Instagram square

  

• Vertical story

  

• Wide YouTube thumbnail

  

• Tall infographic

  

Same content, reshaped for each slot.

Multi-slide carousels

Seven slides from the same article, sequenced, each its own page.

I even used Canva MCP to collage the set into one grid to show the whole sequence at once.

Custom Image Backgrounds

I dropped in a workspace photo and asked for a muted overlay so the text stayed readable. Both came through the import clean.

And I tried more background images, with my own article covers.

Every file above came out of one article. None of it touched Canva’s UI button.

Different Layouts

How the content is arranged inside any format? I’ve always had a few I’d love to include in my blocks.

I asked for the layouts I reach for when I’m explaining something.

Start with A stat hero.

Then the rest, in one pass:

• Bar chart

• Donut

• Comparison table

• Checklist

• Flowchart

• Cycle

• Pyramid

• Venn

• Code card

Every one came back clean and on brand. Not a chart widget I had to wrestle into shape. A finished layout I could export or keep editing.

Branded colors and styles

The above are all using my brand color in purple, so I tested different color and styles on the same content:

Different surfaces

Then I tried the thing I’d half given up on:

• Whiteboard surfaces.

• Chalkboard.

• Kraft paper….

I used to make these with AI image tools, and they landed maybe half the time. The text warped, the lines smeared, the same prompt gave a different mess every run.

Canva just made them.

On demand, legible, the same every time.

Elements

Along the way I collected the element styles I kept reaching for, now in one place Claude can pull from.

Many of these used to mean half a day in the editor, or paying someone to do it.

This run took one afternoon, all on the free path, and the files can be reused as many times as I want.

The one thing it didn’t solve: making every new design match the last. That, and the rest of the how, is past here.

• Claim the skill: the kit I built, plus the exact prompts that drive it.

• Run it, step by step: the full walkthrough to your first finished kit, prompt to exported files, in about 20 minutes.

• Make it yours: set your colors, fonts, and logo once, so every design after comes out on-brand, design #10 still matching design #1.

• Where the free plan stops: which Canva Pro walls are real, and the free path that routes around the ones that aren’t.

It’s all in the Free-Plan Visual Kit. Grab it below.

Read more

Multi-step agents scanning covers via API drift: each handoff loses context and prompts slip from your brand. FastMCP’s Image type keeps everything in one Claude session.

Two modes via one skill: reverse-engineer any cover style (one article or a full brand audit), generate a prompt per article.

One MCP URL that you just connect and let the skill handle the rest.

I’ve spent the past year building systems to get consistent Substack covers.

Not consistent-ish. Not “close enough.” The kind where someone scrolls your archive and sees a coherent visual identity instead of a collection of experiments.

I wrote about this in How I Create Consistent Hero Images.

The system works. Attach a reference image, document the prompt, maintain a brand template file. But since publishing that piece I started getting the same follow-up question:

What happens when the model drifts two weeks later?
When you paste in the same prompt and get something that looks slightly, subtly, wrong?

The honest answer: re-attach the image. Re-seed the context. Start over.

To make it less painful, you could write skills, connect to MCPs, and build an autonomous agent around it.

Alejandro tried the ambitious version. A multi-step agent: call Claude’s vision API on each cover, extract brand learnings per image, aggregate them, then generate a prompt to feed into DALL-E or GPT-image-2.

It worked. But each handoff between steps dropped context. The generated prompts drifted from the actual brand. The agent took more effort to maintain than just eyeballing the covers manually.

So he rebuilt it at the protocol level.

What I appreciate about how Alejandro works: he treats the tool layer as real infrastructure.

We both agree on this: the setup work should happen once at the system level, not every session at the prompt level. That’s what a skill does. That’s what this piece shows.

If you want to go deeper into Alejandro’s thinking before reading:

• Why Skills and MCP Work Better Together

• Hands-On: Building a Substack Agent with Skills and MCP

• AI Observability for Data Engineers

In this piece, Alejandro walks through how FastMCP’s Image type solves the context-loss problem, how the visual-brand skill runs in two modes (reverse-engineer any publication’s style, or generate a prompt for your next article), and how to connect and use it right now from Claude Desktop, Claude Code, or Cursor.

Here’s Alejandro!

The Gap in Every Image Workflow

When I read Jenny’s article about consistent hero images, I recognized the system and the problem it’s trying to solve immediately.

Thing is, consistency becomes a manual operational process you keep repeating, praying that image generation models follow without drifting.

How do you extract your visual brand DNA and hand it to someone else? You explain it manually or use custom prompts-skills, but the image reference still needs to be attached one way or another to build the context.

That’s still manual work, moved from the creation stage to the audit stage.

I ran into this gap while building a multi-step agent to solve it for my own publication.

The setup: call Claude’s vision API on each cover, extract brand learnings per image, aggregate them, then generate a prompt to feed into DALL-E or GPT-image-2.

It worked, but each handoff between steps dropped context.

The generated prompts drifted from the actual brand. Maintaining the agent took more effort than just eyeballing the covers manually.*

Two additions to the Substack Author MCP collapsed that entire pipeline to end up with a prompt that will help you with this brand consistency pain.

Part 1: Teaching the MCP to See

Most MCP tools return text. Strings, JSON, structured data: all things the AI reads like a document.

FastMCP also has an Image type. When a tool returns it, the AI doesn’t read. It sees.

from fastmcp.utilities.types import Image

def get_article_cover_image(article_url: str) -> Image:
    ...
    return Image(data=img_resp.content, format=fmt)

Two differences from returning a URL as text:

1. Image(data=..., format=...) wraps the raw bytes with format metadata

2. The MCP client (Claude) receives it as visual input, not a string

In the multi-step agent approach, Claude received a text description of the image passed from one API call to the next. Here it processes the visual data directly in a single session without context loss between steps.

When I tested this on my most recent article, Claude returned without any prompting:

And the breakdown was quite spot on.

Subject / Focal point A person (you?) center-frame, smiling, hands raised like conducting chaos. Relaxed, confident posture. No stress despite the chaos around him. The 💩 with sunglasses on the shirt adds personality and humor.

Background / Environment Dark background (near black) with neon glowing elements. A “digital universe” aesthetic — particle streams, graph networks, floating UI panels. Orange/red on the left, pink/magenta on the right, blue/green in lower corners. High contrast, high density.

Floating UI elements Multiple neon-framed panels surrounding the figure...

Let’s see how this gets combined with skills.

Part 2: Skills and What They Do

Seeing covers is one thing. Without a workflow on top, you prompt from scratch every session, explain your intent, repeat yourself each time.

That’s where Skills come in, and this is the part most people haven’t seen yet.

The Substack Author MCP uses FastMCP’s SkillsDirectoryProvider. Two lines on the server:

from fastmcp.server.providers.skills import SkillsDirectoryProvider

if skills_path.exists():
    mcp.add_provider(SkillsDirectoryProvider(roots=skills_path))

This scans a .claude/skills/ directory, finds every SKILL.md file, and exposes each one as an MCP resource: a doc the AI can read on demand when it recognizes the right context.

The difference between a tool and a skill:

The MCP currently ships with 6 skills. One of them, visual-brand, was built specifically for what Jenny’s article was about. (I wrote a full breakdown of how Skills and MCP work together if you want to go deeper.)

The visual-brand Skill: Two Modes

When you connect to the MCP and ask about covers, the AI loads visual-brand automatically. Two modes depending on what you’re trying to do.

Mode 1: Generate a New Cover Prompt

“I’m writing a new article. Give me a cover prompt consistent with my brand.”

Give it your publication URL and article title. The skill fetches your recent covers, establishes your visual DNA, then composes a prompt that fits the article’s specific topic and mood while staying inside your visual system.

Output comes out with just a ready-to-paste prompt block.

Mode 2: Reverse a Style

“What’s this cover doing that makes it work?”

Give it a URL, a single article or a full publication, and tell it how many covers to scan. The skill calls get_cover_image on each, analyzes palette, layout, subject, mood, and style, then outputs a ready-to-paste prompt.

Single article gives you a bullet breakdown and a style prompt. Multiple covers flag outliers and output a brand template with [variable] placeholders for what changes per article.

This came out from my latest article on AI Observability for Data Engineers.

Scanning 5 covers outputs something like this:

Photorealistic digital illustration, newsletter cover, portrait 2:3, high resolution.

Subject: curly-haired man with glasses and a 💩-with-sunglasses emoji t-shirt, center-frame, [expression and gesture: smiling + open hands for approachable

topics / serious + pointing for critical topics / dynamic riding pose for architectural concepts].

Background: near-black or deep navy, dense particle field with neon light streams — orange/amber radiating from center-left, pink/magenta on the right, [accent: green for validation/success / blue for data/structure / purple for AI/LLM themes].

Floating UI elements: 2–4 neon-framed panels surrounding the subject, each labeled with [article-specific technical concept]. Border colors: orange for

process/pipeline, pink/magenta for AI or warnings, green for success states, blue for data schemas.

Style: hyperrealistic rendering, cinematic lighting, neon glow with soft bloom, dark cyberpunk aesthetic with dense technical detail.

Mood: [confident and chaotic for overview articles / focused and analytical for deep-dives / kinetic and motion-forward for architecture articles].

That’s your visual brand DNA in text form. Paste it into ChatGPT, Midjourney, Flux — any generator you’re already using. The [variables] swap per article. The DNA stays fixed.

How I Use It & You Can Use It Too

This won’t fully solve the need to attach the image on ChatGPT, but it will solve a lot of the consistent breakdown.

My current workflow relies on:

• A brand template file saved to my Obsidian vault

• The MCP skill to create a prompt just like the one you saw

• Then I attach one image or keep reusing a ChatGPT conversation

Whenever Claude releases image models or ChatGPT allows proper MCP usage, this might become even more straightforward since the attachment won’t be needed at all.

No installation. Add this to Claude Desktop, Claude Code, Cursor, or any MCP-compatible client:

https://substack-author.fastmcp.app/mcp

In Claude Code, skills are exposed as MCP resources — the server instructions tell it which workflow to activate based on what you ask, no manual @ mention needed. Claude Desktop and Cursor work the same way.

Then try:

“Look at the last 5 covers from [your publication URL] and build me a brand template prompt.”

Or point it at any publication you admire:

“Reverse-engineer the cover style from [any public Substack URL].”

The tools, image processing, and visual-brand skill are all already there when you connect — just tell it what you want.

What's the one thing in your current image workflow that you keep redoing every session?

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth