If you’re scrolling through web pages, copying text, clicking through intake forms, manually filling out the same bio for the fifth time this month. Complaining, at least internally, about how long all of this is taking.

Claude in Chrome is probably the easiest solution you could find.

What it does: you give Claude a browser tab. It navigates, clicks, fills, extracts. The stuff you’ve been doing by hand.

The funny part is the 2.7-star rating on the Chrome Web Store. 838 people left that number.

But that rating is about one thing: the installation. Everyone who left that review hit a setup wall, wrote something frustrated, and never saw what happens after.

I went through the install, found the fix (it lives in a Reddit thread, not the official docs), and spent a full session testing every workflow I could use. Some worked. Some failed. A few changed how I handle recurring browser work.

What’s inside:

• How to Set Up Claude in Chrome: three setup paths and the single fix that resolves most install failures

• Type 1: Use Claude to Read and Extract From Any Web Page

• Type 2: Use Claude When the Web Needs to Know Who You Are

• Type 3: Use Claude to Evaluate Pages Against Your Criteria

• Type 4: Use Claude to Test Your Product Before Anyone Else Does

• Type 5: Run Browser Tasks on a Schedule, Without You There

• Which Claude in Chrome Type Fits Your Work?

• Claude in Chrome Limitations: 5 Things That Break

How to Set Up Claude in Chrome

There are three ways to bring Claude into your browser:

• Install from chrome web store (pre-requisite)

• Install from Claude desktop

• Install from Claude Code

How to Install the Claude for Chrome Browser Extension

This is the non-negotiable step, you have to install Claude Chrome Extension from the Chrome Web Store in order to use it anywhere.

1. Go to the Claude listing in Chrome Web Store

2. Click Add to Chrome

3. Once installed, pin the extension to your toolbar

4. Click the extension, log in and authorize

You need a paid plan (Pro, Max, Team, or Enterprise) for the extension to work.

If the extension isn’t connecting after install, run through these steps in order:

1. Sign out of Claude completely (not just close the tab; go to Account → Sign out)

2. Clear your browser cache (Settings → Privacy and security → Clear browsing data)

3. Log back in using your email address, not Google OAuth

4. Reload the extension

That single fix resolves the vast majority of connection failures. Edge cases remain on Brave, Arc, and Edge, and Linux users have reported intermittent issues. For most people on a standard Chrome install, this one sequence gets you through.

The 2.7-star rating on the Web Store is almost entirely install-era frustration from people who hit this and gave up before finding the fix. I spent time on it too. Now Claude has improved the installation experience to be much more smooth.

How to Set Up Claude in the Desktop App

The Claude desktop app unlocks Computer Use mode: this is where Claude can take control of your entire screen, not just your browser. You need this if you want Claude to navigate applications outside Chrome: Figma, Slack, your file system, anything that isn’t a web page.

1. Download the Claude desktop app at claude.ai/download

2. Sign in with your paid Claude account

3. Computer Use mode is available immediately. You’ll see it as an option in a new conversation

For browser-only tasks, the Chrome extension is the better choice: it’s faster, uses fewer resources, and is more precise within web pages. Switch to the desktop app when your workflow crosses into non-browser applications, or when you need Claude to see your full screen.

This distinction matters more than it seems. There’s a resource trap that catches people who have both modes active at once. I’ll come back to it in the failure cases section.

How to Connect Claude Code to Chrome

This is the terminal path. The Claude Code CLI has a Chrome integration in beta that connects your terminal to a live Chrome session. Claude can then read DOM state, inspect network requests, and run browser automation you describe in plain English instead of code.

1. Install Claude Code (version 2.0.73 or higher) and the Claude for Chrome extension (version 1.0.36 or higher)
   For how to install Claude Code, this article will get you up to speed.

2. Start a session with the --chrome flag: claude --chrome

3. Claude installs a native messaging host automatically on first use, no MCP config needed

4. To enable Chrome by default so you don’t need the flag each time, run /chrome inside a session and select “Enabled by default”

You can also enable it mid-session by running /chrome. Run /mcp and select claude-in-chrome to see the full list of available browser tools.

One distinction to hold onto throughout this guide: the CLI integration opens new tabs in your actual Chrome browser and shares your login state, so it can access Gmail, Notion, Google Docs, and anything else you’re already signed into. That’s the same access the consumer extension has. I’ll flag which product applies as we go.

Type 1: Use Claude to Read and Extract From Any Web Page

What you need: Claude for Chrome extension (Pro, Max, Team, or Enterprise plan). No desktop app required.

This is where almost everyone starts. The core workflow is targeted extraction: you point Claude at a page, tell it what you need, and it returns exactly that. You don’t read the whole thing.

Reading a live site you’d otherwise skim

Use this when: you’re opening pages one by one just to find the few details that actually matter to you.

URL: https://www.anthropic.com/news

The prompt:

Read every news happened in the month of April, and tell me what actually changed for someone doing creative work with Claude

What happened: Claude returned four changes, each with a one-sentence explanation of why it mattered for creative work: Claude Design launch, Opus 4.7 vision upgrade, creative tool connectors (Adobe, Blender, Ableton, and more), and the educational partnerships.

No press release framing. Just: here’s what changed, here’s why it matters to you.

Why this matters: This is a task that normally takes 20 minutes of link-hopping. Claude read the whole newsroom, filtered by your angle, and returned only what was relevant.

Extend this to:

• Multi-page pricing research across tools like Notion, Craft, and Obsidian

• Competitor landing page scans

• Release note summaries filtered by your role

• Product documentation searches

• Any research task where the answer lives across several tabs

The catch: This type of use is helpful, but it is not the best advantage. Every AI tool does page summarization: ChatGPT, Perplexity, Gemini all handle this. If this is all you use Claude in Chrome for, you’re using a very small part of what it can do.

The next four types are where it does the tedious browser work you’ve been doing by hand.

• Personalized inputs: Claude uses what you’ve already told it (your bio, positioning, projects), so you stop re-entering the same things

• Criteria-based evaluations: Claude applies your standards to a page, instead of making you rebuild the rubric from memory

• Product testing: Claude clicks through your product before anyone else does and brings back what broke

• Scheduled tasks: most people have never found this, Claude runs browser checks on a schedule, without you there at all

Upgrade to Premium

Type 2: Use Claude When the Web Needs to Know Who You Are

Read more

When the Claude Code redesign dropped in April, the biggest draw wasn’t the new UI.

It was Routines: a scheduling layer that promises to run your AI work autonomously. Lighter than OpenClaw. No server required. Built right into Claude.

The biggest question I got from that update was:

Is OpenClaw still worth exploring?

I get the anxiety. You bought the Mac Mini, did the install, got things running. And now Claude has a scheduling layer built in, and Hermes is chasing from the other side.

So I tested it. Migrated what I could to Routines, kept what belongs in OpenClaw, figured out where the line actually is.

And that line is more interesting than I expected.

OpenClaw was the first tool that made a lot of builders feel what autonomous AI work could become: an agent running workflows in the background, not just answering you in a chat box. But it also came with setup, hardware, architecture, and one more system to maintain.

Claude Code is now closing part of that gap.

Not all of it. But for recurring work like research digests, content planning, SEO checks, and project summaries, Routines get you surprisingly close with less setup and inside a subscription you may already be paying for.

That is the real change. You can now get a meaningful version of autonomous AI work without building the whole automation stack first.

In this guide, you will see:

• Where Claude Code Routines Fit — the quick version of why they matter

• 7 recurring tasks worth scheduling right now — from a 2-minute demo to a full research-to-planning stack

  • The First Routine (Demo)

  • Weekly Research Digest

  • Daily Inbox Triage

  • GSC Opportunity Review

  • Daily Notes Generation

  • Doc Sync

  • Weekly Strategy Review

• Does Claude Code Replace OpenClaw?

• The first routine I’d build — the one that shows the return fastest

Where Claude Code Routines Fit

If you already read the Claude Code redesign breakdown, you can skip ahead. This is the quick version for everyone else.

Routines are scheduled tasks inside the Claude Code tab of the desktop app.

You give Claude a project, an instruction, a schedule, and an output location. Then it runs the task without you opening a live chat.

The important part is that this is code-first automation. Claude can read files, use your local context, run logic, and write the result back into your repo.

That puts Routines at Level 3 in my 4 Levels of AI Automation framework: above one-shot Claude sessions, below full OpenClaw pipelines.

Use them when the job is:

• repeatable

• file-based

• scoped enough to review after the fact

The cleanest shape is simple:

Read these inputs on this schedule. Produce this output. Tell me when it is done.

If a failed run leaves you with a missing report or stale planning file, a Routine is fine.

If a failed run sends the wrong email, deletes data, publishes publicly, charges someone, or blocks another workflow, use something heavier.

That is the whole point: Routines give you useful autonomous work without making you build the whole automation stack first.

For this guide, I am focusing on local Routines. They run on your Mac, which means your machine needs to be on, but they can use the files, repos, and MCPs you already have connected.

Claude Code Routines Worth Scheduling

What follows is a progression from the simplest possible Routine to more complex setups.

The first Routine is deliberately tiny. It is there to help you understand the mechanics: what it feels like to set something up once, hit Run Now, and see Claude do something without you prompting it live.

After that, each Routine teaches a reusable pattern. Once you understand how one Routine works, you can point that same shape at a different topic, tool, data source, or workflow. You can also expand on top of it.

That is the change I want to deliver in this piece: you are not just copying my automations. You are learning the building blocks for your own scheduled AI workflows.

Each Routine follows the same structure:
- what it does,
- what tools it needs,
- what goes in,
- what comes back,
- why it is useful, and
- a starter prompt you can copy and adapt.

Before scheduling any of them, run the Routine manually once and check three things:

• Did it read the right inputs?

• Did it write the output where expected?

• Did it leave a clear completion signal?

Do not schedule anything until the manual run produces an output you would actually trust.

Routine 0: The First Routine (Demo)

This one does nothing impressive. That is the point.

What it does: Claude sends a Slack message on a schedule. That is it.

Tools needed: Claude Code. A Slack MCP connected to Claude.

What goes in: A single instruction: “Send a message to #my-channel saying: Weekly routine fired at [time]. Date: [date].”

What comes back: A Slack message.

Schedule it for Monday morning. Hit “Run Now” once to confirm it fires. Then watch it run on its own next week.

Why start here: Most people never get their first Routine running because they try to build something useful before they understand how the mechanism works. This one removes that trap. Once you see a scheduled task fire on its own, even a trivial one, the rest becomes obvious.

Starter prompt:

Send a message to #[your-channel] in Slack:

"Weekly routine fired. Date: [today's date]."

The following routines are where this starts doing real work.

Each one shows a different type of data source or output:

• One pulls research from the web.

• One reads your inbox.

• One mines your own Google search performance.

• One repurposes content while you sleep.

• One fixes your build docs.

• One auto-adjusts posting strategy.

Different inputs, different outputs, same transferable pattern underneath each one.

Each routine tells you exactly what tools you need, what goes in, and what comes back.

Upgrade to Premium

Routine 1: Weekly Research Digest

Pattern: Data In — external sources

What it does: Claude scans a list of topics you care about, filters out what you have already covered, and writes a weekly brief on what is new and worth acting on.

Read more

If you’ve used it, you know: it searches the web, ingests PDFs and YouTube videos, and stores everything in a permanent, queryable notebook with citations.

If you’re new to it, it’s a free research tool by Google. Think of it as a knowledge base that only answers from sources you give it, or sources it finds from the web. It never makes things up from training data.

I’ve been using it for about a year. Appreciated the capabilities. But the biggest unlock came when you could finally connect it to Claude Code, which means your agent can query your notebooks mid-session, mid-build, 10x the power of Claude Code without extra bill.

What’s inside:

• What NotebookLM actually is

• How to use NotebookLM in the browser

• Why connecting it to Claude changes the workflow

• MCP setup in 15 minutes — two install paths with exact commands, works in Claude Code, Claude Desktop, and Cursor

• 10 use cases with prompts and real session outputs:

  • Do deep research from inside Claude

  • Query multiple notebooks in one session

  • Build an infographics pipeline

  • Build an app with Claude + NotebookLM

  • Index audio and video into your workflow

  • Content repurposing on autopilot

  • Find bug patterns across hundreds of log files

  • Automated daily research brief

  • Audio overviews for non-technical stakeholders

  • Team shared knowledge base

What NotebookLM actually is: source-anchored research, not a note app

It looks like a note-taking app at first glance. That’s what most people close the tab on.

NotebookLM is a source-anchored knowledge engine. It only answers from sources you provide or sources it researches for you. It doesn’t pull from training data. Every answer comes with a citation pointing to the exact passage it drew from.

That’s a fundamentally different behavior from Claude, ChatGPT, or Perplexity, and it’s what makes the Claude Code integration worth setting up.

Three things NotebookLM transform how you do work:

• Deep web research — a built-in feature that finds, evaluates, and imports sources on a topic. Real web retrieval from actual pages, not a language model estimating from training data.

• Multi-source grounding — load up to 300 sources into a single notebook. Every chat answer shows numbered references you can click to see the exact source passage.

• Artifact generation — from your sources, generate a podcast (Audio Overview), slide deck, study guide, FAQ, briefing doc, quiz, or infographic. From your sources, not from scratch.

Here’s how it compares to the tools you’re probably already using:

The honest framing: if your research fits in Claude’s context window and you don’t need citations, you probably don’t need NotebookLM.

It earns its place when you’re working across many documents over multiple sessions, or want web research without an API subscription.

How to use NotebookLM in the browser: sources, deep research, and artifacts

Before connecting anything to Claude Code, it’s worth knowing what the web UI can do on its own.

You’ll need: a Google account.

Go to notebooklm.google.com.

Create a notebook:

1. Click New notebook

2. Name it (e.g., “Research: [your topic]”)

3. The interface opens with two panels: sources on the left, chat on the right

Add sources:

NotebookLM accepts:

• Website URLs

• PDF files (upload from your machine)

• YouTube video URLs (it transcribes and indexes the full video)

• Google Docs or Google Drive files

• Plain text (paste directly)

You can add up to 50 sources per free notebook.

Run deep research:

In the sources panel, click Discover sources.

Type one focused research question. NotebookLM runs a web search, evaluates results, and imports up to 50 of the most relevant sources directly into your notebook.

I was learning about infographics patterns, my example prompt:

Search across high-quality sources (design blogs, academic papers, and data visualization guides) for principles of effective infographics and data visualization.

Focus specifically on extracting:

1. Core design principles

   • Visual hierarchy, layout, spacing, typography

   • Color usage and contrast

   • Balance, emphasis, and unity

2. Cognitive and perception principles

   • How people process visuals (attention, memory, cognitive load)

   • Gestalt principles, pattern recognition, information chunking

   • What makes visuals easy vs hard to understand

3. Data storytelling principles

   • How infographics convey narratives, not just data

   • Sequencing, flow, and guiding reader attention

   • When to use different chart types and formats

4. Practical rules and constraints

   • What to simplify vs what to keep

   • Common mistakes (misleading visuals, clutter, wrong chart types)

   • Trade-offs (accuracy vs aesthetics, density vs clarity)

Return results in this format:

• Grouped principles (Design / Cognitive / Data / Storytelling)

• Named frameworks or experts when possible

• Concrete examples (good vs bad, with explanation)

• Actionable rules I can apply immediately

Avoid generic advice. Prioritize specific, evidence-backed insights.

Chat with your sources:

Ask questions in the chat panel. Every answer shows numbered references you can click to see the exact passage in the source.

My example prompt:

What are the specific visual design rules that separate mediocre infographics from excellent ones? Cover: visual hierarchy construction, typography sizing ratios, color usage (how many colors, where, why), white space ratios, border usage, card shadows, badge placement, connector design, and the exact mistakes that make infographics look cheap or cluttered.

The answer cited specific passages from dual coding theory papers and Tufte-derived material, not a language model summary.

Generate artifacts:

In the Studio panel in the top right. Each artifact type has a different output format:

• Audio Overview — two AI hosts have a back-and-forth conversation about your sources. Downloads as an MP3. Useful for long research you want to absorb on a commute.

• Slide Deck (beta) — auto-generated presentation from your notebook content. Structured slides, ready to edit.

• Video Overview — a short animated video version of the Audio Overview. Same content, visual format.

• Mind Map — visual web showing how concepts in your sources connect to each other.

• Reports — structured written report pulling key findings across all sources, with citations.

• Flashcards — question-and-answer cards for memorizing key concepts from your sources.

• Quiz — multiple choice questions generated from your source content. Useful for testing comprehension on anything you’re studying.

• Infographic (beta) — a single-page visual summary of your notebook. Style presets only, no brand color control.

• Data Table — extracts structured data from your sources into a table format.

Here are two of my favorite artifact types:

• The mind map that guides you through thinking structure

• The slide deck that helps you visualize the knowledge base

This is useful on its own. If you want to deep dive into a knowledge base, the web UI gets you there without any setup.

But if you already use Claude, combining the two pushes the capability much further with less cost.

Why connecting NotebookLM to Claude is different

Claude Code loads CLAUDE.md at session start — that’s its memory. Any external documents you bring in are gone when the conversation ends.

And there are more constraints beyond session resets.

• Each session is scoped to one project, so cross-project research means starting over.

• Every document you add eats into the context window, driving up token cost. For a single focused session, this is fine. For research you want to reuse across projects and sessions, it compounds fast.

NotebookLM persists. The sources stay indexed. You query them each time instead of re-uploading, and your context window stays clean for the actual work.

Three concrete reasons to connect them:

1. Free web search, no API cost.

NotebookLM’s deep research does real web retrieval. Results are grounded, cited, and stored permanently in the notebook.

No Perplexity subscription. No Apify API. No external tool at all.

If you don’t have a Perplexity MCP set up (most users don’t), this is available right now, at no cost.

2. Grounded answers instead of estimated ones.

When Claude Code researches a topic and builds from that research in the same session, hallucination risk goes up. The model is doing two hard things at once: synthesizing information and generating implementation.

Separating them changes the output.

NotebookLM handles the research. Claude Code reads the grounded brief and builds from what the sources actually say.

3. Queries mid-session without breaking flow.

With an MCP connection, Claude Code can call notebooklm_query mid-build, get a sourced answer back, and continue. No switching to a browser. No copying and pasting.

The setup takes 15 minutes. The section below covers two install options, all 9 use cases I use weekly, and the prompts that make each one work.

But what surprised me most wasn’t the web research. It was all the capabilities the two tools combined together, with less token cost and better grounded work.

Upgrade to Premium

Inside: two install paths (with exact terminal commands) and every workflow I run regularly, with prompts and real outputs from sessions I’ve run.

• Connect NotebookLM to Claude in 15 minutes

• Do deep research from inside Claude

• Query multiple notebooks in one session

• Build an infographics pipeline

• Build an app with Claude + NotebookLM

• Index audio and video into your workflow

• Content repurposing on autopilot

• Find bug patterns across hundreds of log files

• Automated daily research brief

• Audio overviews for non-technical stakeholders

• Team shared knowledge base

Read more

You’ve read the growth advice. Engage with other creators. Write great notes. Exchange recommendations with newsletters in your niche.

All true. All useful.

And if you’re here, you’ve probably tried at least some of it. The recommendation exchange felt awkward to initiate. The notes felt like guessing. The articles took longer than expected. By the time you hit publish, you weren’t sure anyone was going to find them.

The frustrating part: the system works. It’s just slow when you’re running on limited time and limited social energy.

Full-time job. Two little kids. Maybe 4 spare hours a day across everything. That was my reality for the past year. Easy-going, but not a natural networker. I wanted to engage more on Substack. I just didn’t have the hours.

I still hit 6k+ subscribers and 200+ paid members in 12 months.

Not because I cracked an algorithm. Because I figured out what each growth level is actually buying you, then built tools to do the slow parts faster.

This article is both: the system, and the shortcuts.

What’s inside:

• Why the 3-level Substack growth framework works — what each level is buying you

• Level 1: Newsletter recommendation exchanges — how to find the right partners and what to say

• Level 2: Writing notes that perform — how to find your pattern without months of guessing

• Level 3: Writing content that compounds — the moves that separate growing writers from stalled ones

• The fast track: how I run all three levels with Claude and 4 BTL tools — step-by-step for paid members

🎁 DM template + note prompt pack — grab them at the end.

The 3-Level Substack Growth System

Before we get to the fast track, you need to understand what the three levels are buying you. Each one does a different job.

Level 1 is about surface area. Recommendation exchanges put your newsletter in front of audiences who already care about your topic. The person subscribing to a newsletter similar to yours is more likely to subscribe to you than a cold audience. It’s not glamorous. It is one of the highest-leverage early growth moves you have.

Level 2 is about presence. Notes keep your name in circulation between big articles. They surface you to followers of people who engage with you. They let you be interesting in 200 words when you don’t have 2,000. The writers who grow fastest on Substack are almost always consistent with notes.

Level 3 is the long game. Articles compound. A well-written piece brings in subscribers 6 months after you hit publish. It gets reshared, referenced, linked to. Writers who invest in craft and internal linking are building something durable. Writers who publish and forget are not.

The trap most people fall into: they go all-in on Level 3, skip Level 1 and 2, and wonder why growth is stuck. Or they focus on Level 1 and 2, publish mediocre content, and grow an audience that doesn’t stick.

You need all three. The question is how to run all three without spending your whole week on it.

Level 1: How to Find the Right Newsletter Partners for Recommendation Exchanges

Recommendation exchanges are exactly what they sound like. You find a newsletter in a similar niche, reach out, and if both sides agree, you each recommend the other to your subscribers. Substack has this built in as a first-class feature.

One good exchange can bring you 20–40 new subscribers in a few days.

My best early exchange brought in over 40 subscribers in 2 days. The other writer later messaged me to say it wasn’t fair: they had only received 3 back. I was smaller at the time. That’s how it goes sometimes. Still worth every message I sent.

How to find partners:

Search Substack’s Discover page for newsletters in your niche. Follow people. DM the ones that feel like a fit. The message doesn’t need to be long. It needs to be specific: why you follow their work, what you write about, a direct ask.

What to look for in a potential partner:

• Similar audience topic (size matters less than fit)

• Consistent recent publishing (a newsletter that went quiet 3 months ago won’t send you anyone)

• Signs of active growth

One honest limit: recommendation exchanges are most useful when you’re small and pick the right people to exchange. I’ve seen writers with 400+ recommendations still stuck at 2k subscribers. Usually two problems: exchanging with the wrong people, or gaming the algorithm so hard it’s working against them.

Recommendation exchange is a support system. Your newsletter is the product.

Level 2: How to Write Substack Notes That Actually Perform

Notes are where a lot of growth happens that most writers don’t notice until later.

Formulas are everywhere. Short sentence. Short sentence. Insight. Screenshot. They all work within constraints. The problem: no formula is universal. Copying someone else’s note style while you’re still finding your voice usually produces notes that feel like imitations.

The real work is personal. What format do your followers engage with? What topics pull them to reply? What do your best-converting notes have in common?

I spent months trying to find those patterns manually. Eventually I built tools to do the analysis for me. That’s what became QuickViralNotes and the Substack MCP.

The research confirmed what I suspected: I pulled 3,000 Substack notes from 9 AI creators I admire and ran them through Claude. The finding that surprised me most: the most-posted format turns out to be the worst performer. Every creator’s top notes had patterns specific to them.

That’s the data worth studying. Not a universal formula. Your own patterns.

The underlying practice:

• Publish consistently, even when you’re not sure notes will land

• Track which ones actually brought subscribers, not just likes

• Experiment with format and length deliberately, not randomly

Write from your actual experience. The notes that performed best for me were almost always specific. Real numbers. Real friction. A thing I actually tried and what happened.

Level 3: How to Write Substack Articles That Compound Over Time

This is the one most writers already know they should prioritize. And still underinvest in.

Good content is not just well-written. It’s well-connected. Writers who grow long-term write articles that reference their own older work, get linked to by others, and show up in search results months after publishing.

I got this wrong for a long time. My best article for a long stretch was something I wrote about RAG, then MCP, then Claude Code projects. Good articles. But I wasn’t linking them to each other. Wasn’t revisiting them. Wasn’t building the web.

What separates the writers who compound:

• Consistent voice across articles (readers recognize the style)

• Internal backlinks — reference your own work whenever it’s genuinely useful

• SEO-aware headings that match what readers actually search

• Articles that stand alone and also reinforce each other

You don’t need to do all of this perfectly from day one. You do need to start sooner than most writers do. The write-and-forget habit is hard to break once it sets in.

Up to here: everything you need to grow steadily and sustainably. These three levels, done consistently, can take you from 0 to 3k+ subscribers easily within 12 months.

What I’m going to show paid members next is the fast track. The same three levels, but with Claude doing the slow parts.

• Finding newsletter partners at scale.

• Generating and scheduling notes in batch.

• Keeping up with subscriptions and tracking article performance without switching tabs.

If you’re a paid member and you use Claude, this section alone earns back the cost of the subscription.

Upgrade to Premium

Inside: 3 complete step-by-step workflows, one per growth level, with exact Claude prompts:

• Substack Explorer + Claude — find newsletter exchange candidates in your niche in minutes, then get a ready-to-send DM drafted on the spot

• QuickViralNotes + Note Scheduler + MCP — extract notes from your own articles, schedule a week of posts in batch, all without leaving Claude

• Substack Article MCP — read your inbox, check article performance, and access paid subscriptions you follow, all in one prompt

• Each level with screenshots, videos, demos, use cases you can implement in 30 minutes.

Plus: DM template for newsletter outreach + note prompt pack — grab them at the end

Read more

I haven't been able to close the tab since. Half the time I'm delighted. Half the time I'm whispering yikes.

If you've followed my work, you know I've loved Cursor for writing and coding because it gave me one place to think. And when OpenClaw arrived, I went deep on its highest-level automation and self-learning capabilities for the same reason: nothing else could do that layer of work.

This is the first time Claude has felt like it might start collapsing both into one stack.

Not all the way.

But fast enough that I had to stop and re-evaluate my whole setup.

Four days in, here’s what I found.

What’s Inside:

• What is Claude Code redesign and why it suddenly matters

• What actually changed on April 2026 Claude Code desktop redesign: the old vs. new comparison that makes the thesis credible

• How Claude Code UI compares to Cursor right now: where it wins, where Cursor still leads

• What Claude Code Routines are: and how they compare to your own cron or OpenClaw at the capability level

• What OpenClaw tasks are replaced by Claude Code Routines: the three-way migration with real job examples

• Which Cursor features Claude Code UI still lacks

• How a non-developer gets the full value from Claude Code UI: including the Slack approval loop that runs with zero code

• What are the real bugs and limits of the new Claude Code UI?

• Where Claude Code is going next: and three things worth building now

What is Claude Code UI and why it suddenly matters

Claude Code UI is Anthropic’s redesigned desktop interface for Claude Code, shipped April 14, 2026.

The short version: it’s a full application layer on top of the Claude Code CLI, built around parallel sessions, project organization, and a cloud automation system called Routines.

On paper, that sounds like a nicer wrapper around the CLI.

It is not.

Why that matters becomes obvious fast.

For years, building with AI meant removing one kind of friction at a time.

The first friction was contextual.
Too many docs. Too many tabs. Too many files. You broke your own thought just to fetch the one thing the model needed. Coding tools like Cursor solved that beautifully. Not just as a coding tool, the whole workspace.

The next friction was access.
Even in one clean workspace, AI still could not reach the systems real work depended on: email, files, storage, tools, live data. MCP and the CLI changed that surgically.

Then came automation.
Not another dashboard. Not another brittle control panel. Not another login just to see if the workflow was still alive. Skills that self-evolve, running on their own. That’s where OpenClaw shines.

Each of the last few AI moments were a huge unblock from before.

1. Cursor: one workspace.

2. MCP + CLI: one AI reaching real systems.

3. OpenClaw: one workflow that keeps running.

Now, Claude Code UI + Routines: the first thing that starts pulling all three into one place.

That is the personal reason the redesign lands so hard. Not because it looks better. Because it feels like convergence.

And the strategic pattern is impossible to miss now. Anthropic keeps watching what builders value, then shipping it natively.

That’s not criticism. It’s a roadmap signal.

“Claude’s roadmap: collaborate with rivals, learn from their prompts and orchestration, match them, then replace them.”

The UI redesign isn’t a feature drop. It’s a cycle completing.

What actually changed on April 2026 Claude Code desktop redesign

The previous Claude Code desktop experience was a thin wrapper: one session at a time, basic file viewer, no project organization. The April 14 redesign is a ground-up rebuild. What shipped:

Session management:

• Sidebar showing all active and recent sessions, grouped by project

• Filter sessions by status (running, paused, complete), project name, or environment

• Drag-and-drop layout: reorder or resize the session list

In-app editing and execution:

• Integrated terminal (run commands without switching apps)

• In-app file editor (view and edit files from inside the Claude Code window)

• Rebuilt diff viewer for reviewing agent-proposed changes before accepting

Automation layer:

• Routines: cloud-hosted Claude Code sessions that run on Anthropic infrastructure, triggered by schedule, API endpoint with auth token, or 13+ GitHub events (PR opened, commit pushed, issue labeled, etc.)

• Remote edit from claude.ai/code/routines: no SSH, no local machine required

• MCP connectors that pre-wire tools into your routine at creation time

Output handling:

• HTML, PDF, and local-serve rendering built in

• Session URLs (shareable, though currently sometimes open blank; more on that in the bugs section below)

What the redesign was responding to:

The community had been building workarounds for everything above:

• Session management: tmux plus dashboards like siteboon/claudecodeui (a webUI literally called “Claude Code UI”), Ark0N/Codeman, and Stargx/claude-code-dashboard.

• Automation: stacks like OpenClaw.

• In-app editing: IDEs such as Cursor.

The April 14 redesign closed all three gaps in one release. Anthropic even shipped it under the same name the community had already given it. That’s unusual velocity.

The two tools under the most pressure here are obvious: Cursor and OpenClaw.

Start with Cursor.

How Claude Code UI compares to Cursor right now

Cursor and Claude Code UI are now solving some of the same pain.

• They both give you sessions.

• They both cut down the old tab-switching mess.

• They both let AI work live closer to the thing you’re doing instead of in a separate chat silo.

But Claude Code UI pushes that one step further.

Cursor still works one project window at a time. If you’re midway through one repo and want to jump to a different project, you open another window. More computer load. More visual clutter. More context switching.

Claude Code UI removes most of that. You create a new session, point it at a different working folder, and keep going in the same app. Best part: you can still see what all the other sessions are doing while this one runs.

That is the real UI gap between them.

Cursor is still the better editor. Claude Code UI is the better session manager.

Cursor still wins on the smaller surgical things:

• Inline diff-as-you-type edits: the autocomplete layer that rewrites code while you type, not after you ask

• Full-page file view with a repo-structured sidebar

• Raw editor speed for surgical changes

Claude Code UI now leads on:

• Parallel session management

• Cloud automation through Routines

• Project-level organization across multiple agents

• MCP-connected workflows that don’t need the editor open

The outcome-first comparison:

If your workflow is “AI helps me write code while I’m looking at it”, Cursor is still faster and smoother.

If your workflow is “I give AI a task and come back when it’s done” (or you’re managing multiple agents across multiple projects), Claude Code UI is the better home.

The session-vs-editor framing:

Cursor is editor-first. Sessions live inside files.

Claude Code UI is session-first. Files live inside sessions.

Once you internalize that inversion, the comparison stops feeling like “which is better” and starts feeling like “which is right for this task.”

But Cursor is only half the story.

The bigger shift is what happens once Claude leaves the editor and starts running on its own. That’s the part that puts real pressure on OpenClaw.

What Claude Code Routines are

Routines are cloud-hosted Claude Code sessions that run on Anthropic’s infrastructure.

• You write the instruction in natural language.

• You pick a trigger: schedule (hourly to weekly, plus custom intervals), an API call, or a GitHub event.

• Claude runs it with whatever MCP tools you’ve wired in.

Local vs Remote: when you click New routine, you choose Local (runs on your machine, needs it awake) or Remote (runs on Anthropic’s infra).
Remote is what makes this different from a cron job on your laptop. Pick Remote unless you specifically need local file access.

Plan limits (for routines hosted on cloud): Pro gets 3 runs/day, Max gets 15, Team and Enterprise get 25. Each Routine is a full Claude Code session, so steps burn tokens. Pro’s allotment gets tight fast. Max is the practical floor for anything beyond a handful of jobs.

It’s worth noting that local routines are unlimited for paid plans.

claude.ai/code/routines lets you view, edit, and create routines from any device. No SSH. No local machine. No waiting to get home to change a schedule.

That’s what makes Routines different. With OpenClaw, editing a job means SSHing into the server or connecting to the VPS. Remote edit is a genuine quality-of-life improvement, especially for non-developers.

Routines vs OpenClaw: the capability comparison

Both are AI agents on a schedule. The real difference is where they run and how far they reach. Routines are Anthropic-hosted, fast to ship, and edit-from-anywhere. OpenClaw is self-hosted, self-evolvable, and can chain with anything else you’ve built.

Here’s the capability-level view.

What the table says:

• Routines win on convenience, deployment speed, and remote editability.

• OpenClaw wins on depth, self-evolution, and no limits.

The migration question isn’t “move everything”. It’s about knowing which tier each job belongs to.

If you’ve spent a year building around Cursor or a cron stack like OpenClaw, the real question isn’t whether the redesign is impressive. It’s what you actually move, what you keep, and what breaks if you move the wrong thing.

I sorted my own 18 OpenClaw jobs in two days using a three-tier map:

• Cloud Routines for what runs clean on Anthropic’s infra,

• Mac launchd for what needs local files,

• OpenClaw for what needs self-evolution or multi-channel orchestration.

Twelve stayed self-hosted. The rest moved out, and none landed in the wrong tier.

Next: the three-tier migration I ran on my own stack, with every job named and the decision rule for each, plus the do-it-now toolkit, the non-developer recipe, and the honest-take bug list.

• The OpenClaw migration map: 18 jobs sorted in two days, with the tier decision rule on each

• The do-it-now toolkit: the 3-question test to sort your own automations into the right tier in 10 minutes, plus a copy-paste Slack approval loop you can have running today in 30 minutes

• The self-evolving experiments: 6 freed OpenClaw slots running self-improving, self-correcting, and cross-job memory patterns, now pointed at a kids’ language app, an investment scouting loop, and shared family access

• The Cursor concession ranking: which features close in 2026, which hold longer, so you can plan your year

• The non-developer playbook: routines and project tabs without writing a line of code

• The full “what breaks” list: 4 desktop bugs and 1 workflow gotcha I hit personally, 2 Routines bugs I hit personally, the two MCP issues everyone’s reporting that I haven’t, plus 4 performance fixes and 8 community UI issues with GitHub numbers

Plus: the forecast: where Claude Code is going next, and 3 things worth building now to compound on it.

Upgrade to Premium

What I kept on OpenClaw and what I moved to Claude Code Routines

When the redesign dropped, I had 18 active jobs on Oracle OpenClaw. Two days later, I had 12. Here’s exactly where everything went and why.

Read more

Anthropic released MCP — Model Context Protocol — in November 2024. By spring 2025, OpenAI, Microsoft, and Google had all adopted it. It became the industry standard for how AI connects to external tools

Before MCP, AI answered from memory. After MCP, it could connect to your files, your Google Drive, your Slack, your Notion, your calendar, anywhere your data actually lives.

Claude moved fast. Native integrations appeared directly in the app.

You’ve probably installed an MCP server by now. Maybe you followed a tutorial. Maybe you copied a JSON block from a post you bookmarked and pasted it into Claude or Cursor. It connected. Immediately, Claude could talk to your data you never thought to wire up yourself.

I got obsessed with MCPs the week they came out. I’ve tried dozens, kept a handful in my daily workflow, and built several of my own once I hit the limits of what was already out there.

A typical workflow I do after publishing an article involves a custom MCP I’ve built available to premium members, and it looks like this:

After using MCPs intensively day-to-day, I found the term “MCP server” still gets confusing.

Some run locally. Some live behind a URL. Some are easy to share as an npm package. Some need a one-click installer. Some need OAuth and browser sign-in.

Tutorials for one pattern do not translate cleanly to the others, and most do not tell you which kind you’re actually using and building in the first place.

I’ve built the Substack newsletter MCP, the Substack notes MCP, the Substack article MCP, the Gmail MCP, the crossposting MCP, the Build to Launch premium MCP for my paid subscribers. And a handful working locally that I never publicly shared. None of them were the same kind of server, because none of them had the same requirements.

After enough builds, the map became clear. This article is that map.

What’s inside:

• MCP Server Types: Stdio vs HTTP — what the two types across five patterns look like in practice, with examples you’ve already seen:

  • How Stdio MCP Servers Work — local script, npm package, or .mcpb installer

  • How HTTP MCP Servers Work — Bearer token or OAuth, connected via URL

• How to Build a Stdio MCP Server — the full stdio build in 8 verified steps, then three ways to ship it:

  • Run it locally — point Claude at dist/index.js, no publishing needed

  • Publish to npm — users install with npx, two live packages you can try now

  • Build a .mcpb installer — one-click install for non-technical users

• How to Build an HTTP MCP Server — same HTTP transport, two auth layers:

  • Bearer token auth — Next.js route with API key auth, deploy to Vercel

  • OAuth PKCE — browser sign-in, Cloudflare Worker build, three live OAuth MCPs you can connect now

• When to Upgrade Your MCP — how the Substack newsletter MCP went from raw Python script to npm package to full OAuth, and what that path tells you about when to upgrade

• How to Choose Between Stdio and HTTP MCP Servers — a decision tree: which transport, then which sub-pattern

• MCP Server Standards Changing in 2026 — four spec changes worth watching before your next build

• Stdio starter, Next.js HTTP starter, and Cloudflare OAuth starter templates in the Build to Launch resource library

🎁 Three starter templates are in the Build to Launch resource library. Access them at the end of the article.

Check out the library now

MCP Server Types: Stdio vs HTTP (and Five Ways to Use)

Every MCP server uses one of two transports: Stdio and HTTP. That’s it.

Everything else — npm packages, OAuth flows, Bearer tokens, .mcpb installers — is a distribution or authentication layer on top of one of these two.

How Stdio MCP Servers Work

Stdio MCPs run on your own computer. Claude opens them like you'd open an app, uses them to get what it needs, then closes them. You never have to think about them, they open and close automatically every time you chat.

Three forms it comes in:

1. Local script or interpreter — uvx, python, node. If the setup instructions told you to clone a repo or run a script, this is it. Many of these are also published on GitHub and available as npm packages.

2. npm package — if the docs said “install via npm” or the command starts with npx, it’s this. Someone published it so anyone can install it in one line. No cloning, no setup.

3. .mcpb installer — double-click and Claude Desktop installs it automatically. No terminal at all.

How HTTP MCP Servers Work

HTTP MCPs live on someone else's server, not yours. You connect once with a URL, the same way you'd visit a website. Nothing runs on your machine, and when the builder ships an update, you get it automatically without doing anything.

Two ways they handle your identity:

1. Bearer token — you paste a URL and an API key from the service’s dashboard.

2. OAuth — you click “sign in,” authenticate in a browser, and it’s connected. The native connectors that appear built-in to Claude Desktop — the ones where you just click to connect — are all OAuth MCPs.

You’ve just seen five ways AI can connect to external sources. Every one of those MCPs was built by someone (or company) who had domain resources they wanted to make useful.

That’s the real opportunity.

Just like puts it perfectly in his article. You've spent years building up your domain knowledge, and developing a system that works. An MCP packages it — your logic, your shortcuts, your way of doing things — so anyone can use it.

Your domain knowledge is the product. The MCP is how it ships.

That’s what we’re building next.

How to Use the Guide

Each pattern in this guide comes with four things:

The complete step-by-step build: every command, every file, every config, in order.

Full working code packet: every build includes the complete package.json, tsconfig.json, and source file. Download it and build on top of it.

A verification step after each meaningful command: a JSON-RPC call, a curl, or a compile check that confirms the step worked before you move to the next one.
Status: ✅ worked first try · ⚠️ worked after a documented fix · ❌ failed and abandoned

A build error reference at the end of each pattern: every failure point I hit, with the exact cause and the fix.

Three starter templates with local MCP and two hosted MCPs are in the Build to Launch resource library. Access them through the resources.buildtolaunch.ai.

Upgrade to Premium

Let’s start with the local MCP server and download the templates below.

Read more

But the friction shows up fast.

How do you turn a big desire into a clear question?
How do you get out of tab-stuffing mode and actually move the needle?
Which tool should retrieve, which one should synthesize, and what kind of data is worth collecting in the first place?
How do you know when you have an answer that’s worth acting on instead of just another plausible paragraph?

Those questions are not new. They existed long before AI. What’s changed is that AI makes them much easier to answer if you know how to route the work.

At the start of this session, I ran a quick poll in chat and asked what people currently use for research. The answers came back as combinations: Claude and Perplexity. ChatGPT and Google. Forums and communities. Almost everyone was already using multiple tools.

That was the point. The tools are already here. The harder part is building a process that turns vague research into clear, actionable answers.

This article walks through that process: how to identify the question, how to route it, and how to decide what to do with the answer once it comes back.

What’s inside:

• The 3 research situations everyone hits:

  • How to learn something from scratch

  • How to track down a specific answer

  • How to pressure-test an idea before you commit

• The 5-stage process for turning a vague question into something you can actually route, retrieve, and act on

• 3 live demos run in parallel:

  • “How do I make money with AI?” -> what the crowded market still reveals

  • “Where can I get the best deal on a second-hand car?” -> how a specific lookup returns a completely different kind of answer

  • “Is it a good idea to build a deal tracker?” -> how to get directional signal before you spend the next week building

• How the MCPs fit into the process:

  • Perplexity for retrieval

  • Build to Launch MCP for the repeatable research workflow members can use

• Live questions from the session:

  • How the MCPs work together

  • How accurate AI answers are

  • Where to store research

  • A scheduled-task example for handling data over time

• What to do this week:

  • One question to run through the framework yourself (with 30 ideas to get you started)

• Program context:

  • Jenny’s background

  • CPD certification details

• Session timeline with timestamps

🎁 Everything from this session is included in the Build to Launch resources: the slides, the full video with captions, the research brief and outputs from all 3 live questions, and a list of question ideas you can use to run the same process on your own work.

The 3 Types of Research Questions

Before the live demo, I named the three situations most research questions fall into. This matters because the shape of the question changes what a useful answer looks like.

Type 1: Learning something new. You do not know enough yet to ask a sharp question. Example: you want to understand SEO, AI monetization, or how agents work before going deeper. The goal here is foundation.

Type 2: Data collection. You know what you need and now you need specific, current information. Prices. Listings. Rates. Providers. Tools. The goal here is not broad understanding. It is finding the right data fast.

Type 3: Idea validation. You have a thesis and want enough signal to decide whether to keep going. You are not looking for perfect proof. You are looking for enough evidence to invest the next week or redirect.

These question types can blur together. A question that feels like learning may actually be a decision question, and something that sounds complex may just need a straightforward lookup. Once you name the question type, the rest gets easier.

The 5-Stage Research Process

The framework itself is simple. It is not tied to one tool. It is just a way to stop treating every research question the same.

If you want to see how this process shows up in different kinds of work, here are three examples:

• Researching visual product covers without a design background

• Researching what was actually true about Substack Notes performance

• Researching whether an app idea was worth building before writing code

Stage 1: Refine. Turn the vague desire into a real question.

Stage 2: Lens. Decide whose perspective you are borrowing.

Stage 3: Retrieve. Go to the source that actually holds the data.

Stage 4: Synthesize. Force the results into a structure you can compare.

Stage 5: Decide. End with one next move, not five ideas.

That was the framework. Next, I ran all three question types live so you can see how the same process produces completely different outputs depending on the question.

In the live demo, I also use reusable research skills like idea-research and data-curator inside the Build to Launch MCP so I am not rebuilding the same research process from scratch each time.

The Live Demo

Read more

Within days: screenshots of tasks completing from phones, workflows that used to take an hour finishing in minutes, threads with hundreds of reactions. People claiming they’d automated their entire morning routine. That their Mac was finally working for them while they were away. That this was the thing they’d been waiting for.

The hype was immediate. The transformation is real. It earned every bit of it.

Reactions were split hard: breakthrough for some, impossibly frustrating for others, nothing new for the rest. I had a theory why, so I went and tested it. 18 tasks that would change how a one-person operation runs.

My results are genuinely split: some exceeded what I thought was possible, some are still getting there.

But the thing that struck me most wasn’t any specific result. It was what Dispatch is actually standing on.

Claude has spent a year quietly building the stack: MCPs, Claude Cowork, Claude in Chrome, skills, plugins, Claude Code, Claude Routines. Each one looked like a separate feature. Together, they’re the reason any of this works at all.

What’s Inside:

• What Dispatch is built on — and why the demos suddenly make sense — the five layers underneath, what each one does, and what breaks without it

• What this changes for a one-person business — the real shift, the OpenClaw tension, and the few findings that changed my view fast

• 18 tasks, one complete pack each — onboarding, warm-ups, real work, and the failures worth knowing before you trust this

• The prompt structure that prevents most stalls — the one line and task-shape that made the biggest difference

• The stack — what lives where — which mode owns which job so you stop overlapping tools

What Dispatch is built on — and why the demos suddenly make sense

Here’s what each layer does, why it matters, and what breaks without it.

MCP — The efficient communication layer

• What it is: Connectors that give Claude direct API access to Gmail, Calendar, Notion, Substack — no browser navigation required

• Why it matters: When an MCP exists for the service, Claude uses it directly instead of opening a browser and navigating manually. Faster, fewer steps, fewer failure points.

• How to trigger: Install in Claude Desktop settings, connect the service. Claude picks it up automatically when the task involves that service.

• Without it: Claude has to open a browser, navigate the UI, and work through the page manually. More steps, more failure points.

Claude in Chrome — DOM access without the OS screenshot loop

• What it is: A browser extension that gives Claude direct access to the page’s DOM structure — reads and interacts with web content without taking OS-level screenshots

• Why it matters: For browser-only tasks, it’s more precise than Computer Use because it reads the page directly rather than interpreting a screenshot

• How to trigger: Requires installing the Chrome extension first — not enabled by default. Once installed, specify the URL in your task prompt and Claude reads the page through the extension.

• Without it: All browser tasks fall back to the Computer Use screenshot loop. React forms will consistently fail.

Claude Desktop Control — The GUI hand

• What it is: Claude sees your screen and controls your mouse and keyboard — real automation of native desktop apps via screenshot-based Computer Use

• Why it matters: The only way to reach software that has no API and no browser version. Anything that lives on your Mac and nowhere else.

• How to trigger: Built into Claude Desktop. Send a Dispatch task that requires GUI work — Claude takes over automatically.

• Without it: Native apps are unreachable. Finder, local software, anything outside a browser won’t work.

Skills & Plugins — Nice to have, not required

• Skills are markdown files Claude reads before a task starts — your workflow rules, preferences, context.

• Plugins are MCP-connected services with their own communication interface.

Neither is required to use Dispatch, but both make it noticeably more capable.
Without skills, Claude starts each session without context.
Without plugins, it falls back to browser navigation for external services.

Claude Cowork — The session hub

• What it is: The session environment where Dispatch tasks run — a separate context from Claude Desktop, with its own filesystem mount and tool access

• Why it matters: Without a live Cowork session, Dispatch has nowhere to land. The task arrives on your Mac but can’t execute.

• How to trigger: Open the Claude app on your phone → Cowork tab → describe your task → send.

• Without it: You can’t trigger any of this remotely. You’re back at your desk.

Claude Code — The coding buddy

• What it is: Claude’s coding environment with terminal access, file read/write, and git operations — runs as a separate session

• Why it matters: For code-heavy tasks, Code sessions use direct tools rather than screenshots, more reliable for anything involving files, code, or git

• How to trigger: Start a Code session from Claude app, or Dispatch a task that requires code or file work.

• Without it: Code and file work falls back to the screenshot loop. Slower and less precise on anything technical.

How to enable Dispatch

Enable Dispatch: Open Claude Desktop app → click your profile → Settings. Toggle on: “Keep computer awake”, “Browser Use”, “Computer use”, “unhide apps”. Grant access to files and screen recording.

From Claude Desktop: Open Claude Desktop app → click the Cowork tab. This is where you trigger tasks from the desktop or send them from your phone.

From Claude Code: Open Claude Code → start or connect a Code session in terminal (e.g. claude) → /mcp → select “computer-use” under “Built-in MCPs”. Dispatch tasks route here automatically when they involve code, files, or git.

Settings worth checking before your first task:

• macOS permissions: System Settings → Privacy & Security → Screen Recording → Claude Desktop ✓ and Accessibility → Claude Desktop ✓. Both are required for Computer Use. Without them, any task that touches the screen or GUI fails silently.

• Desktop Commander enabled in Claude Desktop settings (Connectors tab)

• Claude in Chrome extension installed (Chrome Web Store) if you want browser tasks

• MCPs connected for any external services (Gmail, Notion, etc.) you want Claude to reach directly

• Sensitive apps blocked if needed: Settings → Cowork → Blocked Apps (e.g. 1Password, banking apps)

That’s the infrastructure. Now we can explore what it actually changes.

What this changes for a one-person business

Leave your laptop home. Your phone is the interface. Whatever is on your Mac, files, apps, git repos, browser tabs… Claude can reach it while you’re away.

You can be at a coffee shop and have Claude close 25 browser tabs. At the gym while a morning brief builds itself. On a phone call while Claude merges the git branches you’ve been avoiding. The Mac keeps working while you’re not sitting in front of it.

For a one-person operation, that changes the math fast.

The OpenClaw question matters here. I’ve been running OpenClaw since March for the jobs that need to run while my Mac is off: newsletter scanning, content research, recurring ops. Dispatch needs your machine awake. OpenClaw runs on a server and doesn’t care what time it is. The question going into testing was whether Dispatch, with everything it’s now standing on, starts closing that gap.

A few things changed my view fast:

• Claude can check multiple Gmail inboxes in one prompt if the MCP stack is set up correctly.

• The content research pipeline was the task I was most excited about.

• Computer Use works, but on my hardware I’d call it about 60% reliable, useful, not blindly trustworthy.

Next: the full breakdown, every task tested across all 5 modes, with real times, exact prompts, the stack used, and my verdict on each. One task, one complete pack.

Upgrade

18 tasks, one complete pack each

Each task is a complete pack: mode, time, result, prompt, what happened, where it’s useful, the catch, and my verdict. Prompts are reconstructed from session notes — exact copy-paste templates in the Prompt Pack.

Before you send your first task — onboard Claude to your computer

Most people open Dispatch and immediately throw a real task at it. Don’t. The first session should be orientation, not work.

Send this prompt first:

Read more

I had been publishing Gumroad products for months. More products meant more cover page decisions. And the same question kept coming up:

Is this actually good, or does it just feel good because I haven’t seen enough of the market?

My covers were converting. But are they working good? Compared to what? I had no baseline.

Usually if you want to know whether your cover is good, you open a few competitor pages, look around, and go with your gut.

So I did that. I opened tabs. Lots of them.

By session two, I could not remember what tab 8 looked like. I was screenshotting the covers that caught my eye last. Copying a few prices. Leaving with a vague sense of what was out there.

Then making decisions based on that.

My cover felt right because it matched the vibe I remembered. My price felt competitive because it sat somewhere in the range I still had in my head.

Every one of those decisions came from a compressed memory of the market. Not the market itself.

Someone in r/AIAssisted said it better than I could:

“My brain kept overweighting the last 20 ads I saw. I needed a way to hold the whole market in one view.”

What changed things was not more browsing.

It was seeing the whole market at once, then seeing what that changed in me. I used that same logic when testing 8 AI coding tools, for studying the Substack notes performance, and whether my app was worth building.

What’s inside:

• How AI research shows you the whole market at once — the video, the board, and why tab-based research fails you every time

• What Perplexity MCP + Claude does to your research process — the 4 layers of AI competitive research and why orientation is the one that matters

• What 177 Gumroad products reveal about covers, pricing, and trust — the first pattern that showed up across every platform

• How to spot gaps in your own product using competitor data — what the board surfaced that individual product pages never would

• The exact Perplexity MCP + Claude competitive analysis workflow — the prompt, the board builder, and parallel research across 5 platforms

• How to set up Perplexity MCP for an autonomous research loop that runs beside you

• How to use Claude in Chrome to collect data without manually switching tabs

• The exact prompt, scripts, and research board — everything to run this yourself, including the Claude Chrome workflow for cover analysis

🎁 If you want to skip rebuilding this from scratch, the exact prompt, scripts, and the same HTML research board shown in the walkthrough are included below for paid subscribers.

How AI Research Shows You the Whole Market at Once

What I mean by “seeing the whole market at once” is exactly what is shown in this video.

Within 30 minutes, it browsed through the websites for me, took enough images and screenshots, and consolidated everything I need into a beautifully scored HTML page: one where I can see everything at once.

Human short-term memory only holds a small number of items at once. So when you study 50 competitors by switching tabs, your brain quietly turns 50 inputs into 6 or 7 remembered fragments.

But this board fixed that part instantly. Not by making me smarter. Just by holding the full set in view at the same time.

What Perplexity MCP + Claude Does to Your Research Process

I thought the first benefit would be speed.

It was. But that ended up being the least interesting part.

The real change happened in four layers.

Layer 1: speed

One AI conversation can scan a range of products much faster than you can by hand. That matters. It gets you to the board quickly. But that is table stakes now.

Layer 2: delegation

Once I could send a task to an agent and keep thinking while it worked, my role changed. I was not the one doing all the collection anymore. I was the one deciding where the collection should go next.

That sounds small. It is not.

Once you can send a task to an agent and keep thinking while it works, your role changes. You stop being the one doing all the collection. You become the one deciding where the collection goes next.

It moves you from researcher to director.

Layer 3: the loop

The system did not just return information.

It returned information, I reacted to it, it fetched more, I reacted again, and the next move became obvious from the conversation.

That is a different feeling from using AI like a vending machine.

It is closer to debriefing with someone who already did the first pass for you.

Layer 4: orientation

This was the unexpected part.

Within one session, I had the shape of a market in my head that I had never studied properly before. I could see what clustered, what looked strong, what looked weak, where prices concentrated, and which products were winning for reasons that had nothing to do with beauty.

You usually think you earn that kind of orientation slowly.

Here it arrived early.

That is what made the process feel almost wrong at first. It was too fast to feel like real learning.

But it was real learning. It was just front-loaded.

What 177 Gumroad Products Reveal About Covers, Pricing, and Trust

Before my last Gumroad launch, I built five boards: Gumroad, App Store, Amazon KDP, Etsy, Creative Market. 177 products. Three hours.

The first pattern that jumped out had nothing to do with refined design.

Personal photos beat professional-looking covers. By a lot.

Across 52 Gumroad products, creators who used their own photo on the cover had stronger sales signals than products with cleaner, more polished, photo-free covers.

Not a little stronger.

Obviously stronger.

And the photo did not need to be professional. One of the better-selling products used what looked like a phone selfie.

Technically weak.

Commercially strong.

The point was not beauty. The point was trust.

A face signals accountability. You know who made the thing. You know who you are buying from. That is a different signal from “this looks designed well.”

That is the kind of pattern I would never have trusted if I had seen it one product at a time.

Side by side, it became hard to ignore.

And that was just the first reveal.

The board kept surfacing things like:

• clear “what’s inside” titles beating beautiful but vague ones

• outlier products selling because of niche specificity or audience, not design quality

• pricing clusters creating obvious gaps once the whole range was visible

Those are not individual observations. They are constraints.

And once you can see constraints, you stop guessing.

How to Spot Gaps in Your Own Product Using Competitor Data

This is where the article stopped being about competitor research and started being about self-awareness.

I do not come from a design background.

When I see something that looks good, I know it looks good. But I have not had the vocabulary for why.

The board changed that.

It showed me that the strongest products were not all “beautiful” in the same way. They tended to split into two buckets:

1. Raw human: face forward, personality forward, trust as the main signal

2. Bold/direct: no softness, no hedging, the statement itself is the design

By accident, I had already been making products in the second category.

That was one reveal.

The second reveal was harsher and more useful.

The audit pointed to a specific gap: the gradients on my covers were making them feel cheaper than the structure deserved.

That changed the question.

The question was no longer “do I have taste?”

The question became “what exactly is making this look mid-tier, and what is the fix?”

That sent me into a design education session I was not planning to have.

I ended up experimenting on this product with a lot more styles to find the one that speaks to my vibe.

Suddenly I was learning first principles.

What does restraint signal?

Why does typography carry authority?

Why does one aesthetic look expensive and another look generic?

I especially loved these 2 examples:

That sequence mattered.

First, broad exposure.

Then, self-comparison.

Then, vocabulary.

Then, looking again with different eyes.

Then, a specific next move.

That is why I keep saying this was not just a research workflow.

It was a learning workflow.

And the most important part is this: everyone comes out of that learning sequence with a different slice.

For me, the slice was design execution.

For someone else, it might be pricing. Or the realization that their category is far less crowded than they thought. Or the realization that the titles that win are all much more literal than the ones they wanted to write.

The board does not hand everyone the same generic lesson.

It reveals what is missing for you.

Once you see it, you cannot unsee it.

Fragmented Research vs. Decision-Grade Research: What Changes Before Launch

This is why I do not think the right contrast is research versus doing the work.

The real contrast is fragmented research versus decision-grade research.

The first one leaves you with vibes.

The second one leaves you with a constraint, a direction, and often one uncomfortable but useful truth about your own work.

That is the frame I care about for Month 1 of the Practical AI Builder Program.

Not research as homework.

Research as the thing you run before any meaningful decision so you can stop building from partial memory.

What’s Next:

• The exact competitive analysis workflow, step by step

• How I set up Perplexity MCP to run searches through my subscription instead of burning extra tokens

• How I set up Claude in Chrome so it works from both Claude Code and Claude Desktop

• The prompts I used, with screenshots and a video walkthrough

• The complete HTML research boards — so you do not have to rebuild the collection setup yourself

Upgrade

How to Run Competitive Research With Perplexity MCP and Claude in Chrome

This is the full step-by-step version.

The free part showed you why this changes decisions. This part shows you exactly how to run it.

Before you start: set up your two tools

The workflow uses two AI tools alongside the scripts: Perplexity MCP for live research, and Claude in Chrome for browser visits. Set both up once now, then follow the steps below.

Read more

AI has so much to offer, and it’s very easy to get lost. New tools launch every week. Every announcement creates a little more urgency, a little more noise, a little more catching up to do. In the meantime, the actual problem you’re sitting with is still there.

This is where practical AI building becomes useful: you stop chasing what’s new and start solving what’s real.

How the program works

One live session per month. One real problem. One thing you build.

Each 60-minute session follows the same structure:

• 15 min — Context and tools. I introduce the problem, the first principles underneath it, and the tools we’ll use. No prior reading required.

• 30 min — Live build. I build it in front of you — real setup, real workflow, real decisions as they happen. You see the thinking unfold, then take it wherever makes sense for you.

• 15 min — Discussion and Q&A. Open discussion on what we just covered, questions that came up, and how to take it further in your own work.

You leave each session having already started. No prep required, no blank page to stare at afterwards. Between sessions, the resources keep coming: recordings, prompts, configs, frameworks, and follow-up materials, all collected at resources.buildtolaunch.ai. Optional office hours are available if you want to go deeper on applying what we covered to your specific situation.

First session: Friday, April 10, 2026 at 12pm ET / 9am PT / 5pm UK. Sessions run the second Friday of each month.

What we cover

• April — Research: Find what you need across tools without losing your mind.
  ↳ Month 1 recap: How to Do Research With AI Effectively
  You build a research brief using 3+ AI tools.

• May — Connection: Stop copy-pasting between tools and build a pipeline that flows. You build a working pipeline with 2+ tool connections.

• June — Building: Go from idea to a live URL without writing code. You deploy a landing page or app at a real URL.

• July — Content: Create something that sounds like you, not AI. You write a content piece about something you built.

• August–March: Testing, governance, automation, extending your builds, distribution, orchestration, iteration, and your capstone project.

The tools adapt as better ones come along. The thinking stays the same.

What you get

• 12 monthly live sessions (recorded if you can’t make it)

• My actual setups, prompts, and configs, the infrastructure behind my builds

• Community discussion with other builders throughout the year

• Peer feedback on what you’re working on

• Certificate of Completion from Build to Launch when you finish your capstone

Pricing

Included in the Build to Launch paid subscription. No extra cost.

If you’re already a paid member, you’re in. If not, upgrade here.

Upgrade here

Common questions

Do I have to commit to 12 months?
No. Show up for what’s useful to you. Sessions are recorded and each month is self-contained. If you join for 3 months, take what you need, and run with it on your own, that’s a completely valid outcome. The program is designed to give you methodology you can apply long after the sessions end, not to lock you into a schedule.

I’m not technical. Is this for me?
No coding required. No technical background needed.

The tools we use have no-code interfaces, you write instructions, not code. The skill this program builds is knowing what to ask for and how to evaluate what you get back. That doesn’t require a technical background.

I happen to be technical, but 80% of what I’ve built had nothing to do with code. I didn’t know how to launch a Gumroad product. I didn’t know how to publish on different platforms. I didn’t know how to put together free resources people would actually want. I didn’t know how to sell, how to write consistently, or how to create images. Most of what I’ve built lives in areas where I had no idea what I was doing, just curiosity and the need to move forward.

The hesitation is the starting point. AI gets you past it. That ability compounds over the next year, five years, ten years.

What if I don’t know what to build yet?
That’s what Month 1 is for. Research and ideation. You’ll start with a small research project and see what interests you. The capstone doesn’t have to be decided now, you have 12 months to figure it out.

What’s the time commitment per month?
1 live session (about an hour) + optional office hours + however much time you want to spend building. Some people will spend 2 hours, some will spend 10. You control the pace.

Do I have to attend live?
No. Live sessions are great for real-time feedback and community, but recordings are available if you can’t make it. All materials are shared async, so you won’t miss anything.

What tools do I need?
Whatever you already use is a fine starting point. This program isn’t tied to any specific tool, we work with whatever makes sense for what you’re trying to build. Most AI tools have free tiers, so you can get started without spending anything. I’ll share what I’d reach for each month and why, but you adapt from there. You don’t need to buy anything before Day 1.

Do I have to ship something every month?
Absolutely not. This program is here to move you forward, not burden you with a pace that doesn’t fit your life. Some people will ship something every month. Others will go deep on two or three things that matter most to them. Both are fine. Quality always matters more than volume, I ship products from time to time, not on a fixed schedule, and what counts is that each one means something. The goal is that you end up working on what matters most to you, not keeping pace with a checklist.

What’s the capstone project?
Whatever format makes sense for your work: an app, a digital product, a research report, an automation system, a content system, or something else entirely. The goal is to ship something real that solves a real problem. I’ll help you figure out what that should be as we go.

What if I fall behind?
Each month is self-contained, there’s no “you must finish Month 3 before Month 4” rule. Build what matters to you, skip what doesn’t. Catch up with recordings whenever it makes sense.

Can I join mid-year?
Yes. Each month stands on its own, and earlier sessions are available as recordings. Join when it’s right for you.

Can my company pay for this?
If you want to expense your Build to Launch subscription, I have email templates you can use to request reimbursement from your employer. Reply and I’ll send them over. I’m also a CPD-verified trainer (verification: 789656, verify at thecpdregister.com), which may help with your reimbursement request.

If you’re interested in bringing this to your team as a group training, reply and let’s talk, that’s something I’m exploring for later in 2026.

Is this program CPD-accredited?
Not yet. I’m a CPD-verified trainer, but the program itself is not currently CPD-accredited. If enough participants need that, I’ll pursue it.

Will I get a certificate?
Yes. You’ll get a Certificate of Completion from Build to Launch when you finish the program and complete your capstone. It could be an app, automation, workflow, digital product, or whatever you shipped.

Questions not answered here? Reply to any post or message me directly.

Why now

The builders who develop this reflex early will have a significant advantage over the next few years. They are those who stop chasing tools and start with practical AI building. Not because they know more, but because they can move faster, with less friction, on problems that actually matter to them.

You already use AI. This is the year you make changes with it.

Upgrade

When Anthropic shipped Claude skills, the AI builder community moved fast.

Not prompts anymore. Not system messages. A real named instruction layer — invokable, composable, loadable on demand. Skill counts climbed into the hundreds. Community repos got shared. Template packs appeared.

Most of them are silently broken. Nobody can tell.I ran the same kind of structured evaluation across 8 AI coding tools — the 3-stage build audit shows what 'silently broken at Stage 1' looks like in build output.

“[Claude] still loves to ignore [the skill] and live it as if it wouldn’t be worth paying attention to at all.” — u/Glittering-Owl-1326, r/ClaudeAI

“I just had Claude set up my system to load them in demand, but they’re all loading at once and now Claude wants to turn them into hooks with trigger phrases, which is a total pain in the ass.” — u/marcopaulodirect, r/ClaudeAI

“I have rules listed in User rules and project-level rules. But models just ignore them — often even when I specifically tell them to use rules — they confirm they can see them.” — Andrii Stupak, Cursor Community Forum

73% of 214 community Claude skills scored below 60/100 in a 2026 audit. Most failed silently. No error message. Just slightly wrong output.

The instinct every time: add another skill to fix it. Which is exactly how you make it worse.

That was what happened in my setup: one for SEO, one for brand voice, one for social notes, one for research, then products, product building, content creation, article, communication, coding, and release workflow…

Six months later, I got 59 broken references pointing to files that had been moved, renamed, or deleted. 20 skills no agent had ever called. Written carefully, completely invisible. 30 duplicate definitions, two versions of the same doctrine diverging without a signal. A 1,239-line legacy command still running alongside the current system, with nothing to flag the conflict.

My AI wasn’t ignoring my skills. It was reading broken paths and getting nothing, silently.

Weeks of cleanup later, I’m finally satisfied with 10/10 reference integrity, 10/10 filesystem consistency, 10/10 single-source architecture. Output consistent for the first time in months, not because the model changed, but because it could finally read what I’d written.

What you’ll go through with me:

• Skill, Command, or CLAUDE.md: What Goes Where — the decision most people skip and why getting it wrong compounds everything else

• The Two Rules That Prevent Skill Sprawl — the folder shape and scope rule that stops silent divergence before it starts

• How Skills Break Without Telling You — five violation types that degrade AI output with no error message

• My actual audit from 192 files — real violation counts, what each finding looked like, including the naming disaster I didn’t catch until a script showed me

• The complementary-vs-duplicate test — the 10-word check that tells you whether two skills are doing the same job or silently fighting

• The .claude architecture template + claude skills auditor — grab them at the end

Hi, I’m Jenny 👋
I build AI systems and tools, then share how I did it. AI builder behind VibeCoding.Builders and other products with hundreds of paying customers. See all my launches →

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

• Claude Onboarding: How to Set Up Claude Code

• Best Claude Code Plugins, Tested

• Best Claude Code Prompts

Subscribe now

Skill, Command, or CLAUDE.md — What Goes Where

Most guides say: put your instructions in CLAUDE.md. Or: write skills. Or: use commands.

Nobody tells you when to use which one. So you default to wherever you started. Pile everything there. And eventually wonder why Claude stopped listening.

Three containers. Three different jobs.

CLAUDE.md: what’s always true

What it’s for: Rules that apply in every single conversation without exception.

“Use brand voice.” “Never commit directly to main.” “Reference docs live in /docs.” Instructions that should never switch off.

What goes wrong: People put conditional logic in CLAUDE.md.

“When writing articles, do X; when editing for SEO, do Y.” That logic is job-specific. It belongs in a skill. CLAUDE.md can’t turn itself off based on context, so those conditional rules run in every conversation, including ones where they have no business running.

Why it causes trouble: The file bloats.

Each new conditional adds more lines. Past 300 lines, the concrete rules start getting buried in principles and guidelines. Past 500 lines, community research in r/ClaudeAI consistently reports accuracy drops noticeably.

At that point you’re not giving instructions, you’re creating noise that competes with everything else.

A skill: for a specific type of work

What it’s for: Instructions that only apply when Claude is doing a specific job.

One skill, one job, something you could describe in 10 words. The full skill content only loads when the skill is invoked, so it doesn’t pollute every other conversation.

What goes wrong: Two things.

First, people write long, vague descriptions that don’t front-load what the skill actually does. So Claude never knows when to trigger it. The official spec truncates descriptions at 250 characters in the skill listing; anything longer gets cut. If your key use case is buried in sentence three, Claude never sees it.

Second, people duplicate skills across locations without realizing it, so Claude loads conflicting instructions depending on which path a command happened to reference.

Why it causes trouble: A skill with a bad description is invisible.

Claude can’t match it to the right moment, so it never loads, your carefully written instructions are never read. A skill with a duplicate is unpredictable. You edit one version. The other keeps running.

A command: what you invoke directly

What it’s for: Workflows you trigger on purpose at a specific moment: /article-prep, /run-audit, /deploy.

A command orchestrates: it calls skills, sets context, moves through a checklist. The difference from a skill is intent.

A command is something you initiate. A skill is something Claude enters when the work calls for it.

What goes wrong: By default, Claude can auto-trigger any skill when it decides the context is relevant.

Most of the time that’s fine. For workflows with side effects: structural changes, deploys, audits — it isn’t. Without disable-model-invocation: true in the frontmatter, Claude might decide to run your skill because your question sounded architecture-related.

Why it causes trouble: I had a file called collect-article.md (a specific command) and a folder called article-collection (the entire skill system for collected articles) sitting side by side. Similar names, completely different jobs. Claude would invoke either one depending on the session. The naming collision was bad.

The silent auto-triggering made it worse, I had no idea which one had actually run until the output was wrong.

The decision in practice

Does this apply to every conversation in this project?
→ Yes → CLAUDE.md

Is this a workflow you invoke directly (slash command)?
→ Yes → Command in .claude/commands/

Is this a specialized mode for a specific type of work?
→ Yes → Skill in .claude/skills/{name}/SKILL.md

Anthropic has since merged the “skills” and “commands” concepts, the official docs now treat them as equivalent. If you’re reading older guides and finding them contradictory, that’s why. The structural rules below apply regardless of what the docs call the containers.

There’s considerably more to the skill spec for those who want it: subagent forking (context: fork), path-scoped activation, effort levels, tool restrictions, lifecycle hooks, and plugin-style distribution for teams. For day-to-day content and build work, the three containers above handle 90% of what you’ll actually need. When you’re ready to go deeper, the official skills reference has it all.

The Two Conventions That Prevent Skill Sprawl

Both conventions enforce the same underlying principle:

Single Source of Truth.

Every piece of doctrine has exactly one authoritative home. When two files both claim ownership of the same job, Claude picks whichever has the most positional weight. You never see which one won.

Most skill problems trace back to ignoring one of two conventions. Once you see them, you can’t unsee them.

Convention 1: Prefer a folder over a flat file

What’s correct: A skill lives in its own folder with SKILL.md as the entry point.

.claude/skills/humanize/
├── SKILL.md          ← entry point (required)
├── reference.md      ← doctrine (optional)
└── examples.md       ← judgment examples (optional)

What goes wrong: People create flat files instead — humanize.md directly in skills/. Claude reads them fine. Nothing breaks immediately.

.claude/skills/humanize.md   ← works today, causes problems at scale

Why it causes trouble: A flat file has nowhere to grow. It can’t reference supporting docs cleanly. It can’t hold examples separate from doctrine. So it balloons, 300 lines, then 600, then 800. At that point it either stays as one unmanageable blob, or someone splits it into two flat files that immediately start diverging. Nothing signals the divergence.

Two versions of the same doctrine, both active, producing different output depending on which path a command happened to reference. That’s what the 30 singletons in my audit were.

The folder creates a contract: one stable entry point, everything else in service of it. The path humanize/SKILL.md never changes regardless of how much the skill grows.

Convention 2: Root-level means cross-system. Nested means system-scoped.

This is my own organizational convention, not an official Claude Code requirement, but it’s the one that’s saved me the most confusion.

What’s correct: Shared skills live at the root of .claude/skills/. Skills that belong to one system live nested inside that system’s folder.

• .claude/skills/humanize/SKILL.md — any command, any workflow, any other skill can call it

• .claude/skills/article-creation/skills/intro-system.md — internal to the article-creation system; other systems shouldn’t route to it

What goes wrong: People put system-specific skills at the root level because it feels simpler. Or they put broadly applicable skills nested deep inside a system because that’s where they first needed them.

Why it causes trouble: A root-level skill signals “broadly applicable.” If it isn’t, other commands start referencing it when they shouldn’t. You get unexpected cross-system dependencies that are invisible until they produce wrong output.

A nested skill signals “internal component.” If it’s actually shared, commands in other systems can’t find it cleanly, or they create their own duplicate that immediately starts diverging.

When three similar skills can coexist without conflict

My setup has three skills all in the same domain: humanize, brand-voice, writing-coach.

A fast scan might flag them as duplicates.

They’re not, they have different verbs, different activation stages, zero overlap. Three jobs. Three activation points. They never compete because they never activate at the same stage. The full framework for distinguishing complementary from duplicate is in The Complementary-vs-Duplicate Mental Model.

Duplicate looks like: two files both describing how to write an article, different instructions, neither one deferring to the other. This is the same single-source-of-truth problem that breaks any shared documentation system. I had exactly that. Fixing it meant picking one as canonical and deleting the other.

Knowing the rules is one problem. The harder one: most setups are already breaking them, and nothing tells you.

Three Architecture Patterns

Before the conventions can do their job, there’s a bigger decision most people never consciously make: how do you want your skills to relate to each other as a system?

Three patterns exist. Each one changes what counts as a violation, and what breaks silently when you get it wrong.

Option A — Monolithic orchestrator.

.claude/skills/
└── article-creation/
    ├── SKILL.md              ← orchestrator (the only entry point)
    └── skills/
        ├── write-draft.md    ← internal reference, not invocable
        ├── write-intro.md    ← internal reference, not invocable
        └── seo-pass.md       ← internal reference, not invocable

What it’s for: One top-level skill owns all sub-steps as internal reference files. The orchestrator loads them selectively. Nothing is individually invocable. Works when the workflow is linear and you always run it front to back.

What goes wrong: You need to fix one sub-step without running the whole workflow. You can’t — everything routes through the orchestrator. So you duplicate the sub-step as a standalone skill at the root level, and now two versions of the same doctrine coexist with nothing flagging the split.

Why it causes trouble: Silent divergence. The orchestrator keeps loading the original. The new standalone loads in other contexts. They drift apart over weeks. Neither version knows the other exists.

Best for: Tightly coupled workflows where the steps always run in sequence and you rarely need to call one piece in isolation.

Option B — Modular individual skills.

.claude/skills/
├── write-draft/
│   └── SKILL.md             ← independently invocable
├── write-intro/
│   └── SKILL.md             ← independently invocable
└── seo-pass/
    └── SKILL.md             ← independently invocable

What it’s for: Every step is its own independently invocable skill at the root level. No orchestrator. You invoke each piece directly and compose them as the work calls for it.

What goes wrong: The root level fills up fast. Without a naming convention, write-intro, write-summary, and write-cta look identical in the slash menu. You lose track of what’s current, what’s deprecated, what’s article-specific vs. general-purpose.

Why it causes trouble: Orphans — skills nobody calls because nobody can find them. Orphan files are one of the highest-frequency violations the auditor surfaces.

Best for: Non-linear workflows where each step has genuine standalone value and you want maximum flexibility over how to combine them.

Option C — Thin orchestrator + invocable modules.

.claude/skills/
├── article-creation/
│   └── SKILL.md             ← orchestrator (routes to root canonicals)
├── s-atl-write/
│   └── SKILL.md             ← root canonical, independently invocable
├── s-atl-intro/
│   └── SKILL.md             ← root canonical, independently invocable
└── s-atl-seo/
    └── SKILL.md             ← root canonical, independently invocable

What it’s for: The orchestrator handles the full workflow. Each module is also independently invocable when you need to fix just one piece in isolation. Modules follow a namespace prefix — in my setup, s-atl-write, s-atl-bio, s-atl-seo — so they group visibly in the slash menu and don’t get lost among unrelated skills.

What goes wrong: The orchestrator’s spec table and the root-level module drift apart. Someone updates the module at the root. The orchestrator still references the old path. Claude reads the orchestrator, follows the stale reference, and loads the outdated version.

Why it causes trouble: Broken references — the highest-impact violation type. The fix is strict: the orchestrator’s spec table must always point to the root canonical. The root module is the single source of truth. If you edit the module, you do not also edit an internal copy.

Best for: Complex workflows where you sometimes need the full run and sometimes need to fix just one piece — and where discoverability in the slash menu actually matters.

The two conventions above apply within whichever pattern you choose. But if you try to apply them before deciding on a pattern, you’ll end up flagging things as violations that are actually correct for your architecture, and missing violations that would be obvious once the pattern is clear.

My current setup uses Option C. The Single-Source-Of-Truth (SSOT) Audit section shows what that looks like in practice.

How Skills Break Without Telling You

Claude doesn’t throw an error when it reads a broken path. It reads the instruction, finds nothing at .claude/skills/seo-convert.md, and continues as if that line wasn’t there.

The output looks slightly wrong. You can’t tell why. You add another skill to compensate.

Five ways this happens:

Why this is hard to diagnose:

“The model doesn’t flag these contradictions. It picks whichever instruction has the most recent positional weight, or whichever happens to align with its training distribution, or something effectively random. You won’t know which instruction won until you see the output.”

— InsiderLLM, on prompt debt

The AI doesn’t tell you it’s confused. It just produces slightly inconsistent output. And you assume it’s a model problem.

That same 73%, most setups failing, most failing silently. The most common cause: broken or missing references, not bad instructions.

Not a rare edge case. The default outcome of adding skills without a maintenance system.

The SSOT Audit

When two files both describe how to write an article intro, Claude doesn’t flag the conflict. It picks whichever has the most recent positional weight. You get inconsistent output. You assume it’s the model.

The SSOT Audit makes that invisible structure visible. It runs three passes over your .claude folder:

Pass 1 — Reference scan. Every internal path reference across all skill and command files gets extracted and checked against what actually exists on disk. Paths that lead nowhere get flagged as broken references.

Pass 2 — Structure scan. Every item inside skills/ gets checked for proper folder shape — a named folder containing SKILL.md. Flat .md files at the root get flagged as singletons.

Pass 3 — Doctrine scan. Files with overlapping topic coverage get compared for content divergence. Two files both claiming ownership of the same job, with different instructions, get flagged as duplicates.

Each pass feeds one score. Each violation surfaces with its type, the specific file, and a one-line fix description. Run it, get three scores. Fix what’s flagged. Run it again. Score should be 10/10 before you close the session.

Knowing what can break is one thing. Knowing specifically what’s broken in your setup is different. Behind the paywall: my actual violation counts from 192 real files, the mental model for resolving what you find, and the script that scores your own setup in 30 seconds.

Upgrade

Next we’ll go through:

• My actual audit results — real violation counts from 192 files, what each finding looked like (including the naming disaster I didn’t catch until a script showed me)

• The complementary-vs-duplicate test — the 10-word check that tells you whether two skills are doing the same job

• The .claude architecture template — folder structure and ownership map, ready to adapt to your setup

• The ssot-auditor skill — point it at any .claude folder, get three scores in 30 seconds

Read more

I already had a hero-image system that worked.

Then OpenAI retired 4o, the model that made it reliable.

That left me with a simple problem: rebuild the workflow, or watch it slowly break.

So I tested Nano Banana 2 on the creator tasks I actually use: hero images, infographics, surface-led text visuals, profile rework, character consistency, carousel cards, multi-image assembly, and finally a Claude Code workflow powered by a Nano Banana MCP.

By the end of it, Nano Banana had taken over more of my visual workflow than I expected.

For this article, I generated more than 100 images and included around 30 of them so you can see the useful parts and the weak parts side by side. This is not a cleaned-up highlight reel. It is the full test: outputs, prompt patterns, verdicts, and the Claude Code workflow that made the whole process faster once everything moved out of manual trial-and-error.

What you’ll go through with me:

• What Makes Nano Banana 2 Different — the pricing, capabilities, and official positioning that make it worth testing seriously

• 7 Use Cases, Real Outputs — see the outputs first so you can decide immediately whether this is useful for your work

• The Deep Dive: 7 Use Cases, Broken Down — each use case broken down by prompt, output, what held up, what failed, and my verdict

• Run Nano Banana Inside Claude Code — run it inside Claude Code and speed up your image workflow

Hi, I’m Jenny 👋
I teach non-technical people how to build and launch AI systems that are actually useful in real life through the Practical AI Builder Program. AI builder behind VibeCoding.Builders and other products with hundreds of paying customers. See all my launches →

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

• How I Create Consistent Hero Images with ChatGPT

• Best Claude Code Projects, Beginner to Advanced

• Best MCP Servers for Claude Code: 15 MCPs to Transform Your Work

Subscribe now

What Makes Nano Banana 2 Different

Nano Banana 2 is Google’s public name for gemini-3.1-flash-image-preview, introduced on February 26, 2026. Google positions it as the high-efficiency counterpart to Nano Banana Pro: faster, cheaper, and built for high-volume image generation and conversational editing.

The official facts that matter here are simple:

• Mainstream price point for volume — Google’s Gemini API pricing lists gemini-3.1-flash-image-preview at $0.067 per 1024x1024 image, while Nano Banana Pro is $0.134 per image at 1024x1024 up to 2048x2048 on the same pricing page. If you generate in batches, the gap gets wider.

• Better text handling than earlier Flash image models — Google explicitly highlights advanced text rendering and localization and calls out improved i18n text rendering in the model documentation.

• More shape flexibility than the old 10-ratio setup — the current image generation docs list 14 supported aspect ratios, including 1:4, 4:1, 1:8, and 8:1.

• Image Search Grounding — Google added Grounding with Google Search for Images, which lets the model use web images retrieved through Google Search as visual context for generation.

What that means for creators is more practical than it sounds:

• Nano Banana 2 is the one worth stress-testing if you generate a lot.
  The price point is low enough that you can run real batches instead of treating every image like a precious shot.

• It is more reliable for working visuals than earlier Flash image models.
  Better text handling, more aspect ratios, and search grounding all map directly to creator tasks like infographics, carousels, and reference-based image generation.

• The docs are only the starting point.
  Product positioning tells you what Google thinks the model is for. The actual question is whether those advantages survive contact with real workflows.

Those platform claims only matter if they hold up in actual use. In some of my tests they mattered a lot. In others they barely mattered at all. That is why I structured the rest of this article around real workflows instead of feature descriptions.

So before getting into prompts and verdicts, let me show you the outputs first.

7 Use Cases, Real Outputs

Before getting into prompts, verdicts, and workflow details, I want to show you what Nano Banana 2 actually produced across the seven creator tasks I tested.

1. Hero Image Style-Lock

Test: Same style prompt across 3 article hero images in 3 columns below. Top 3 are from ChatGPT, bottom 3 are from Nano Banana. Do they feel like a set?

The 3 articles tested:

Claude Code vs 7 AI Coding Tools
Gmail MCP for Claude Code
What Is Practical AI Building?

2. Surface Visualization

Test: One short text-led idea across six drawing surfaces, showing the stats of this article. Which ones do you like the most?

3. Infographics

Test: Whiteboard process diagram from a text description. From article: Claude Code vs 7 AI Coding Tools. It actually looks like imperfect whiteboard drawing!

Test: Branded table. From article: Best Claude Code Projects.

4. Profile Photo Rework

Test: Background change in 4 parallel variations, then hair tidy on the two winners.

5. Story Book Character Consistency

Test: Same character across 5 scenes using a text description only.

6. Carousel Cards

Test: 4 consistent cards for article Best Claude Code Projects.

7. Piecing Up Images

Test: Five finished visuals assembled into one publishable comparison image. From article: Best Claude Code MCP servers

To test all of this properly, there was no way I was going to generate everything by hand in one sitting.

Midway through the process, I started using MCP. That was what made it possible to run all the use cases, compare outputs side by side, and keep the testing moving fast enough to finish this article.

You’ve seen all 7 outputs. Now get the full picture:

• Verdict on every use case — what actually worked, what drifted, what I’d never use again

• Exact prompts for every output shown above — copy, paste, adapt

• The template method — why generate_image produces inconsistent carousels and how edit_image fixes it

• Surface reference system — 9 drawing surfaces, when each one works

• Character consistency formula — how to hold the same character across multiple scenes

• Full MCP setup — install, configure, and run NB2 inside Claude Code without tab switching

Plus: Complete prompt library — 20+ prompts across all 7 formats, organized by use case

Upgrade

The Deep Dive: 7 Use Cases, Broken Down

This is the part I wanted when I first started testing: not just the gallery, but the actual prompt logic, the honest verdict, and which method I ended up using inside the MCP workflow.

1. Hero Image Style-Lock

Exact prompt block that changed the result:

Read more

How many Gmail accounts do you have? And how many unread emails are in there?

I have four. Personal, newsletter, business, payments.

This morning I asked Claude Code to scan all four and return only what needed my attention. It came back with 7 items. Two Ahrefs alerts. An n8n workflow that had been in a crash loop for two days. A Stripe payout. A reader question. Two emails that needed replies.

That 7 came out of 918 unread sitting in inboxes, and 3,353 when you count everything that bypasses the inbox through filters.

The brief took 40 seconds.

Before I explain why this became necessary, I’m curious where you sit:

The reason I needed this is tax season. I have income from Medium, Substack, Gumroad, my own apps, Stripe, and occasional affiliates. Some business deductions come through personal purchases too: Amazon orders, hosting bills, app development tools, random software receipts. It all adds up, and it all lands in different accounts for different reasons.

Getting everything in one place used to mean logging into each account separately, searching, exporting what I could, and cross-referencing dates. Hours of work that was really just moving data between tabs.

A single Gmail MCP connection didn’t solve that. (If you’re new to MCP, I have written about the Best MCP Servers for Claude Code to help you get the bigger picture.)

The problem here wasn’t access. It was switching. If I had to query one account, jump to another to match it up, then verify in a third, I was still doing the context switching myself. What I wanted was Claude moving through each account in sequence, fetching what I needed, storing it locally, and matching across all of them without me leaving the session.

Getting Gmail into Claude Code for one account is straightforward. The multi-account case is where it quietly breaks, and the fix isn’t obvious until you’ve hit each failure mode once.

Once that full multi-account MCP setup is working, a much bigger set of workflows opens up. That’s what I’ll show you next.

What’s inside:

• What can you automate with Gmail MCP? — receipt extraction, inbox triage, subscriber monitoring, 40-second morning brief

• When Gmail MCP needs multiple accounts — account bleed, re-auth friction, false confidence

• 5 Gmail MCP workflows worth running first:

  • Receipt extractor → $986.41 pulled in one run

  • Collab pitch triage → inbox to decision in one prompt

  • Inbox zero → classify, archive, draft in sequence

  • Subscriber surge detector → 28 new subs caught before I noticed

  • Morning brief → all 4 accounts, 7 items, 40 seconds

• How to automate a Gmail MCP nightly digest — the scheduled version that runs without a manual prompt

• Gmail MCP multi-account setup for Claude Code — one Google Cloud project, 4 named inboxes, the fork that made it reliable

• Gmail MCP config template + 5-prompt pack + 12 more automation ideas — grab it at the end

What Can You Automate With Gmail MCP?

Most Gmail MCP demos stop at “search my inbox.” That proves access. It does not prove usefulness.

Gmail MCP is the connection layer that lets Claude Code search, read, draft, and organize your Gmail from inside the same session you’re already working in.

Once it works across multiple accounts, the first jobs worth running are much more practical:

• Pull money history into one place by extracting receipts, payouts, invoices, and payment confirmations across accounts

• Triage what needs attention by separating needs-reply, FYI, and automated emails before you touch anything

• Watch for growth signals by spotting subscriber spikes, recommendations, and unusual activity in the newsletter account

• Scan all accounts at once so personal, business, newsletter, and payments stop behaving like separate places you have to visit manually

The two highest-value jobs for me were extraction and triage, because they replace real admin work instead of giving you a fancier search box.

The simplest version of this was the payments pull.

In 45 seconds, it pulled 103 emails and turned six months of payouts, subscriptions, and tool fees into a markdown file I could actually use. That is tax-prep work that usually takes an afternoon of tab switching.

The free proof is simple: Gmail MCP can turn a messy payments inbox into something structured fast. The paid section is where I give you the full production-ready version: the exact search logic, the saved output format, and the cleaner prompt I would actually reuse.

The same pattern becomes useful in the other accounts too:

• personal → classify unread and surface what needs a reply

• newsletter → watch for subscriber spikes and recommendation alerts

• business → pull collab pitches and partnership requests into one review pass

• all 4 together → generate one morning brief instead of four separate inbox checks

That is the shift that matters. Gmail stops feeling like a place you visit and starts acting like a system you can query.

When Gmail MCP Needs Multiple Gmail Accounts

Connect one account. Run one extraction prompt. Run one triage prompt. That alone is enough to tell whether Gmail MCP is useful at all.

The multi-account problem starts when the work itself is split across accounts.

In my case, income lands in one account, newsletter activity in another, business conversations in a third, and personal purchases in a fourth.

At that point, the problem is no longer “can Claude read Gmail?” The problem is whether the setup can move across accounts cleanly enough to replace the switching.

That is where most multi-account setups start to wobble:

• Account bleed — you ask one inbox a question and quietly get results from another

• Re-auth friction — the setup works, but demands enough maintenance that it stops feeling like infrastructure

• False confidence — the tool appears to work, but the routing is unreliable, which is worse than a visible failure

Once those three problems were handled, the system got simple:

The Gmail MCP Stack

1. One Google Cloud project → handles OAuth for all 4 accounts without credential bleed

2. 4 named MCP servers → gmail-personal, gmail-newsletter, gmail-business, gmail-payments, each isolated

3. 5 workflow types → receipt extraction, collab triage, inbox zero, subscriber surge detection, morning brief

4. One nightly digest → Claude-triggered, runs all 5, delivers the brief without a manual prompt

That was the moment the setup stopped feeling fragile and started feeling useful.

Next, I’ll show you what those workflows look like in practice, then the exact multi-account setup that made them reliable.

• The receipt extractor — the exact prompt, the full markdown table output, and $986.41 pulled in one run

• The collab pitch triage — the workflow that pulled 4 borderline partnership emails into one review pass and showed where context still matters

• The subscriber surge detector — the workflow that caught 28 new subscribers before I noticed, and why the reader-reply version returns nothing

• The inbox zero classifier — classify, review the breakdown, then approve the bulk archive before anything gets touched

• The morning brief — one prompt across all 4 accounts, 7 action items surfaced in 40 seconds

• The 4-account setup — one Google Cloud project, named connections, and the few tweaks that made the open-source MCP behave reliably

Plus: the nightly digest job, the routing path for each email type, and a note on the small fork I made to the open-source Gmail MCP so the multi-account setup would hold up

Upgrade

5 Gmail MCP Workflows Worth Running First

This is the part that makes the setup feel real.

Not “Claude can read email.” Actual jobs, specific prompts, and outputs you can judge.

Read more

You’ve seen the posts. A 24/7 employee who never sleeps, handles every digital task you throw at it. An autonomous investor agent that made $14,700 in three weeks. A sleepless developer who ships features while you’re asleep. This is what OpenClaw promises. This is what circulates on social.

If you opened this article expecting that — let’s reset.

OpenClaw can do real things. The gap between “autonomous agent” and something useful you actually trust is exactly where everyone gets stuck. This article is about closing that gap.

I’ve had 12 active cron jobs running on Oracle ARM for weeks: briefings, content research, Substack engagement monitoring, social posts. All autonomous. Two of those exact jobs show up in the cron section below. This is what it took to get there, and what I’d skip if I was starting today.

What’s Inside:

• What “done” actually looks like — so you know when you’ve crossed the finish line

• Pick your path — which install method fits your situation, without the sales pitch

• What most tutorials skip — five production gaps worth knowing before you start

• Install OpenClaw — local and Oracle ARM, side by side

• Give your agent an identity — what to write in SOUL.md and AGENTS.md

• Connect Telegram — including the pairing step the wizard doesn’t mention

• Your first cron job — from zero to your agent messaging you without being asked

🎁 SOUL.md, AGENTS.md, USER.md, and cron jobs templates — the ones I use in production — available at the end.

Hi, I’m Jenny 👋
I turn friction into launched AI systems, and help you to do the same. AI builder behind VibeCoding.Builders and other products with hundreds of paying customers. See all my launches →

If you’re new here, you might enjoy:

• OpenClaw for One-Person Businesses — the why before the how

• 4 Levels of AI Automation: When Claude, n8n, and OpenClaw Each Win — how to know which tool fits which job

• OpenClaw Live Demo: What It Looks Like After Four Weeks — 18 cron jobs, live MCPs, and what surprised me

• MCP Second Brain: Connected Intelligence Guide — how memory works across sessions

Subscribe now

What “done” actually looks like

Most OpenClaw tutorials declare success the moment the gateway starts. That’s step one. There are three more.

The complete loop has four stages:

Your machine → OpenClaw gateway → Telegram → you

Done means all four are working:

1. Gateway running — installed, starts cleanly, openclaw gateway status shows runtime: running and RPC probe: ok

   

2. Identity configured — SOUL.md, AGENTS.md, and USER.md are filled in with real constraints, not default placeholders

3. Telegram connected — you can message the bot and get a response; the bot can message you first

   

4. Cron job firing — the agent sends you something without you asking

Stage 4 is the whole point. Everything before it is setup. A gateway that starts but has no identity, no Telegram, and no scheduled work is an expensive chatbot.

Time to expect:

• Local (Mac/Linux): about 20 minutes to a working conversation, plus 10 more for the first cron job

• Oracle ARM: about 45 minutes including server setup

• DigitalOcean: see Pick Your Path — UI bug in the current version

Pick your path

Seven real options. The short version: if you’re on a generic VPS (Hetzner, Vultr, Linode), the setup is identical to Oracle ARM — bare Ubuntu, same manual steps, same systemd config. The only difference is you’re paying for what Oracle gives away free.

*Railway can scale to zero on some plans, which silently kills cron jobs.

→ Just want to try it? Local. You’ll have it running in 20 minutes with zero infrastructure decisions.

→ Free and permanent? Oracle ARM — if you can get one. The always-free tier gives you 4 OCPU and 24GB RAM, but ARM capacity is heavily contested. I had to hit the API thousands of times programmatically before one provisioned. If you land one, it runs 24/7 without a bill. If you can’t, paid options is the next best thing.

→ Willing to pay? Railway or Fly.io for the shortest path. Render works well on a paid plan — avoid the free tier if you’re running cron jobs. Hetzner and similar VPS providers are solid options if you already have one running; just follow the same Oracle ARM steps.

→ DigitalOcean: OpenClaw exists in their marketplace as a 1-click app, but the Droplet creation UI is currently broken — region selection doesn’t persist and the Create button stays grayed out. Skip it for now.

For more on what OpenClaw actually does before you commit to a path, read OpenClaw for One-Person Businesses. And before you start installing: five production gaps worth knowing that most tutorials skip entirely.

What most tutorials skip

Five production gaps. Enough to name each problem — the solutions are in the paid section.

1. SOUL.md without hard constraints is incomplete.

The docs show you how to define a personality. They don’t tell you what happens at 3am when a cron job hits an ambiguous situation and there are no explicit rules to fall back on. A SOUL.md without a hard constraints section is a personality document, not a safety layer. The difference matters when the agent has access to real systems.

2. The Telegram pairing step isn’t in the wizard.

The first time you message your bot after setup, you won’t get a response. You’ll see a code:

OpenClaw: access not configured.
Pairing code: XXXXXXXX
Ask the bot owner to approve with: openclaw pairing approve telegram XXXXXXXX

❌ What people do: assume the bot is broken, restart the gateway, try again.
✅ What works: run openclaw pairing approve telegram [CODE] from terminal. One command.

3. Asking the agent to “work on this” and closing the chat doesn’t work.

Sessions are stateful only while open. Close the window, the agent stops. Background tasks — anything that should run while you’re not there — need cron jobs with an isolated session target. This is the gap between “autonomous agent” and “chatbot you have to babysit.”

4. For cron jobs: use the UUID, not the job name.

❌ openclaw cron run "substack-notes-review" — won’t work
✅ openclaw cron run [UUID from openclaw cron list] — this is what the scheduler uses internally

Also: the CLI times out at 30 seconds. The job keeps running in the background. The terminal returning is not a failure.

5. Scoped credentials before you give it database access.

When you connect the agent to a real system — Supabase, an API, a database — create a read-only or scoped credential specifically for the agent. The hard constraints section in SOUL.md catches intent. Scoped credentials limit blast radius. Both are needed.

💎 Keep reading with a paid subscription

Inside: the complete setup video walkthrough for local — plus the exact files I use in production.

• Step-by-step install — local and Oracle ARM in one article, follow your path without switching tabs

• SOUL.md and AGENTS.md templates — my production files, cleaned up, with the hard constraints section that stops the agent from acting on something you didn’t ask for

• Telegram setup — including the pairing workaround and the group ID trick the docs skip

• First cron job — from zero to your agent messaging you without being asked, including MCP setup for external tools

Plus: the openclaw doctor diagnostic ladder — five commands to run in order before you go hunting for what broke

Read more

Claude Code’s plugin marketplace launched quietly. Soon it wasn’t quiet anymore.

Developers started running Claude skills on every session. Marketers installed business plugins and expected them to know their business. Builders stacked MCP servers on top of hooks on top of skills and wondered why things felt slow.

The biggest frustration was never whether plugins work.

It’s that it’s almost impossible to tell what “working” actually means until you’ve run one on something real.

I’ve been building and shipping with Claude Code daily since it launched. When the plugin ecosystem expanded to 101 official plugins, I decided to stop guessing and start testing. I ran content plugins on my actual writing system. Business plugins on my actual positioning questions. Coding plugins on a real feature build for an app I maintain.

For the same real-work test applied to the tools themselves — not the plugins — the 8-tool AI coding audit runs Claude Code, Cursor, and six others through the same three-stage evaluation approach.

What’s inside:

• What Claude Code plugins actually are — skills, hooks, commands, and MCP servers: the 4 components bundled in one install at three different cost levels

  • Claude Code plugins vs. Claude Desktop vs. Claude Web

  • Where Claude Code plugins come from: 3 levels of trust

• 11 Claude Code plugins tested on real work

  • Best Claude Code plugins for content and writing — Brand Voice found 34 Gumroad products I’d never audited for consistency

  • Best Claude Code plugins for business workflows — Marketing vs Sales: why one gave me the right answer and one gave me wrong data with a flashy UI

• Best Claude Code plugins for coding and development — feature-dev eliminated 4 database tables before a line of code was written

• Domain-specific Claude Code plugins: when niche beats general-purpose

• How to build your Claude Code plugin stack (after testing 11) — always-on vs session-based toggle logic, by workflow type

  • Plugin evaluation scorecard — 9 questions before installing anything

  • Known breakages and workarounds — every failure mode I hit

What Claude Code Plugins Actually Are

People use “plugin” to mean several different things inside Claude. They do not behave the same way. Once you see the building blocks, the confusion disappears.

Claude Code Plugin Components: Skills, Hooks, Commands, and MCP Servers

A Claude Code plugin bundles one or more of these:

• Skills — what most people mean by “using a plugin.” You trigger them with a slash command (/brand-voice:enforce-voice, /marketing:seo-audit). Runs once, does its job, stops. Cost: per use.

• Hooks — run automatically in the background. They attach to events (file write, session start, commit) and fire every time without you asking. Cost: every session they are active.

• Commands — the management layer. /plugin install, /plugin disable, /plugin marketplace add. Free. Not the plugin itself.

• MCP servers — external connections to databases, APIs, file systems. Not plugins themselves, but bundled inside plugins so often that people treat them interchangeably. Cost: per query. (For a specific setup walkthrough, connecting Gmail across multiple accounts via MCP shows the exact installation pattern.)

A Claude Code plugin can bundle skills, hooks, and MCP servers together — one install, three behaviors at three different cost levels.

Why it feels muddy: one plugin can contain skills, hooks, and MCP configs together. You install one thing, you get three behaviors at three cost levels. That matters when you ask “why is this session slow?” or “why did something run that I did not ask for?”

Claude Code plugins versus Claude plugins

Three products. Different installation. Different capabilities.

• Claude web (claude.ai) — MCPs, web search, built-in tools. No terminal, no local file access, no hooks, no slash-command plugin system.

• Claude Desktop — MCP-based extensions for file access, database queries, APIs, browser tools. More capable, but still not the Claude Code plugin layer.

• Claude Code — the full system. Skills, hooks, commands, MCP servers, marketplace browsing, always-on vs. triggerable behavior, local file access.

You install through the CLI:

/plugin install security-guidance@claude-plugins-official
/plugin marketplace add owner/repo
/plugin install brand-voice@knowledge-work-plugins

Plugins live in ~/.claude/plugins/ and work across projects once installed globally. The confusion starts here: someone reads about a Claude Code plugin, looks for it in Claude Web, cannot find it. Same brand name, different product.

If you use ChatGPT or Gemini, Claude Plugins are meaningfully different architecture from Claude Skills vs. ChatGPT GPTs and Gemini Gems.

Where Claude Code Plugins Come From: 3 Levels of Trust

Three levels. The trust story is different at each one.

Level 1: Official Anthropic marketplace

claude-plugins-official is built into Claude Code. As of March 2026: 101 plugins (browse here).

• 33 Anthropic-built: language servers (12), dev workflow (10, including feature-dev, code-review, commit-commands, security-guidance, frontend-design), setup tools (5), output styles (2), playground (1), messaging (3)

• 68 partner plugins: GitHub, Playwright, Supabase, Figma, Vercel, Linear, Sentry, Stripe, Firebase, and more

Two additional Anthropic marketplaces (require manual add):

• life-sciences — 17 biomedical plugins

• knowledge-work-plugins — 14 role-based plugins (Sales, Marketing, Finance, Legal, HR, Brand Voice)

There are also 11 plugins tagged “Cowork” on claude.com/plugins. The site labels them Cowork-only. Misleading. I installed and tested Brand Voice, Marketing, Sales, Productivity, and Cowork Plugin Management directly in Claude Code through knowledge-work-plugins. They work.

Level 2: Community marketplaces

GitHub repos anyone can share. Add with /plugin marketplace add owner/repo. No verification. Quality depends on the maintainer.

Worth knowing:

• ComposioHQ/awesome-claude-plugins — 25-30 production plugins

• jeremylongshore/claude-code-plugins-plus-skills — 346 plugins, quality-graded

• alirezarezvani/claude-skills — 192+ plugins

Not everything in these repos is installable. Some have full plugin.json packages. Others are standalone skill files for .claude/skills/. “1,916 skills” does not mean 1,916 things you can /plugin install.

Level 3: Discovery tools

Sites you will hit before finding the official marketplace:

• ClaudePluginHub.com — 14,083+ indexed

• Build with Claude — 2,865 marketplaces

• claude-plugins.dev — community registry

These are search engines, not sources. They scan GitHub for plugin.json and index what they find. Useful if you know how to evaluate. If not, stick with official repos.

From Anthropic’s docs: “Plugins and marketplaces are highly trusted components that can execute arbitrary code on your machine. Only install from sources you trust.”

Private or team plugins sit outside all three levels. Custom builds from a local path or hosted source. If you want to go that route, how to build your own MCP server covers the full process.

11 Claude Code Plugins Tested on Real Work

I tested in four buckets: content, business, coding, and one niche life sciences case. For each plugin, three questions:

1. Where does it work?

2. Where does it break?

3. Does it earn a place in the stack?

Then I used those tests to answer the bigger questions underneath: workflow fit, overlap, collaboration, and whether the plugin was improving my process or just adding machinery.

Best Claude Code Plugins for Content and Writing

The easiest to evaluate. I could run them against my real content engine, Substack workflow, and brand materials.

Every plugin here installs the same way: add it to your claude_desktop_config.json (Mac: ~/Library/Application Support/Claude/) and restart Claude Code. To verify any MCP is connected: open Claude Code and type /mcp — it lists every active server and its status. If a server shows as disconnected, check your config JSON for syntax errors.

How to install the plugins in this section:

# What I actually used during testing
/plugin marketplace add /Users/bouyang/Documents/Zxperiment/media/newsletter_position/knowledge-work-plugins
/plugin install brand-voice@knowledge-work-plugins

# Official plugin in this section
/plugin install explanatory-output-style@claude-plugins-official

Note: knowledge-work-plugins had schema validation issues during testing. I used a local fixed copy. That breakage matters and I come back to it later.

Plugin 1: Brand Voice

What it is: Three-skill plugin. Discovers your scattered brand materials, generates guidelines, enforces your voice.

• /brand-voice:discover-brand — searches directories, platforms, and products for brand materials

• /brand-voice:generate-guidelines — synthesizes into a structured guidelines file

• /brand-voice:enforce-voice — applies guidelines as you write

Where it works: Most creators have brand guidelines in five places: a Notion doc from 2023, a Google Doc nobody reads, random files in a content folder. This plugin finds all of it and makes it usable.

On my content-engine directory:

• Found 15 brand documents across subdirectories

• Found 34 Gumroad products I had never reviewed for consistency

• Generated a 963-line guidelines file saved to .claude/brand-voice-guidelines.md

• Available automatically in future sessions

The output difference was immediate.

Without Brand Voice:

“In this comprehensive guide, we’ll explore the landscape of Claude Code plugins. It’s worth noting that the plugin ecosystem has grown significantly.”

With Brand Voice enforced:

“Claude Code has 30 official plugins. I had one installed. It came from a life sciences template I’d forgotten about.”

Where it breaks: If you create content for different channels with different voices, leaving it on globally steers everything toward one guideline set. That can work against you.

Verdict: KEEP. One-time discovery + guidelines generation pays back on every article after.

For the visual side of the same content workflow — generating hero images, infographics, and carousels — Nano Banana 2 in Claude Code tests 7 creator workflows on 100+ real outputs, the same way this article tests plugins.

The bigger question it raised:

If I already have a voice, or write across multiple channels, when does a plugin like this genuinely help and when does it start steering work in the wrong direction?

Plugin 2: explanatory-output-style

What it is: Always-on hook. Modifies every Claude response: progressive disclosure, layered explanations, insight sections, teaching scaffolding.

Where it works: I asked Claude to explain the plugin marketplace system. Output was 9/10 for clarity: three-layer architecture walkthrough, component deep dives, ASCII flow diagrams, progressive disclosure from simple to advanced. For tutorial writing and technical explainers, this is exactly the structure you want.

Where it breaks: It is a hook, not a skill. It runs on every response.

• Quick coding question? Still gets a structured lesson.

• Content editing? Still gets a structured lesson.

• Adds token cost to every exchange, not just the ones where structure helps.

Verdict: CONDITIONAL KEEP. Strong for tutorials and documentation. Too much for everything else.

The question it left:

When is always-on structure worth the session cost, and when does it become drag?

Best Claude Code Plugins for Business Workflows

This is where I hit the difference between polished output and trustworthy output.

How to install the plugins in this section:

# What I actually used during testing
/plugin marketplace add /Users/bouyang/Documents/Zxperiment/media/newsletter_position/knowledge-work-plugins
/plugin install marketing@knowledge-work-plugins
/plugin install sales@knowledge-work-plugins
/plugin install productivity@knowledge-work-plugins

Plugin 3: Marketing

What it is: Six-skill plugin for the full content marketing workflow: SEO audit, drafting, brand review, competitive research, campaign planning, email sequences.

Skills tested: /marketing:seo-audit, /marketing:draft-content, /marketing:brand-review, /marketing:competitive-brief

Where it works: Each skill is useful alone. Together they chain: audit finds gaps, drafting fills them, review catches compliance issues.

I tested three parts across ~1 hour 40 minutes:

• SEO audit (30 min) — full audit of buildtolaunch.com. 25 keyword opportunities, 7 competitors benchmarked, 90-day action plan.

• Content drafting (45 min) — three SEO-driven drafts (~2,900, 4,100, 3,600 words) with Brand Voice applied.

• Brand review (25 min) — 4 high-priority issues caught: missing personal intros, uncited revenue claims, affiliate disclosure gaps. Compliance score: 85/100.

Where it breaks: Drafts still needed editing. Not publish-ready. But they were real working drafts with structure and voice applied, not throwaway copy.

Verdict: KEEP. Enable for content planning sessions. Disable for Notes and quick social posts.

The question it raised:

How do you tell when a plugin is working with another plugin versus just running beside it?

Plugin 4: Sales

What it is: Ten-skill plugin for sales workflows: competitive intelligence, pipeline review, cold outreach, call prep, forecasting, account research.

I ran /competitive-intelligence on Build to Launch. The HTML battlecard looked finished: tabs, comparison matrix, dark theme, talk tracks, landmine questions per competitor. Generated in 2 minutes.

Then I read the data.

• Claimed I had 2,000 subscribers. I have 5,000+.

• Compared me to The Rundown AI (2M subscribers) and DeepLearning.AI (7M learners). Completely different league.

• The analysis was no better than asking Claude Code without any plugin.

The real problem: Marketing has a competitive-brief skill covering similar ground. I ran both on the same question: who are my competitors and where am I positioned?

• Sales — flashy output, wrong data, wrong tier.

• Marketing (~45 min) — 3 comparable competitors identified, “stuck-in-the-middle builder” positioning gap found, 10+ content gap opportunities, 7 actions split into quick wins and strategic moves. Grounded in my actual tier.

Most of the Sales plugin is designed for professionals with CRM pipelines and regular customer calls. If that is not your setup, most of its surface area sits unused.

Verdict: SKIP for content creators and builders. The overlap with Marketing is real. When both answered the same question, Marketing was more accurate and more useful.

The bigger question:

When a plugin looks good on paper, how do you tell whether it is for you or for a completely different operator?

Plugin 5: Productivity

What it is: Task management and daily planning. /start creates structured breakdowns, priority rankings, persistent memory across sessions.

Where it works: Thoughtful design. Project-based organization, priority ranking, file-based persistence. If you have no task system, this is a reasonable place to start.

Where it breaks: If you already use Notion, Linear, a custom panel, or even a well-maintained markdown file, this adds another layer managing the same information. I tested /start, confirmed it works, and moved on.

Verdict: SKIP if you have a working system. Try it if you have nothing.

Up to this point, you’ve seen the individual tests.

What changed my mind was not any single plugin result. It was the bigger questions those tests kept raising:

• When does a plugin genuinely improve the way you already work?

• When do two plugins actually collaborate well?

• When is an always-on plugin worth the extra cost and friction?

Next, we’ll go over:

• The coding plugin results — five plugins tested on a real feature build, including the one that eliminated four database tables before a line of code was written

• The stack I’d actually keep — always-on vs. session-based, with exact toggle logic for content, coding, and UI work

• The plugin evaluation scorecard — nine questions that tell you whether a plugin earns a place before you install it

• Known breakages and workarounds — every failure mode I hit, and what I’d do differently

Plus: the callout format that separates plugins worth testing from ones that just look polished

Upgrade

Read more

Before you build anything, a tool, a product, an aggregator… you need to answer: Is there accessible data? What’s the competition doing? Which sources are open, which are locked down? Is this even worth building?

Most people spend weeks clicking through sites, taking notes, guessing. Or worse, skip validation entirely and build blind.

I compressed this into 70 minutes using AI. I’ve done this kind of research before with Cursor, and the methodology works for any industry. Deal sites, API marketplaces, job boards, newsletter platforms, SaaS directories, any ecosystem where you need to map the landscape fast.

Here’s the exact process, applied to deal-finding sites: 16 sites researched, 7 goldmines found, 6 blocked sources avoided, 1 working app shipped. Same 70-minute framework. Same AI research stack. Replicable for any niche.

If you’re new to Claude Code, start with the beginner’s guide. Once you’ve validated your idea with this process, here are 15+ projects you can build.

What you’ll go through with me:

• What I Found: The Deal Site Landscape in 70 Minutes — research results from 16 sites, 7 goldmines vs 6 blocked sources

• What This Taught Me (And Why It Applies Everywhere) — universal insights about RSS, WordPress APIs, and data accessibility

• This Works for Any Ecosystem — apply the same process to SaaS, jobs, newsletters, APIs, research tools

• How I Researched Deal Sites in Minutes — the AI research stack and 9 copy-paste prompts for parallel agents

• Building the App: Key Decisions and Challenges — deduplication, translation, timezones, and what almost broke

• Apply This to Your Next Project — the framework, data access hierarchy, and 30-minute action plan

• Next Steps — beginner, intermediate, and advanced starting points

🎁 The 9 Claude Code research prompts, complete research kit (Notion template + Perplexity prompts + full results), and framework for validating any idea, all included.

What I Found: The Deal Site Landscape in 70 Minutes

After relocating cross-country, I needed a deal aggregator that didn’t exist. Before building it, I had to know: Which sites have accessible data? Which are blocked? What are the business models?

Using Perplexity, Notion, and Claude Code in parallel, I mapped 16 sites and found 7 with working RSS feeds or APIs.

Notion database with research results

The Four Categories of Deal Sites

The deal-finding world breaks down into four distinct categories, each with different business models and (critically for builders) different levels of data accessibility.

1. Deal Aggregators

They are the sites that actually curate deals.

Slickdeals, Hip2Save, Ben’s Bargains, Dealnews, Southern Savers, Duoshou, and Dealmoon. Some are community-driven (Slickdeals), others are editorial (Ben’s Bargains proudly claims “100% human-sourced”). Duoshou and Dealmoon target Chinese-speaking shoppers in the US with deals from American retailers.

The surprise?

Most of these run on WordPress and expose their content through RSS feeds or REST APIs. Hip2Save’s WordPress API returns structured JSON with titles, prices, images, and categories. Slickdeals has an RSS feed with 25 curated deals, including their famous “thumb score” ratings.

This was the goldmine I was looking for.

2. Cashback Platforms

Rakuten, TopCashback, and Ibotta negotiate commission splits with retailers—getting 5-15% on purchases—and share a portion with users. For builders, these are essentially closed ecosystems. No public APIs, no RSS feeds.

They guard their retailer relationships carefully.

3. Coupon Extensions

Sites like Honey (owned by PayPal) and RetailMeNot auto-apply coupon codes at checkout. These sites are increasingly hostile to scrapers. RetailMeNot has extensive anti-bot measures. Honey is facing class-action lawsuits over affiliate commission attribution—allegedly replacing creators’ tracking tags with its own.

The browser extension model seems to be hitting some turbulence.

4. Price Trackers

Such as CamelCamelCamel and Keepa focus specifically on Amazon price history. CamelCamelCamel is free but now has Cloudflare protection on its RSS feeds. Keepa has a paid API starting at €19/month.

These are complementary to deal aggregators, not competitors—they track prices over time; aggregators find current deals.

What Actually Works (And What’s Blocked)

Here’s the practical breakdown for anyone thinking about building in this space:

Working Sources (7 RSS feeds + 5 WordPress APIs)

Blocked or Inaccessible (6 sites)

• RetailMeNot: Extensive anti-bot measures, legal warnings in robots.txt

• Honey: No public data access, anti-bot measures

• Brad’s Deals: No feeds, extensive blocking rules

• Dealnews: RSS endpoint returns JavaScript instead of XML

• CamelCamelCamel: RSS feeds protected by Cloudflare

• Dealmoon: Explicitly blocks AI crawlers in robots.txt, no public API

The takeaway: Plenty of high-quality sources are open and accessible. You don’t need to scrape protected sites. The deal blogs want you to access their data, it drives affiliate revenue for them.

What This Taught Me (And Why It Applies Everywhere)

After researching 16 sites and building this app, a few things stood out:

RSS feeds still work. I expected to need complex scraping, browser automation, maybe even proxy rotation. Nope. Good old RSS feeds, a technology from 1999, power most of my data collection. The deal world hasn’t moved on because RSS works perfectly fine. And this isn’t just for deals, blogs, podcasts, job boards, government data, RSS is the universal data access layer nobody talks about. MCP servers make connecting to these feeds even simpler.

WordPress APIs are everywhere. Deal blogs love WordPress. And WordPress exposes a REST API by default. This is why Hip2Save, Southern Savers, and The Freebie Guy are all trivially easy to access, they’re running the same CMS with the same API structure. 43% of the web runs WordPress. If your target sites run WP, you have instant API access. This applies to: deal blogs, recipe sites, news outlets, local business directories.

The Honey scandal is a warning. PayPal paid $4 billion for Honey in 2020. By 2024, they’re facing class-action lawsuits over how the extension handles affiliate commission attribution. The browser extension model, inserting yourself between shoppers and checkout, creates complex incentive problems.

Human curation still matters. Ben’s Bargains proudly advertises “100% human-sourced.” Slickdeals has a community voting system that surfaces the best deals. Even in an age of AI, human judgment remains valuable. Deciding “Is this actually a good deal?” is something algorithms still struggle with.

Anti-bot measures are increasing. Sites like RetailMeNot have extensive blocking rules. But here’s the thing, plenty of other sites are wide open. You don’t need to fight the locked ones. Find the open ones. True across every industry.

The research was validation, not just preparation. If I’d found exactly what I needed, I wouldn’t have to build. If data access was locked down, it wouldn’t be worth the effort. Instead: 7 open sources, nearly no English-language solution, clear gap. Even if only my family uses it, saving myself time every week is worth it. I use this same AI research workflow across different domains, and here’s how I studied 3,000 Substack notes with the same framework to understand what content actually works.

This Works for Any Ecosystem

The same 70-minute process applies to:

• SaaS directories — Which review sites have APIs? Which block scrapers? How do they categorize tools?

• Job boards — Where do tech jobs actually get posted? Which have RSS? What’s the posting frequency?

• Newsletter platforms — Which Substack competitors exist? What’s their data access? What features differentiate them?

• API marketplaces — RapidAPI vs alternatives? Which have accessible catalogs? What’s the pricing model?

• Content platforms — Medium, Dev.to, Hashnode—which allow crossposting? What’s the canonical link policy?

• Market research — Who are the competitors? What’s their tech stack? What public data can I access?

• Research tools — Which academic databases have APIs? What’s behind paywalls? Where can I scrape ethically?

• E-commerce platforms — Shopify, WooCommerce, BigCommerce—what data can third-party apps access?

The questions change. The research methodology stays identical: map the landscape → test accessibility → understand business models → validate data quality.

Whether you’re researching deal sites, API marketplaces, or newsletter platforms—the pattern repeats across any domain. Once validated, pick a project and build it.

Keep reading with a paid subscription

The research results and insights are yours. Here’s what’s next:

• The exact 9 Claude Code prompts I used — Copy-paste ready prompts for parallel agent deployment

• The AI research stack setup — How Perplexity, Notion, and Claude Code work together

• Your 30-minute action plan — Apply this to validate any niche yourself

• Complete research kit — Notion template, 15+ Perplexity prompts, full technical results

How I Researched Deal Sites in Minutes

Here’s exactly how I did it, three AI tools, each for what it does best:

Read more

Vibe coding changed what “anyone can build” means. Generating code isn’t the hard part anymore.

Shipping it end-to-end is. A live URL that holds up when someone actually visits it. A database that doesn’t break under real data. Environment variables that work in production, not just dev. An AI integration that doesn’t silently fail the moment you combine it with an RSS fetch.

That’s where most first builds die, not in the idea, not even in the code, but in the gap between “it runs in preview” and “it’s actually deployed.”

This guide covers that gap completely. ChatGPT to lock the architecture before you write a single line. Replit to build in five structured phases. Supabase for the database. OpenAI for summarization. Vercel for hosting. And the one production fix that every Replit deploy needs and that no tutorial mentions.

Build this once, and you have a reusable system. The same planning process, the same prompt structure, the same deployment pattern applies to the next project too, a newsletter CRM, a content gap finder, a job tracker, a link archive. Different apps. Same bones.

What You’ll Get:

This is the finished app, live URL, real articles, AI summaries, categories filtering correctly. The build takes one focused session using the system in this guide.

Everything in this guide:

The setup

• What this actually costs — Replit billing from a real screen, the $100/month hosting trap, and why Vercel changes the math

• Why opening Replit first is the #1 mistake — the sequencing that determines whether you ship in one session or three

Step 1: The ChatGPT planning session

• The one prompt that changes output quality — how to make ChatGPT ask you questions instead of jumping to answers

• Round 0–1: Problem statement + the 12 questions that lock your architecture — what you’re building, what it stores, how it flows

• Round 2–4: Architecture, constraints, final details — locking the data model before any code is written

• Round 5: The Master Initialization Prompt — the single prompt you paste into Replit first

• Round 6: Phased build prompts — what a real Phase 1 prompt looks like (screenshot included)

• Round 7: Verification and hardening — the test checklist that catches integration failures

Step 2: Building in Replit

• Agent mode vs Assistant mode — when to use which and what each actually costs per task

• What each phase looks like on screen — the 404 that’s expected, the empty state that confirms Phase 3 worked

• The categorization prompt that actually works — why the default fails (95% “Technical”) and the exact prompt fix

• Database patterns: duplicate detection, indexes, transaction safety — the code that prevents the three most common production data bugs

Step 3: Production deployment

• One-click publish and what to do right after — what the Publishing tab shows, what to add before you share the URL

• The ENOTFOUND error — why it happens every time — Replit’s workspace-scoped secrets explained, with the log screenshot

• The exact fix: Advanced Settings → Secrets — the four variables, where to find them, in two minutes

What comes next

• 4 projects to build with the same stack — newsletter CRM, content gap finder, job tracker, link archive

• All templates — 7-round conversation prompts, schema, deployment checklist, copy-paste ready

Stack: Next.js App Router + TypeScript + TailwindCSS + Supabase + OpenAI + Replit (build) + Vercel (host)

Hi, I’m Jenny 👋
I help non-technical people ship real products with AI. AI builder behind VibeCoding.Builders and other products with hundreds of paying customers. See all my launches →

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

• How to Vibe Code a Production-Ready App

• Smoke Testing for Vibe Coders

• 15 Claude Code Projects: From First Prompt to a System That Runs Itself

Subscribe now

Before You Open Replit

Most first builds fail the same way. Someone opens Replit, types “build me an RSS reader app with AI summaries,” watches the agent start generating, then hits a wall around Phase 3 when the database connection breaks or the AI categorizes everything wrong. They spend the rest of their credits trying to undo decisions the AI made for them.

The fix is sequencing. Spend 30–45 minutes resolving the hard decisions in a free tool (ChatGPT) before touching Replit. By the time you open Replit you should have a complete spec: tech stack, data model, what to store, how data flows, what the AI does at each step, and a phased prompt chain ready to paste in order.

The result: a coherent build in one pass rather than three sessions of undoing.

Real Costs Upfront

This is a real billing screen from one build session, not a screenshot from a pricing page.

What you’re actually paying for:

Replit Core plan: $240/year ($20/month). Includes $25/month in credits that reset monthly and do not roll over.

Agent usage: Variable. One focused Agent-mode build session consumed $8.98 of a $25 credit allocation. Complex sessions can consume half your monthly credits in an afternoon.

Assistant (edit requests): $0.05/edit. Flat rate, predictable. Use this for targeted tweaks once the core build is complete.

The hosting number that catches everyone: Running a deployed app on Replit’s Autoscale infrastructure costs roughly $1/compute hour. 730 hours a month = ~$100/month for continuous uptime. That’s not viable for a personal project.

The move: Build in Replit, then host on Vercel (free tier handles most small apps; paid from $5–10/month), Render, or Railway. You lose nothing in functionality.

Critical timing: Tell the AI before it starts building that the code should be Vercel-compatible. If you wait until after, you may have Replit-specific dependencies to untangle.

Upgrade

Step 1: ChatGPT Architecture Session

Do not open Replit yet. Open ChatGPT or Claude instead.

ChatGPT and Claude aren’t credit-based for planning conversations. You can spend an hour changing your stack twice and it costs nothing beyond your subscription. Replit charges per edit. Use the free tool until you have a complete picture.

The One Prompt That Changes Output Quality

Before asking for any spec or architecture, send this first:

Read more

Table of Contents

• What Are Constraint Prompts

• The Four Core Constraint Prompts

• Anti-Loop & Anti-Drift Prompt

• Clarification-First Prompt

• Surgical Changes Prompt

• Combined Master Prompt

• How to Use These Prompts

• Framework-Specific Cursor Rules

• Universal Cursor Rules Template

• Expected Behavior Changes

• Common Scenarios Prevented

What Are Constraint Prompts

Constraint prompts are guardrails that control AI behavior during coding sessions. Without constraints, AI coding assistants become “enthusiastic over-builders” that:

• Add features you didn’t ask for

• Refactor working code unnecessarily

• Create endless loops of improvements

• Break existing functionality while “helping”

• Continue working after the task is done

With constraint prompts, AI becomes a “focused implementer” that:

• Builds only what you requested

• Preserves existing functionality

• Asks clarifying questions first

• Stops when the requirement is met

• Makes minimal, surgical changes

The Four Core Constraint Prompts

Read more

Previous: Methodology | Back to Hub

Table of Contents

• When to Use Advanced Patterns

• Master Prompt Library

• Testing Without Writing Tests

• Common Problems and Quick Fixes

• Advanced Scenarios

• Production Debugging Patterns

• Working Effectively with AI Assistants

• Essential Tool Stack

• Development Environment Setup

• Deployment Platforms

• Monitoring and Analytics

• Learning Resources

When to Use Advanced Patterns

Use these patterns when:

• You’ve completed the 30-min and 2-hour challenges

• Your project has 3+ external integrations

• You need background processing or scheduled jobs

• You’re building complex state machines

• You need advanced error recovery strategies

Don’t use these yet if:

• You haven’t completed the basic challenges

• Your project is straightforward (1-2 APIs, simple flows)

• You’re still learning the 5-Round methodology

• You’re building your first AI-assisted project

The 5-Round Planning Method works for both simple and complex projects. The difference is in execution, not planning.

Read more

The systematic planning framework that prevents the most common AI building disasters before any code is written.

Most AI builders treat planning like a formality-write a quick prompt, get code, debug later. This works for demos. It fails catastrophically for production.

This methodology flips the model: spend 60 minutes in systematic conversation with AI before writing a single line of code. The result? 23+ hours saved per project by preventing scope creep, architectural mistakes, integration failures, and endless debugging sessions.

This isn’t theory. This is the battle-tested system behind every production-ready AI project in this playbook.

Table of Contents

1. Overview: The Two-Part System

2. The Problem with “Just Describe Everything and Hope”

3. The 5 Planning Rounds Explained

4. What Implementation Phases Actually Do

5. The 5-Step Execution Pattern

Read more