When you’re building in plan mode, Claude works out the plan first for your approval before doing any actual implementation.

You get a high-level view of what Claude Code is proposing before a single line of code gets written. That means you can audit the architecture, push back on assumptions, tweak the scope, and iterate until it actually matches what you want.

Only then does it build.

But why does this matter?

Subscribe now

Why Plan Mode?

After using Claude Code consistently for the past 2 weeks, two constraints keep showing up:

• Credit consumption (Maybe because I’m on the Pro plan.)

• Time for Claude to complete its tasked work

You’re going to face these two constraints no matter what.

If you’re vibe-building and the output goes in the wrong direction, you don’t just lose time. You burn credits. And then you burn more credits fixing what shouldn’t have been built in the first place.

The biggest surprise (in a good way) for me in plan mode is that Claude Code asks genuinely deep clarifying questions. The kind of questions and insights that honestly didn’t even occur to me when I was planning things out.

Not surface-level stuff, but structural questions that make you rethink what you’re actually trying to build. It really forces you to be precise instead of vague-prompting your way forward.

Actual Example: Building a “GTM-Brain”

As a GTM engineer, I’m very interested in building out my “GTM Brain.”

It’s essentially a system that:

• Stores all of my GTM knowledge

• Continuously ingests new knowledge (Substacks, YouTube, operator threads, etc.)

• Distills that knowledge automatically

• Synthesizes it against what I already know

• Surfaces gaps, blind spots, and opportunities in my line of work

My biggest belief in the post-AI world is this:

Most roles can get from 0 → 90% efficiency by leveraging information that already exists, synthesizing it properly, and applying it to their context.

The key missing gap is the collection and synthesis of this data at scale, which is exactly what I’m trying to build my GTM Brain to solve.

Let’s take this as an example.

One thing I’ve always struggled with is: how do I “download” all the GTM information in my head into Claude Code?

I considered a few approaches. Creating a master file with everything I know. Dumping notes into one giant doc. But it quickly felt too manual and way too time-consuming.

When I used plan mode, Claude Code proposed “Option C,” which I really liked.

Instead of trying to write everything down upfront, it suggested running a structured Q&A / interview to capture my actual expertise. Almost like mapping my brain through conversation. Then combining that with my GTM-brain content to deepen topic coverage.

That to me was a solveable bottleneck.

If you’re building workflows, debugging loops, or thinking through architecture, your brain moves way faster than your finger.

That means you need a proper voice dictation setup.

Subscribe now

Choosing Your Voice Dictation Layer

I researched into what’s out there:

• Wispr Flow (paid)

• Superwhisper (paid)

• Spokenly (free)

My pick? Spokenly.

It runs locally. Sets up in minutes. And most importantly, it costs $0.

Spokenly runs a local LLM model on your machine to convert your voice into text w/o any cloud dependency. I’ve tested it, and the model works very fast too.

And it’s free. Which makes it hard to justify paying a monthly subscription just to transcribe your own voice.

The model I use is Nvidia Parakeet TDT 0.6B v3. Lightweight, responsive, and more than good enough for prompting Claude Code all day.

Once you switch to speaking instead of typing, going back feels super slow.

Why?

With Playwright, you are adding browser capabilities unlocks what standard web fetch can’t handle:
→ JS-heavy websites
→ Multi-page scraping/pagination
→ Screenshots
→ Actions that require being logged in to your own accounts
→ Perform actions on websites (such as clicks, form fills etc)

Subscribe now

Use Case of Playwright: Landing Page Analysis

With Playwright, I can analyze the full funnel of a competitor exactly as a real prospect would experience it.

For example: Landing page
→ Click “Submit” on whitepaper (page 1)
→ Fill qualification form (page 2)
→ Reach scheduling page (page 3)
→ Reach confirmation page (page 4)

Playwright can automatically progress through each step, just like a human user. It clicks buttons, fills forms, waits for the next page to load, and captures the resulting state.

At every stage, it extracts and catalogues the page without requiring me to manually go through the funnel.

Playwright over Puppeteer

When working with headless browsers, there are two dominant options:

• Playwright (maintained by Microsoft)

• Puppeteer (maintained by Google)

I went with Playwright over Puppeteer primarily because it has an official MCP server maintained by Microsoft. Puppeteer’s MCP implementation has been deprecated, which makes Playwright the more reliable choice for long-term use with Claude Code.

Official support also reduces the risk of breakage. Deprecated or unofficial MCP servers may stop working, fall behind browser updates, or introduce unexpected issues. Since my workflows depend on consistent browser automation for landing page analysis and funnel extraction, stability is critical.

Note: Playwright spins up a fresh browser instance each time (think of it like a new incognito window), so you can't use your existing browser sessions.

I think this opens up alot of potential in marketing research and data collection.

Handling Playwright Chrome Auth

The main issue I hit with Playwright was authentication.

By default, Playwright spins up a fresh browser profile every run. Think “new incognito window.” Clean session, zero cookies, zero logins.

That’s great for test isolation. It’s terrible for real-world research.

Because if your workflow needs access to anything behind a login (LinkedIn, ad libraries, SaaS dashboards, analytics tools), you end up re-authenticating constantly. Same sites. Same MFA. Same pain.

Then I saw a simple fix:

Make a copy of your default Chrome profile and point Playwright to that copied profile.

Now Playwright launches with an already-authenticated state. Your cookies, sessions, and stored logins persist across runs. You get the best of both worlds:

• Not touching your real day-to-day Chrome profile

• Keeping a stable “automation” profile with persistent auth

• No repeated logins every time you run a script

Subscribe now

Why GitHub Installation Over NPM Registry?

I went with GitHub as Anthropic maintains the official repo.

The npm command being shared (for example from sources like aitmpl.com) is published and maintained by a 3rd party.

With unofficial 3rd party packages, you don’t really know what’s inside unless you audit everything. It could be clean. It could also include extra scripts, telemetry, modified templates, additional dependencies, or code that reads from your environment.

Claude Code is typically granted broad local access. So in theory, an unofficial package executed via npx can:

• Read and write files

• Access .env variables

• Modify project structure

• Execute scripts during install

If I’m giving something that level of access, I’d rather it come directly from the original maintainer than through an extra distribution layer I don’t control.

Installing Anthropic’s Github Repo

The install itself was straightforward.

I pointed Claude Code directly to Anthropic’s official GitHub repo URL and asked it to install the skill from source.

In practice, it was just:

• Clone the repo

• Copy the skill-creator folder into my local .claude/skills directory

• Restart Claude Code

That’s it.

As someone who’s quite deep into AI x Marketing, this feels non-negotiable at this point.

Wanted to share this 0 → 1 journey openly, mainly as a way to document what I’m learning. If it helps other marketers along the way, even better.

Subscribe now

The 2-Week Struggle: Why I Nearly Gave Up

I’ve actually been exploring Claude Code for the past 2 weeks.

Watching videos, reading guides, bookmarking resources. Just... stuck in tutorial mode because the terminology kept confusing me.

Everyone throws around terms like “agents” and “skills” and “hooks” like they’re self-explanatory. They’re really not. Especially when most guides are written for developers, not marketers.

Things finally clicked for me today. So while it’s still top of my mind, here’s what actually helped me break through the confusion.

#1: Claude Code (the tool itself)

What I thought: Some coding platform where I’d need to learn Python or JavaScript.

What it actually is: A system where you build automation workflows using plain English. You’re technically “writing code,” but it’s just markdown files with instructions.

Reality check: The word “code” puts marketers off. But you’re not becoming a developer, you’re just teaching an AI your marketing processes.

#2: Claude Code CLI

What it looks like: That black terminal window you see developers use. All text, no mouse clicks.

Why it matters: Claude Code runs in the terminal. No fancy interface to click around and just typing commands. Feels old-school and I couldn’t really get the hang of this.

The shift: Think of it like typing an email versus filling out a form. More direct, less fuss.

#3: IDE Integration (Cursor, VS Code, etc.)

What it is: IDE = Integrated Development Environment

What they actually are: Optional visual wrappers that sit on top of Claude Code. They give you:

• File trees you can see and navigate

• Prettier formatting for your markdown files

• Mouse navigation if you prefer that

Common options:

• Cursor - Popular in Claude Code circles

• VS Code - Microsoft’s free editor, highly customizable

• Antigravity - by Google

Day 1/30 - What I Did

Step 1: Found the Best Guide Available

After going through dozens of Claude Code tutorials, I settled on Joshua Schultz’s complete guide. It’s over 10,000 words of solid architectural breakdown.

I’ve read a lot of AI guides over the past year, and most fall into two camps: either too surface-level (just showing you what buttons to click) or too technical (assuming you already know how systems work). Joshua’s guide is different.

It teaches you the “why” behind the architecture. I’m not interested in just copying templates—I want to understand how the system thinks so I can build my own workflows. The guide breaks down the hierarchy (Commands → Agents → Skills → Hooks) in a way that actually makes sense. I finally understood why you’d use a Command versus a Skill, and when an Agent is overkill.

Step 2: Set Up Claude.ai Project as My Learning Copilot

Here’s what I did: I uploaded Joshua’s guide into a Claude.ai Project (the web interface, not Claude Code yet).

Why this approach works:

• Claude.ai keeps the entire guide in memory across all my questions

• I can ask things like “How do Commands differ from Skills?” without re-explaining everything

• Basically have an AI tutor that already knows the framework I’m learning

Resources that Helped me Out

1. Nate Herk’s Claude Code Guide:

2. Mark Kashef’s Claude Code Guide: