Today I want to talk about something I recently built inside Claude. It’s a small thing. In fact, just one markdown file. But it changed how Claude works with me on pretty much everything.

If you use Claude (or any AI tool, really) for content work, this might be the most practical thing I’ve shared in a while. I’m going to walk through exactly what I built, why I built it, and how I did it step by step.

I’m also attaching a video walkthrough for those of you who prefer to see the process in action. But the full story is right here.

The thing that kept bugging me

I use Claude for a lot of things. Blog outlines, social media copy, newsletter drafts, email sequences, website copy, content research, brainstorming. It’s my primary AI tool for both my personal brand work and my full-time role at AddSearch.

And for the most part, it’s been great. But there was one pattern that kept frustrating me.

Every time I asked Claude to write something in my voice, the output would feel... off.

The tone would be too polished. Too corporate. It would use words I’d never use. It would add details about my work that were close but not quite right. And the part that really got me? It would confidently present opinions I never had. Not in a malicious way. Claude was just filling in the gaps based on context. And those guesses would sound so reasonable that I’d almost miss them.

So I’d push back. Fix the tone. Remove the jargon. Correct the made-up details. Go back and forth 5-8 times before I had something I could actually use.

Every. Single. Time.

I tried writing better prompts. I’d explain my tone, list my preferences, say “no AI jargon, keep it casual, short sentences.” It would work for that one conversation.

Next chat? Back to square one.

At one point, I asked Claude to write a quick two-line LinkedIn post based on my past opinions. When I looked at the draft, I literally had to ask: “Are those exactly my words, or did you give me these words?”

Turns out Claude had been pulling from its own previous drafts and presenting them as things I’d said.

That was the moment I realized: the problem isn’t Claude. The problem is that there’s no system telling Claude what’s mine and what’s its.

The fix: a Claude skill

If you’ve been following my posts for a bit, you know I’ve talked about building AI systems before. Brand voice documents, product knowledge bases, user language guides, custom instructions. My takeaway from all that work was simple: the tool changes, the system stays.

A skill is the next evolution of that idea.

In simple terms, a skill is a markdown file (called SKILL.md) that we upload to Claude. It contains a set of instructions that Claude follows automatically every time it works on a relevant task. No code. No plugins. No technical setup. Just a simple markdown file with clear rules.

Now, the obvious question: how is this different from just writing a better prompt?

A prompt lives in one conversation. When we start a new chat, it’s gone. We have to re-explain everything. And honestly, we never write it the same way twice, so Claude’s output quality keeps varying.

A skill stays. It activates automatically. We write the instructions once, and Claude follows them every single time.

Think of it like this. A prompt is telling a new colleague what you need every morning. A skill is writing an onboarding doc that they read once and follow forever.

How I actually built a Claude skill

Here’s where I want to go deep, because I think the process matters more than the output. And honestly, it was simpler than I expected.

Step 1: I asked Claude to audit my own conversations.

I have a Claude Project where all my personal brand work lives. LinkedIn posts, newsletters, website copy, and brainstorming sessions. Over time, I’d built up 17+ conversations in there, plus attached files like my brand strategy document.

I told Claude: go through every single conversation in this Project, every file, and help me figure out where I’m spending the most time going back and forth. Where are the friction patterns?

Here’s a detail that matters. Claude’s conversation search can look at two types of content. There are H blocks, which are messages I sent (my thoughts, my opinions, my corrections). And there are A blocks, which are Claude’s responses. For this audit, what mattered most were the H blocks. My words. My feedback. My pushbacks. That’s where the real patterns of frustration live.

Claude went through everything and came back with a clear picture.

Step 2: Claude studied the skill format.

I didn’t know how a SKILL.md file is supposed to be structured. Turns out Claude already has access to example skills in its system. There’s a brand-guidelines skill, a doc-coauthoring skill, a skill-creator skill. Claude studied those examples, understood the format (a YAML header at the top plus markdown instructions in the body), and was ready to build one for me.

I didn’t need to learn any of this myself. That’s the part I want to highlight. Claude understood the structure and translated my needs into it.

Step 3: Claude gave me skill ideas based on my actual friction points.

Based on everything it found in my conversations, Claude proposed about seven different skills I could build. Things like a LinkedIn post drafter, a newsletter builder, a content calendar tracker, and a few others.

I picked the one that I knew would matter most: a personal voice research skill.

Why this one? Because every other skill on the list depends on Claude getting my voice right first. A LinkedIn drafter is useless if Claude is still making up my opinions. A newsletter builder doesn’t help if the sourcing is wrong.

This skill is the foundation. If it works, everything built on top of it works. If it’s broken, nothing else matters.

Step 4: Claude built the SKILL.md file.

This is the part that surprised me. Claude already knew my voice rules from months of conversations. It knew my frustrations, the corrections I’d made, what I liked and didn’t like. It took all of that and produced the complete SKILL.md file.

Here’s what went into it.

The YAML header. At the very top of the file, there’s a small section that looks like this:

---
name: personal-voice-research
description: "Source and fact-check before writing as Rohit. Triggers for LinkedIn posts, newsletters, website copy, emails, DMs, webinar drafts, or any content in his voice. Always activate first."
---

This is the trigger. It tells Claude when to activate the skill. That description field is key. Whenever I ask Claude to write anything in my voice (a post, a newsletter, an email), Claude reads this and knows to follow everything inside the file.

The YAML header matters because without it, Claude wouldn’t know when to use the skill. The name identifies it. The description tells Claude which tasks should trigger it. Get the description wrong, and the skill won’t activate when it should.pe

The three-step workflow

This is the core of the entire skill. Three steps Claude must follow in order. No skipping.

1. Research.

Before writing a single word, Claude searches my past conversations. Not one vague search. 3-4 specific searches using project names, phrases I’ve used, or topic-plus-context combinations. The skill even includes which search strategies work and which ones fail, so Claude doesn’t waste time.

2. Source assessment.

After researching, Claude separates everything into two buckets. Sourced material (things I actually said, opinions I expressed, corrections I made) and generated material (Claude’s paraphrases, inferences, or assumptions). This forces Claude to be honest about what’s mine and what’s its guess.

3. Present and confirm.

If Claude found my past position on a topic, it shows me and asks if my thinking has changed. If it found nothing, it tells me directly: “I didn’t find your past position/opinion on this. I don’t want to put words in your mouth.” Then it asks me specific questions before writing anything.

Voice rules.

The file includes all my non-negotiables. Casual and conversational tone. Short sentences. Simple English. “We” instead of “you” so it sounds inclusive, not preachy. And a strict avoidance list: no em-dashes, no AI jargon like “unlock” or “unleash,” no corporate language, no generic AI-sounding content.

Fact-checking protocol.

Before presenting any draft, Claude verifies factual claims, checks tool names and feature descriptions, and confirms that examples from my work match what I’ve actually described. If something seems off, it flags it instead of silently including it.

Step 5: I uploaded it to Claude.

Here’s the actual process. It’s simpler than it sounds.

Claude generated the SKILL.md file inside our conversation. I downloaded it. On my local machine, I created a new folder, named it “personal-voice-research,” and put the SKILL.md file inside it. Then I zipped that folder into a .zip file.

In Claude, I went to Customize (you’ll find it in the left sidebar below the Search), then to the Skills section. Clicked the “+” button, uploaded the zip file, and that was it.

The skill showed up in my skills list. I toggled it on. From that moment, every conversation in Claude where I ask it to write in my voice follows the rules in that file. Automatically.

One conversation to build it. One zip file to upload. Done.

Did it actually work?

I tested it by asking Claude to write a LinkedIn post about a topic I’d been wanting to cover. Here’s what happened.

Claude searched my past conversations first. Found that I’d listed this topic in a brainstorm session weeks earlier. Surfaced the specific angle we’d discussed. Separated sourced content from gaps. Asked me clarifying questions before writing anything.

The draft came back in my voice. Casual tone. No jargon. No em-dashes. About 95% of the instructions were followed on the first try.

Then I asked Claude to audit itself. “Did you follow all the instructions? Tell me what you hit and what you missed.”

It gave me an honest, step-by-step breakdown. Where it followed the instructions. Where it fell short. It even suggested three improvements to the skill file. That’s when it really clicked. A skill isn’t a finished product. It’s a living document. We use it, find the gaps, improve it. Each version gets better.

If you want to try this

Start with the problem, not the solution. Don’t think “what skill should I build?”

Think “what do I keep correcting Claude on?” That correction pattern is the skill waiting to happen.

Pick the foundational one. If we have multiple ideas, resist the urge to build the most exciting one. Build the one that everything else depends on.

Let Claude do the heavy lifting. We don’t need to learn Markdown or YAML. Give Claude the context (past conversations, files, preferences), tell it what keeps going wrong, and let it draft the skill file.

Test and iterate. The first version won’t be perfect. Use it, ask Claude to audit its own compliance, find the gaps, and update the file.

Have you built a skill yet? Or if you haven’t, what’s the one thing you keep correcting Claude on? That’s probably your first skill right there.

Hit reply and let me know. I’d love to hear what you come up with.

— Rohit

The comments were full of “this is the way” and “WordPress is dead” energy.

And I sat there thinking: was WordPress actually the problem here?

Because if it were ranking pages, converting traffic, and generating revenue, then what exactly are we fixing?

Before I go further, a quick note on where I’m coming from. I’ve spent the last 8+ years working with early-stage B2B SaaS companies. Small teams, limited budgets, and never enough hours in the day. Everything I’m about to say comes from that lens. If you’re at a company with a 20-person engineering team and dedicated DevOps, your constraints are different. But if you’re a marketer at an early-stage company where every hour and every dollar counts, this one’s for us.

The pattern I keep seeing

This isn’t just about WordPress. I see this everywhere right now. People migrating CRMs. Rebuilding websites from scratch. Switching email tools. Rewriting entire workflows. Not because something broke. But because AI made it possible to start over.

And starting over feels productive. It feels like progress. But most of the time, it’s just a very expensive side quest.

Especially when we’re working with limited budgets and small teams. We don’t have the luxury of spending three weeks rebuilding infrastructure. Every hour we spend migrating is an hour not spent on acquisition, conversion, or retention.

The “can vs. should” trap

AI can do a lot of things now. It can build websites. It can write email sequences. It can set up automations. It can manage publishing workflows.

But “can” is not the same as “should.” And more importantly, just because AI can do something doesn’t mean we should hand it the keys.

We’re still the ones making the decisions. AI is the tool. We’re the ones who decide when to use it and when to leave things alone. That’s the part people keep forgetting in the rush to rebuild everything.

The real question is never “can AI do this?” The real question is “is this thing blocking my growth right now?”

If the answer is yes, go for it. Migrate. Rebuild. Go all in!

If the answer is no, close that tab and go work on something that actually moves the needle.

When it actually makes sense to switch

I’m not saying we should never change tools. I’m saying we should have a good reason before we do.

I’ll give you a real example from my own work.

I’ve been running my personal site on Carrd for a while now. It works fine for what it is. But Carrd only supports single-page websites. And I need multi-page. I need separate pages for consulting services, my about section, my projects. I need the site to load faster, be more responsive, and be easier to update without spending hours dragging and dropping elements manually.

Carrd is genuinely blocking what I am trying to build. It isn’t just “not new.” It’s in the way.

Now, a year ago, the obvious move would have been Framer or WordPress. That’s what most people do when they outgrow a simple site builder. But because I’m already in the process of migrating, and because AI can now build and manage sites efficiently, I’ve decided to go a different route. I’m moving to a Claude-built site hosted on Vercel.

Two reasons.

First, as someone who experiments with AI tools every week, this is something I want to try, learn from, and share. It’s part of what I do. Building my site with Claude is a real-world experiment that fits my workflow and my brand.

Second, I’m one person. I don’t want to maintain a WordPress install, deal with plugins, manage hosting, drag and drop page builders. I want to describe what I need in a conversation with Claude, get the files, and deploy. For a solo operator, that’s a better fit.

But here’s the key part. If I already had a Framer or WordPress site that was working well, ranking pages, bringing in traffic, converting visitors, my decision would be completely different. I wouldn’t be migrating. I’d be improving what I already have.

The reason I’m making this move isn’t because AI can build a site. It’s because my current setup genuinely can’t do what I need anymore. That’s a good reason to switch.

When it makes sense to build on top of what we have

Sometimes AI isn’t there to replace a tool. It’s there to make the tool we already use work better.

I run content through WordPress for Overlappr. The CMS works fine. But the publishing process was slow. Formatting documents, uploading images, placing them correctly, and making sure the hierarchy stays intact. It’s tedious, repetitive work.

So instead of ditching WordPress, I built a workflow using Claude Code that takes a Google Doc or PDF, extracts the content with all the formatting, pulls out images, keeps them in the right positions, and publishes the whole thing as a draft in WordPress. One slash command. Done.

I didn’t replace WordPress. I made it easier to work with.

That’s a very different decision from “let me tear everything down and start fresh.”

Three questions before we migrate anything

Every time we see a shiny new AI-powered alternative and feel the urge to switch, there are three questions worth asking first.

1. Is this tool actually blocking growth or revenue right now?

Not “could something else theoretically do it better?” but “is this one actively getting in my way?” There’s a huge difference between a tool that’s imperfect and a tool that’s a blocker.

Imperfect tools can be improved. Blockers need to go. If we have to think hard about whether something is blocking us, it probably isn’t. Real blockers are obvious. They frustrate us daily. They limit what we can do. We don’t need a LinkedIn post to convince us they’re a problem.

2. What’s the real cost of switching?

Not just the money. The time. The learning curve. The things that will break during migration. The momentum we lose on actual growth work while we’re busy rebuilding infrastructure.

For early-stage teams, this cost is massive. Three weeks spent migrating a CMS is three weeks of zero progress on the things that actually grow the business. We have to be honest about that trade-off before we commit.

3. What would we do with that time instead?

This is the one most people skip. If migrating takes three weeks, what revenue-generating work are we not doing for those three weeks? Is the migration worth more than three weeks of growth work? Sometimes the answer is yes.

But we should at least ask the question. Because often, the best use of our time isn’t rebuilding infrastructure. It’s doing the boring, unglamorous growth work that actually brings in revenue.

Experimenting is not the same as rebuilding

Here’s where I want to be careful. Because I don’t want this to sound like “don’t try new things.” That’s not my point at all.

I spend 2-3 hours every Thursday testing AI tools. I try new workflows, break things, and share what I learn. Experimenting is how we stay sharp. I’m all for it.

But there’s a big difference between experimenting with a tool on a Thursday afternoon and ripping out your entire tech stack on a Monday morning.

Experimenting is low cost, low risk, high learning. We try something, see if it works, and move on if it doesn’t.

Rebuilding is high cost, high risk, and the learning only happens after we’ve already committed weeks of work.

The skill isn’t knowing what AI can do. Everyone knows what AI can do. Our LinkedIn feeds won’t let us forget.

The skill is knowing when to let it and when to leave things alone.

The boring answer is usually the right one

Building on existing systems that work is boring. Nobody writes viral posts about “I kept my WordPress site and just improved my publishing workflow.”

But boring pays the bills.

The companies that grow aren’t the ones with the coolest stack. They’re the ones who spend their limited time on things that actually matter.

So next time we see a post about someone rebuilding everything with AI, the question isn’t whether AI can do it. AI can do a lot of things. The question is whether we should let it. Whether this is the right use of our time, our budget, and our energy right now.

Save the bold migrations for things that are genuinely holding us back. Not things that are working fine, but don’t look modern enough.

We have limited time. Let’s spend it on what makes money, not on what makes a good LinkedIn post.

And if you see things differently, I’d love to hear your take. This is how I see it from years of working with small teams and tight budgets. But I’m always open to a good conversation about it.

— Rohit

And now, on top of all of that, we’re expected to figure out which AI tools belong in our workflow, while keeping up with approximately 47 new AI launches every Tuesday.

I’ve been a marketer for over 9 years. Someone who believes that staying curious about new tools is part of the job. I’ve spent the last few months dedicating every Thursday to learning and testing AI tools, 2-3 hours, no agenda except to understand what’s actually useful and what’s just noise.

And after all that testing, the biggest thing I’ve learned has nothing to do with which tool is best.

It’s about the question you ask before you touch a task.

Most marketers are trying to solve the wrong problem. They’re asking “which AI tool should I use for this?” when the real question is: should I automate this, delegate this, or keep it for myself?

That one question, asked before you start, changes everything. It’s the difference between being productive with AI and just being busy with it.

Why most of us get this wrong

The overwhelm is doing something specific to how we think about AI. It’s pushing us toward two very different, very wrong extremes.

The first extreme: automate everything. If AI can touch it, let AI handle it. The output ends up mediocre, you spend more time fixing AI’s work than doing the work yourself, and you slowly stop trusting the whole thing.

The second extreme: do everything yourself. You feel in control of the quality. But you’re spending your hours on work that a properly set-up AI system could handle in a fraction of the time. You’re busy, not productive. There’s a difference.

Both extremes cost you something real. One costs you quality. The other costs you time and leverage.

The fix isn’t a better tool. It’s a better framework for deciding what kind of task you’re actually looking at before you start.

The 3 buckets for AI-first marketers

1. Automate

Automation is for tasks that are repetitive, trigger-based, rule-following, and don’t require your judgment every time they run. You set it up once, define what the output should look like, and it runs without you. Your job shifts from doing the work to reviewing the output.

The clearest test: can you write down every step in the process without needing to make a judgment call midway? If yes, it’s a candidate for automation. If the right answer changes depending on context, you’d need to read and interpret each time, it isn’t.

One thing worth saying clearly: automation is not the same as using AI. Automation means the process runs without you. Sometimes AI is part of it. Often, it’s just workflow tools connecting systems together. Don’t conflate the two.

2. Delegate

Delegation is for tasks that need skill, depth, or consistency you either don’t have or genuinely shouldn’t be spending your time on.

A useful filter here comes from Silvi Spector’s AI Systems for Marketers course I’ve recently completed: delegate when it’s the TUTOR. Ask if the task is

Time-consuming,

Un-automatable,

Teachable,

Organizable into a process,

and Reviewable.

If yes to most of those, it belongs in your delegate bucket, not on your own plate.

Delegation comes in two forms, and they work very differently.

Delegating to humans means sending work to someone with the skills or capacity you don’t have. Freelancers, contractors, specialists. The question is always the same: is the cost of me doing this in time, quality, or the mental load of carrying it, higher than finding the right person?

Delegating to AI systems is different. This is where you invest time upfront building something that consistently does execution-level work without you having to redo the setup each time. A Claude project loaded with your brand voice, product knowledge, and writing standards. A research workflow where AI synthesizes, and you interpret. A feedback project that reviews content against your standards before it ever reaches you.

The critical difference between this and automation: when you delegate to AI, you are still in the loop. Every time. This is what “human in the loop” means in practice, and for marketing work, it’s non-negotiable.

Marketing is not just about producing outputs. It’s about shaping how a product, service, or brand is perceived. That requires human judgment that’s grounded in context, what the business needs right now, what the positioning actually means, what the product can and can’t do, and how the customer thinks and talks. AI doesn’t have that. It works from what you’ve given it. The human in the loop isn’t a safety net. It’s what makes the output actually useful.

The line between delegation and automation gets blurry when you do the same type of AI delegation repeatedly. Honestly, that’s fine. The distinction that matters is whether you’re still providing live judgment and context. If yes, it’s delegation. If the process runs on a trigger without your input, it’s automation.

3. Keep

Keep is for work where your specific presence, judgment, relationships, strategic thinking, and taste are the whole point.

Not tasks you haven’t figured out how to delegate yet.

Tasks where handing them off changes the output in a way that actually hurts.

The question isn’t “is this important?” It’s “is my specific involvement what makes this valuable?”

What I actually automate

I want to be specific here because most content about AI and automation talks in abstractions. This is what’s actually running right now.

Blog publishing flow: Content moves from approved draft to formatted, structured, and scheduled post in WordPress, without me manually handling each step. Setup took time. Ongoing investment is close to zero.

Social listening and Slack alerts: Keyword tracking across Reddit, LinkedIn, and other platforms. When a relevant post gets tracked, I get a Slack notification. I go engage manually. The monitoring is automated. The human response isn’t.

Meeting notes and task extraction: After any recorded meeting, the transcript gets processed automatically. Notes are structured, action items extracted, and landed in the right place. What happens with those tasks - prioritization, follow-through, that’s mine.

Campaign reporting pulls: Raw data from Google Analytics, ad platforms, gets pulled and structured on a schedule. I review and make decisions.

What these share: trigger-based, rule-following, measurable output, no judgment required mid-process.

What I delegate

Delegating to humans

It is about knowing your zone and respecting its edges. Technical work that requires engineering depth. Design that needs real creative judgment. Copywriting when you need a genuinely fresh perspective. If the cost of doing it yourself, in time, quality, or the cognitive weight of carrying it, is higher than bringing in the right person, that’s your answer.

Delegating to AI systems

It is where I spend most of my setup energy, because, done properly, the leverage is significant. A few examples:

1. Email copy with brand context loaded in Claude.

I have a Claude project set up with AddSearch’s brand voice document, product knowledge base, and user language guide. For any email draft, I give Claude the specific context for that piece: who it’s going to, funnel stage, goal. It drafts. I refine and approve. The cognitive heavy lifting is no longer mine. The final judgment always is. That’s the human-in-the-loop dynamic working correctly.

2. Keyword research via Keywords Everywhere MCP.

Instead of switching between tools, pulling data, copy-pasting it back into a document, I pull keyword data directly inside Claude. The retrieval is delegated. The analysis of which keywords matter for our strategy, what to prioritize, stays with me.

3. Content feedback project.

A Claude project with my writing guidelines, brand voice, and quality standards. Before content reaches me for final review, it goes through this project first and comes back with specific notes based on my actual standards, not generic suggestions. By the time it reaches me, the obvious issues are already addressed.

4. Research synthesis.

When I need to understand a topic quickly, a competitor’s positioning, a new channel, or an industry trend, I gather sources and let Claude structure the key insights. I review what came out, decide what’s relevant, and take it from there. The reading and pattern-finding is delegated. The strategic interpretation is mine.

In every one of these, I’m still in the loop. That’s not a limitation. That’s the design.

What I keep

Some work should never leave your hands. Not because you can’t technically delegate it, but because your presence is what makes it matter.

Final review on anything that goes out under my name or the brand. I review, I approve, I own it. The accountability can’t be delegated without quietly shifting something important.

Client and founder conversations. The relationship is the point. AI helps me prepare and follow up. The conversation itself stays with me.

Prioritization and business context. This one is underrated, and I keep it very deliberately. Deciding what to work on requires context that AI simply doesn’t have.

What did I hear in this week’s leadership conversation? Where is the business actually trying to move right now, versus what’s written in the roadmap? Where can I personally add the most impact this quarter, given what I know about our team, our gaps, and our goals?

That kind of prioritization happens through real conversations, with my manager, with the team, through my own sense of what matters. It changes weekly. It’s not static enough to systemize, and it shouldn’t be. Outsourcing your prioritization is outsourcing your ability to think strategically about your own role.

Forming real opinions. When I read something new, I form my own view before sharing it. The thinking is the point. That’s not something I want AI to pre-digest for me.

One thing worth saying: most real work doesn’t sit cleanly in one bucket. It spans all three. My content workflow, for example: research gets automated, first drafts are delegated to AI with me in the loop throughout, and the decisions about what to publish, when, and how to frame it are kept. The framework isn’t about labeling entire projects. It’s about being intentional at each step.

A quick diagnostic

Take the last ten tasks you worked on this week. For each one, ask:

• Was my specific judgment the point of this task? → Keep

• Could someone with the right skills or the right AI setup do this as well as me? → Delegate

• Is this repetitive, trigger-based, and measurable without ongoing judgment? → Automate

You’ll probably find you’re doing a lot of Keep work that should be delegated, and a lot of Automate work you’re still doing manually out of habit.

That’s not a personal failing. It’s just an unexamined workflow.

Where and how to start

The framework is easy to understand. The hard part is making it a reflex before you touch a task, not something you think about afterwards.

A few things that actually help:

Run a weekly task audit. At the end of each week, look back at your task list through these three buckets. The patterns show up quickly. You’ll see what’s eating time that shouldn’t be.

Start with one of each. Pick one task this week that’s clearly automatable and set it up properly. Pick one that belongs in the delegation and hand it off. Don’t overhaul everything. Just move two things.

Use Claude to do the first pass. Drop your weekly task list into Claude, share the three-bucket framework, and ask it to categorize what you’ve been doing. You’ll get a structured starting point fast. Then apply your own judgment to refine it. The AI does the sort. You make the calls.

When prioritization decisions feel unclear, talk to a human. Your manager. A senior colleague. Someone who’s been in the room longer and has seen what actually moves things. The framework gives you the lens. Experience and real business context tell you where to point it.

If you’re working through this and something doesn’t fit cleanly, reply and let me know. I’m happy to think it through with you.

If this was useful, share it with someone who’d get something out of it.

— Rohit

Subscribe now

'Hasty generalization.'

Something I learned yesterday that explains why AI treats your product like every other tool in your category.

And it changes how I think about brand visibility.

I was testing ChatGPT on a few different SaaS products. Asking it to describe what they do, their features, how they work. Just to see how accurate it is.

And it kept getting things wrong. Not wildly wrong. Just slightly off.
Describing features that don't exist.
Mixing up what one product does with what a competitor does.
Confidently stating things that aren't true.

So I pushed back. I told it, that's not right. Why did you say that?

And ChatGPT gave me an honest answer. It said:

"I generalized from how most [category] tools work instead of verifying exact features."

Read that again.

When AI doesn't know enough about your product specifically, it fills in the blanks from what it knows about your category.

Calendar tool? AI assumes it does what most calendar tools do.
Search platform? AI assumes it has the features most search platforms have.
Email tool? You get the idea.

And that's a big problem!

Look at most SaaS websites right now. Everyone says "powerful." Everyone says "seamless." Everyone says "all-in-one." Everyone says "AI-powered."

When our messaging sounds exactly like our competitors, we're basically telling AI: "Yeah, we're the same as everyone else."

So when a potential customer asks ChatGPT about our product, they get a generic category description with our brand name slapped on it.

Not because AI is broken. But because we never gave it a reason to think we're different.

So what do we do about it?

→ Be weirdly specific. Don't just say what we do. Say what we don't do. AI fills gaps with assumptions. If we leave gaps, AI will fill them with what's typical for our category. Close those gaps before AI fills them for us.

→ Draw clear lines in our content. Write stuff that explicitly says "unlike most tools in this space, we work differently because..." Give AI something concrete to latch onto instead of defaulting to patterns.

→ Ask AI about our product. Regularly. Go ask ChatGPT, Gemini, Claude what our product does. If the answer sounds incorrect, we need to review what's out there about our product and where AI might be pulling from.

--

This was just one of the things I learned. Will share more learnings soon.

And before anyone checks my website and @ me with "practice what you preach." - yeah, I know! There's stuff on there that needs updating, and I'm on it.

- Rohit

I’m not a developer. I’m a marketer. With no coding knowledge. But I was curious enough to try.

So I did. And in one sitting, I built a WordPress Post Publisher that automated a docx file to the WordPress draft publishing workflow.

Recommended: Watch this walkthrough video to see how I built it step by step.

The Why?

I run marketing at AddSearch. One-person team. I handle campaigns, SEO, blog content, emails, webinars, social, with some external resources.

The blog keeps falling behind. Not because the content isn’t ready. It is. The bottleneck is getting it into WordPress. Formatting headings. Adding links. Uploading images. Saving drafts. It’s repetitive, manual, and it eats time I don’t have.

So I asked myself: can I try using Claude Code to skip the manual part and just push content straight to WordPress without losing the formatting?

I decided to treat it as an experiment.

Brainstorming with Claude Before Touching Claude Code

I didn’t jump straight into Claude Code. I’m not that brave (yet).

I started with regular Claude. Explained my situation:

“I have a WordPress site. I want to automate pushing blog content to WordPress as drafts. I’m not technical. Is this possible without writing a lot of code?”

Claude said yes. Then it gave me clear next steps to open Claude Code and give detailed instructions on what I’m trying to build, what features I require, and how the functionality should be.

That was it. I then followed the steps it provided for my side project’s WordPress website, Overlappr.

The lesson here? Give Claude clear context. Tell it who you are, what you’re trying to do, and why. The better you explain your situation, the better it helps you.

Getting My Prerequisites Ready

Before I let Claude Code do anything, I needed two things:

1. A WordPress Application Password. I went to my WordPress admin, Users > Profile, scrolled down, created an Application Password. Took 30 seconds. Done.

2. A rough list of what I wanted. Nothing fancy. No formal document. Just a mental checklist:

   • Push content to WordPress via API

   • Always save as draft (never auto-publish. I’m not that trusting)

   • Support Word docs and PDF files

   • Keep headings formatting (H1, H2, H3) intact

   • Preserve hyperlinks with their anchor text

   • Extract images and upload them to WordPress

   • Don’t break the formatting

Having this list ready before starting was the move. When you know what you want, the AI knows what to build. When you’re vague, you get vague results. Simple.

Giving Claude Code Instructions. Plan Mode First.

Here’s something I learned that I think is worth sharing.

Claude Code has something called Plan Mode. Instead of jumping straight to writing code, it researches your problem, designs an approach, and shows you the plan first.

Think of it like this: you wouldn’t start renovating your kitchen without looking at the floor plan first.

I used Plan Mode. Claude Code showed me:

• What files it would create

• How the system would work

• What tools it would use

I reviewed it. Asked a couple of questions. Said “looks good.” Then it started building.

This step gave me confidence. I’m not a developer, and I didn’t want to blindly approve things I couldn’t understand. Plan Mode made the whole process feel like a conversation, not a gamble.

The Build. Where Claude Code Did Its Thing.

Once I approved the plan, Claude Code got to work:

• Created a Python script for the WordPress connection

• Created a config file for my credentials

• Installed the packages it needed (automatically)

• Asked me for my WordPress username and application password

• Updated the config file for me (I didn’t want to touch the code)

• Tested the connection to my site

Connection test: passed on the first try.

One thing I appreciated: Claude Code asks for permission before running commands. It doesn’t just go rogue. Every step, it showed me what it was about to do, and I could say yes, no, or “wait, explain that.”

If you’re not sure about something, just ask. It’ll explain. No judgment. It’s literally an AI. It doesn’t get impatient.

Quick Note: Don’t Do This on Your Live Site

I want to pause here because this matters.

If you’re experimenting with any new tool, Claude Code or anything else, use a staging environment. Or at minimum, make sure your automation can’t accidentally publish something to production.

Things break when you’re learning. That’s normal. Just make sure they break somewhere that doesn’t matter.

I also made sure everything was set to draft only. No auto-publishing. Nothing goes live without me manually hitting publish in WordPress.

First Test. A Text Blog Post.

Time to see if this thing actually works.

I gave Claude a topic: “How to Schedule Meetings Across Time Zones.”

It wrote a full blog post. Headings, paragraphs, a CTA at the end, the works. I read through it, made a small tweak, and said: “Push it to WordPress.”

It ran. A few seconds later:

Draft created successfully!
Edit URL: overlappr.com/wp-admin/post.php?post=732&action=edit

I opened WordPress. There it was. Title, formatting, links. All correct. Saved as draft. Ready for me to add images, check SEO, and publish.

From “give me a topic” to “it’s in WordPress”: one conversation.

I won’t lie, I did a little fist pump.

Making It Repeatable. The Slash Command.

The first test worked. But I didn’t want to explain the whole process to Claude Code every time I had a new post.

So I asked: “Can you create a slash command called /wpdraft that I can reuse?”

It did. Now my workflow is:

1. I write content (or Claude writes it)

2. I review the draft

3. I type /wpdraft

4. It’s in WordPress

Three steps. No formatting. No copy-pasting. No uploading images manually.

This is the part where I felt like I actually built something. A tiny automation that saves me real time, every single week.

Note from Claude Code Docs: Custom slash commands have been merged into skills.

Adding Document and Image Support

The text workflow was great. But let’s be real. Most of my blog posts already exist in Google Docs. I wasn’t going to re-type them for Claude.

So I asked: “What about DOCX and PDF files? Can you process those too?”

Claude Code added full document support. And then I asked it to handle images too. Here’s what it does now:

• Headings: Extracts H1, H2, H3 hierarchy from the document

• Paragraphs: Preserves formatting. Bold, italic, underline.

• Hyperlinks: Extracts every link with its correct anchor text (this was important to me)

• Tables: Converts them to proper HTML tables

• Images: Pulls them out of the document and uploads them to WordPress Media Library

All automatic. All from one slash command.

Testing With a Real Document

Theory is nice. Let’s see it work.

I had a real blog post ready: “Top 7 Chrome Extensions for Google Calendar.” A docx file with images, links, headings, the full package.

I shared the file. Typed /wpdraft.

Claude Code processed it:

• Extracted 3 images

• Uploaded all 3 to WordPress Media Library

• Preserved all hyperlinks with anchor text

• Converted all headings correctly

• Created the draft in WordPress

I opened WordPress. Everything was there. The images. The links. The formatting. All sitting in my drafts, waiting for me to add a featured image and hit publish.

That was the moment it went from “cool experiment” to “I’m going to use this every week after some rigorous testing.”

What My Workflow Looks Like Now

When I want Claude to write:

Me: “Write a blog post about [topic]”
Claude: writes draft
Me: reviews, gives feedback
Me: /wpdraft
Done.

When I already have a document:

Me: shares .docx file or .pdf file
Me: /wpdraft
Done.

Next, I open WordPress, add a featured image, verify SEO settings, and publish. The formatting grunt work? Gone!

Three Things I’d Tell You Before You Try This

1. Start with staging. Not production. Seriously.

I know I already said this, but it’s worth repeating. When you’re experimenting with new tools, things will break. Maybe not today, maybe not tomorrow. But eventually, something won’t work the way you expect. Make sure it breaks somewhere safe.

2. Starting is easier than you think. But give yourself room to learn.

You don’t need to be a developer. You don’t need to “understand Python.” You need to open Claude Code, explain what you want, and follow along. That said, watch a few YouTube videos, attend Claude Code 101 webinars, read the docs a bit. You’ll pick it up faster than you expect. But don’t wait to feel “ready.” You’ll learn more in one real session than in ten hours of reading about it.

3. Look at your own daily work. That’s where the opportunities are.

Don’t start by asking “what can AI do?” That’s too broad. Instead, look at your week. What do you keep doing manually? What tasks feel the same every time? What’s boring but necessary?

That’s your starting point. For me, it was getting blog content into WordPress. For you, it might be formatting reports, sending follow-up emails, or pulling data from spreadsheets. The pattern is the same: if you do it repeatedly and manually, there’s probably a way to automate it.

That’s it. Simple conversational flow, no code written by me, and the most annoying part of my content publishing workflow is handled.

If you’re a non-technical person like me, wondering if tools like Claude Code are worth trying, they are. Pick one small, boring, repetitive task. See what happens.

Worst case, you learn something. Best case, you get your Groundhog Day moment to stop repeating.

So when AI tools started getting serious beyond "help me rewrite this paragraph", I assumed it wasn't for me.

I write copy. I run campaigns. I don't live in a terminal.

Then I actually tried it. And it turns out, you don't need to be technical. You just need to be willing to break things and learn as you go.

And this newsletter is me sharing what I wish I'd known earlier.

If you’re a marketer who keeps hearing about AI but feels unsure where to start, this is for you.

Why I’m writing this

At first, AI helped me in small ways. Cleaning up copy. Editing content. Improving clarity and tone. That alone was useful.

But things really changed when I started trying AI for actual marketing use cases. Building small tools. Automating workflows. Solving specific problems instead of just playing with prompts.

Tools like Claude, Loveable, n8n, and recently Claude Code made me realize that AI is very useful for non-technical folks like marketers if you approach it the right way.

While learning, I kept notes for myself. What worked. What didn’t. Where I got stuck. Where I wasted time.

That’s when I thought it might be useful to share these notes publicly. Not as expert advice, but as real experiments from real marketing work.

This newsletter is me learning in public.

What this newsletter will actually be like

This is not an AI news roundup.
This is not a list of shiny tools.
This is not filled with AI jargon.

Here’s what you’ll find instead:

• Real marketing problems I try to solve using AI

• The exact setup I use and why

• What worked and what failed

• Simple explanations from a marketer’s point of view

• Examples from my own work or from people in my network

Most issues will focus on one use case at a time. One problem. One approach. One learning.

If you work in B2B SaaS, growth, or marketing and want practical AI use cases without the noise, this is for you.

How I’ll share these notes

For now, I plan to publish weekly.

Each issue will be a short set of notes around one idea or experiment. Sometimes it will be text. Sometimes it will include a video walkthrough or screen recording showing what I tried and how it turned out.

I won’t publish just to keep a schedule. If there’s no value, I won’t send it.

What I hope changes for you

My main goal is simple.

I want non-technical marketers to feel less scared of AI tools. Especially tools that look complex at first, like Claude Code or workflow automation tools.

You don’t need to understand everything to start. You just need a place to begin and a reason to try.

If this newsletter helps you try one tool, test one workflow, or look at AI with a bit more confidence, it’s doing its job.

Thanks for being here early.

Share Rohit’s AI Marketing Notes

If you try something I share and it doesn’t work, comment and tell me. If you’re stuck, ask. If you want me to try a specific use case, let me know.

See you soon,

Rohit