For years I believed the template was the answer.

Use a structure. Follow the framework. Pick the writers you admire and reverse-engineer how they do it. The advice made sense — consistency, clarity, repeatability. So I built templates. Then I found better templates. Then I borrowed frameworks from writers whose work I admired and mapped my ideas onto their shapes.

And the information wasn’t bad. It was boring and incomplete.

I love to paint but a trained painter I am not. And for years I would use those paint by numbers kits. You know the ones — printed canvas, numbered sections, every color pre-assigned. They even give you brushes. Generic ones, but brushes.

At first it’s frustrating. Staying inside all those tiny little spaces. Then it gets efficient. Then it gets robotic. You’re not being creative — you’re just the person following the numbers.

That’s what the template was doing to my writing process.

The real problem wasn’t that the ideas were bad or the content was weak. It was that my articles were missing the best parts — the lessons, the snafus, the messy parts.

Most writing advice lives at the endpoints. Here’s the problem. Here’s the output. A to D, clean and straight.

Nobody shows you B and C.

What Happened When I Handed AI the Blueprint

Every week I would sit down to “write” the article.

I’d hand AI the brain dump — the build log, the experiment notes, some random thoughts I’d captured through the week. And from that pile of raw material, it would outline and draft the article. Based on the template.

Here’s what I didn’t notice for a while: the information was getting pared down to fit the tidy little spaces. The riffs didn’t make it in. The creative insights got smoothed over. The “oops, here’s where it went sideways and here’s how I adjusted” moments — gone. And the real failures? The ones rooted in my own mindset? Those definitely didn’t survive the template.

It wasn’t robotic. It wasn’t sloppy. You couldn’t look at it and say “an AI wrote this.”

But it was missing the only thing that made it worth reading — the experiences that only someone going through it could articulate. The part where I second-guessed myself at step three. The detour that turned out to matter more than the destination. The small realization that only shows up when you’re in the middle of something messy and paying attention.

The template didn’t know those parts existed. So it left them out.

The Better Template That Still Didn’t Work

So I did what made sense. I went looking for a better template.

I pulled some of my favorite writers. The ones whose articles felt effortless to read, whose structure seemed to carry you forward without you noticing. I asked AI to help me analyze what they were doing and build something better. Maybe it was a flow problem. Maybe the gaps just needed different sections.

Same thing happened.

I’d finish a draft and find myself rewriting large chunks of it. Not because the words were wrong exactly — but because they weren’t landing on the things that actually happened. The real texture of the experiment. What I was actually feeling at step three when it wasn’t working the way I expected. The adjustment I made that wasn’t in any plan but turned out to matter.

The words were there. They just weren’t making the cut.

And that’s when I finally looked at the right problem.

It wasn’t the structure of the template. It wasn’t the writers I was borrowing from. Templates don’t work for the way my creative process works — and more importantly, they don’t have room for the things that happen between step one, step two, and step three. The pivot that only makes sense if you were there. The failure that wasn’t a failure, it was information. The moment where the whole direction shifted because of something small that a template would never think to ask for.

That’s not a gap you can restructure your way out of.

Structure Isn’t a Template — Here’s the Difference

So I ditched the templates.

And then I just sat there.

Because the templates weren’t just a writing problem — they were also my process. Without them I had a pile of raw material and no clear path through it. I still needed to get from the brain dump to a published article without spending three times as long rewriting everything. I still wanted AI in the mix. I just needed it to stop making decisions that weren’t its to make.

That’s when I realized I’d been confusing two things that aren’t the same.

Templates and structure. I’d been using them as interchangeable words for the same idea.

They’re not.

A template tells you what goes where. Section one is this. Section two is that. Hit these beats in this order at roughly this length. It’s a paint by numbers canvas — the decisions are already made before you sit down.

Structure is different. Structure is just a flow of information. A guide, not a cage. You still know where you’re going. You just get to find your own way there.

The messy middle — the detours, the pivots, the things that only make sense because you were in them — those fit inside structure. They never fit inside a template.

And if you’ve ever handed a process over to a framework and wondered why the result didn’t feel like you — you already know what I’m talking about.

You’re Not Doing It Wrong. You’re Using Someone Else’s Process.

For as long as most of us can remember, we’ve been taught to follow the blueprint.

Funnels. Frameworks. Content templates. Launch sequences. There’s a proven path for almost everything in business — and following it is how you get results. Do X, then Y, then Z. Hit these steps in this order. Success is a system.

And for a lot of people, it works. The map gets them where they’re going.

But what about the ones whose minds need to work through things differently? What about the off-roads — the detours that don’t show up on the map but turn out to matter? What about the person who learns by going sideways first, or needs to feel their way through the middle before the beginning makes sense?

The map still gets everyone to the same place, technically.

It just doesn’t account for how some of us actually travel.

And borrowed confidence — following someone else’s proven path — looks exactly like best practice right up until the moment you notice what it cost you to get there.

How to Know When a Template Is Working Against You

So how do you know when a template is working for you — and when it’s working against you?

Start here. These aren’t a framework. They’re just honest questions worth sitting with (and a few simple one-line prompts) to help you think it through.

Does finishing the draft feel like something you would say or do? If it’s not reflecting the whole story, you need to ask yourself why it feels off and if it helps or confuses the audience.

Are you rewriting large sections after the draft is done? Not polishing. Rewriting. If you’re regularly putting back parts that got cut to fit the template, the template is editing your voice. And your audience will see that.

Does the output sound like you — or like a version of you that cleaned everything up? There’s a difference between clear and sanitized. If you read the draft out loud and it doesn’t feel like you, chances are it’s not.

If any of those land, you’re not doing it wrong. You’re just working with a tool that was built for someone else’s process.

The next step isn’t finding a better template. It’s figuring out what structure actually fits how your mind works — and that looks different for everyone.

My brain has always run at full speed. Some people call it ADHD tendencies. I prefer to think of it as superdrive.

For as long as I can remember, someone was telling me to focus, slow down, do one thing at a time. Teachers. Managers. Myself, on a good day.

Now I use AI daily, and honestly? It can be just as scattered. There’s no one to rein me in when a session goes sideways — when I’ve asked four different questions, chased three tangents, and somehow ended up somewhere completely unrelated to where I started.

Until I built myself a mirror.

It started with an article from Mia at . Her framework is smart — she breaks down what’s actually hiding inside every AI session and makes a compelling case that most of us save the wrong thing. We file the polished draft and lose the moment our thinking actually shifted.

She’s right. But I was sitting here building something slightly different, and I think it’s worth naming why.

Mia’s framework asks: what did the session produce worth keeping?

The thing I kept bumping into was a different question: was I clear, honest, and focused going in?

Those are not the same problem.

I spent a session this week designing a debrief process. It started as “let me capture AI breakthroughs” and wandered through Mia’s hierarchy, through knowledge systems, through Obsidian structures — until I stopped and said out loud: we’re thinking about this all wrong.

What I actually wanted wasn’t a knowledge capture system. It was a mirror.

Something that would show me, at the end of a thinking session, how I showed up. Did I have too many asks going at once? Did I drift off on a tangent that went nowhere useful? Was I actually thinking something through — or was I using the conversation to avoid deciding?

That’s not a breakthrough journal. That’s a coaching log.

Here’s the distinction that crystallized for me:

Mia’s framework is output-oriented — it helps you extract what the session produced.

What I built is input-oriented — it helps me evaluate how I used the session.

Both matter. They’re just solving different problems.

The output framework catches the breakthrough after it happens. The input framework catches the bad habit before it becomes a pattern. And for those of us who use AI daily as a thinking partner, the input side is where a lot of invisible time gets lost — not to bad tools, but to unfocused sessions, validation loops, and scope creep that looks like productivity.

The debrief I landed on is simple. At the end of a general thinking session, Claude observes five things: how focused the session was, whether tangents were useful or distracting, whether I was thinking or seeking validation, whether it reached a real conclusion, and whether the complexity matched the actual size of the problem.

Then I react. Then we write one or two sentences — the honest version — and I log it in Obsidian.

No elaborate capture system. No tagging taxonomy. Just a running record of how I think, so the patterns can eventually show themselves.

I won’t know what my patterns are for a few weeks. That’s kind of the point.

If you’re a daily AI user, you probably already have some version of Mia’s problem — great sessions that evaporate because you didn’t catch what shifted. Her debrief prompt is worth using.

But if you’ve also had that feeling of closing a tab and realizing you can’t quite account for the last 45 minutes — that’s the other side of the same issue. Not what you failed to save. How you showed up in the first place.

That’s worth paying attention to too.

If this resonates, here’s a short prompt to start your own end-of-session habit:

“Look back at this conversation and tell me: how focused was I, did I go on any tangents, and was I actually thinking or just seeking validation?”

Paste it at the end of any session that felt a little sideways. See what comes back.

And if you’re finding your AI sessions are doing more wandering than working, that’s exactly what I help with. Book a session today.

P.S. If you haven't read Mia Kiraki's original piece on catching AI breakthroughs, it's worth your time. Her framework is what sparked this one. Read it here.

If you missed the first two parts of this series, here’s the short version: I built a Google Apps Script to triage my inbox into three folders — Action Items, Read Later, and Noise — so I could stop treating email sorting like a productivity win and start dealing with the thing underneath it: the compulsive checking, the constant context switching. Part one covers the concept. Part two covers the build. This one is about what happened during testing — and what I kept getting wrong.

The script was running. Emails were moving. And I was still opening my inbox every hour or so to check on it.

Not to take action. Not because something felt urgent. Just to watch. To make sure it was doing what I told it to do.

That’s the moment I should have caught myself. I’d handed off the job — and then immediately started looking over its shoulder.

When Two Tools Are Running and Neither Is Enough

When the script wasn’t sorting things right, my first instinct was to run the same instructions through CoWork and see if it could do better. It could, in a way. CoWork read context well. It pulled from my Stripe customer list, identified who actually needed a response, and — this was the part that surprised me — it could explain why it was categorizing something the way it was.

But it couldn’t label. Couldn’t archive. Couldn’t do the actual mechanical job the script was built to do.

So for a stretch, I had both running. CoWork doing the reasoning. Google Script doing the moving. Two tools covering for each other’s gaps.

That’s not a solution. That’s a workaround.

And it told me something: the script wasn’t the problem. The instructions were.

The Brief Was the Problem, Not the Script

I’ve been hired as a consultant with ambiguous instructions. More than once.

It doesn’t just frustrate you — it makes it impossible to do the job well. You deliver something, and it’s wrong, but not because you’re bad at the work. The brief was bad. You built exactly what you were asked to build. It just wasn’t what they actually needed.

That’s what I did to my script.

I gave it instructions that were clear enough to get started but not specific enough to get it right.

When emails landed in the wrong folder, my instinct was to pull everything back and handle it myself. What I should have done was look at the instructions and figure out where they weren’t clear enough.

The other side of that analogy matters too. When you hire someone — or something — for their expertise, you have to trust that the expertise can do the work. Hovering doesn’t improve the output. It just signals that you didn’t actually hand off the job.

What I Actually Fixed

So I stopped looking at what the script was doing and started looking at what I’d told it to do.

I took CoWork’s reasoning — how it was categorizing, why it was making the calls it made — and fed that back into Gemini alongside the current script. Here’s what this tool understands about context. Here’s what it’s getting right. Now fix the script to match.

I added the Stripe customer list so the script had the context it was missing. Names and email addresses it could recognize, not just patterns it was guessing at.

I dropped the hourly recap entirely. It felt like a safety net — proof the system was working — but it was just noise. Subject lines and folder names with no explanation of the decision behind them. Once the script had better instructions, I didn’t need a report. I needed to trust the output.

And I changed the frequency. Every hour was recreating the exact problem I was trying to solve — constant interruption, constant context switching, just automated instead of manual. Four times a day:

• 8:00 am

• 12:00 pm

• 4:00 pm

• 9:00 pm

Enough to stay current. Not enough to give myself permission to check in between.

Before You Check the Output, Check the Instructions

The script is still running. Still working through the occasional sorting quirk. Triggers needed resetting at one point — a minor fix, easy to solve, and Gemini walked me through it clearly enough that someone with no coding experience could have handled it too.

But it’s working. Not because I found a better tool. Because I finally gave the tool I had instructions good enough to succeed.

Before you check whether the automation is working, check your gut — and check the instructions. Were they clear enough for the agent to actually do what you needed? If the output is wrong, that’s the first place to look. Not the inbox. Not the tool. The brief.

It’s the same question worth asking before you automate anything: have you defined the job clearly enough for someone else to do it?

Think about it the same way you would hiring a consultant or a contractor. You bring them in for their expertise. You give them the direction. And then you trust them to do the work — because hovering over their shoulder doesn’t make the output better. It just means you never actually handed off the job.

Your automation works the same way. Give it clear enough instructions, then let it run. If you haven’t, no tool is going to fix that for you.

If you’re working through something similar — an automation that’s half-working, instructions that aren’t landing, or just the general discomfort of letting a system do something you’ve always done yourself — that’s exactly the kind of decision DigiNav is built to help you think through. Start here.

Habits are hard to break. Whether it’s over-checking your email inbox or overindulging in your favorite dessert, it’s something you know isn’t doing you any good but you do it anyway.

I’ve been building a Chief of Staff dashboard for the past few weeks — using AI to pull information into one location so I can concentrate on what needs my attention.

The goal was to not have 10+ tabs open trying to figure out where that one piece of information is or was. I’m making progress, but the email section was the weak link.

Three boxes showing unread counts — inbox, WPSS, read later — and a link to go triage, which was basically a link right to the main inbox. Displayed as just numbers. No intelligence behind them.

I could see how much was waiting. I couldn’t see what kind of waiting. Action items looked the same as plugin update notifications. A client question sat next to a Substack digest.

To actually do anything useful, I still had to open Gmail and sort through everything myself. Which meant I was checking email to figure out if I needed to check email.

That’s the problem I needed to solve before the dashboard could do its job.

Before the Script: Cleaning Up 18 Years of Gmail Labels

It didn’t just start with an automation of my inbox. I had to start with the folder system that was 18 years in the making. 50+ Gmail labels accumulated over many years of running a WordPress agency and building a consulting business. All part of the chaos.

There were emails from clients who hadn’t been active in years. Others were duplicates with slightly different names. A few were things I couldn’t even remember creating, and some folders had zero messages in them.

You can’t automate a mess. If a script is going to sort emails into useful buckets, those buckets need to exist first and they need to make sense.

Knowing that I would be overwhelmed trying to organize all of that folder mess, I went to Claude AI and asked it to help me make heads or tails of the folder structure and how I could streamline it. I also took into account that now, with AI, it’s easier to find emails just by asking the AI to sort for you or by using the search function in Workspace.

And here’s where the reorganization ended:

• WPSS/ — agency wind-down, all client-related threads in one place

• DigiNav/ — consulting, content, audience conversations

• Life/ — personal, receipts, subscriptions, tax stuff

• Utility labels (underscore-prefixed so they sort to the top of the sidebar):

  • _Action Item — needs a response or decision

  • _Read Later — worth reading when there’s time

  • _Processed — the script’s audit trail

This is the non-glamorous work that people don’t talk about. It took a full session with Claude to sort through the chaos. But the upside was that it only took a few hours of conversation, as opposed to weeks of trying to figure out what was where and how to reorganize it.

Why I Used Gemini and Google Apps Script

So I moved the conversation from Claude to Gemini. The AI piece — sorting emails by judgment, not just pattern matching — wasn’t going to happen with Gmail filters or manual checking. But making that sorting automatic wasn’t clear until I started working inside Google’s ecosystem.

The reason for Gemini was simple: it lives inside Google Workspace. And there were some non-negotiables I wanted to make part of the process:

• Read Gmail natively

• Write a script that would automatically trigger

• Set those triggers to be time-based

• Not add another app that wasn’t already in the flow of tools I use

Gemini suggested the Apps Script approach. A script that runs on a timer, reads unread emails, uses AI to classify them, and applies the right labels. I set it to run every hour.

From there, the script would sort emails into three buckets:

• Action Items — anything that needs a response or a human decision

• Read Later — content worth reading when I have time

• Noise — notifications, plugin updates, form submissions, system alerts with zero human attention value

And the best part — Gemini correctly wrote the script based on best practices. It also gave me step-by-step instructions to not only install the script but to run the tests. I already knew how to do that, but if that’s not something you’re familiar with, Gemini can walk you through the whole process too.

Testing the Email Triage Script

The first test run put everything into Action Items. Every email. The rules weren’t specific enough about what counted as noise or read-later, so the script defaulted to the safest bucket. If you don’t tell AI what noise looks like, it assumes everything matters.

So I tightened the rules. Got very specific about what counts as noise:

• WordPress plugin update notifications

• Automated form submissions

• System alerts with no required action

And what counts as read-later:

• Newsletters and articles

• Informational updates with no response needed

The pendulum swung the other way. Everything landed in Read Later. Noise got a few scraps. Action Items was nearly empty.

Then there was the archiving problem. The script was archiving emails before the labels fully applied. Emails were disappearing — no inbox, no folder, just buried in Gmail’s archive. The fix was the same one from my earlier manual triage: label first, pause, then archive.

The _Processed folder became the safety net I didn’t know I needed. Every email that went through the script got tagged. When the counts didn’t add up or a category felt light, I could open that folder and see exactly what the script had done. It wasn’t just a label — it was the audit trail that let me refine the rules without losing anything and without reverting to checking the inbox myself.

The Anxiety of Letting Go

The system was working. The rules were dialed in. Emails were sorting into the right buckets every hour. And I still felt anxious about it.

The inbox was nearly empty, and my brain read that as something’s broken.

It wasn’t. It was working. The script was processing every hour, which meant email never had a chance to pile up the way it did when I was checking three or four times a day.

I was so used to seeing a wall of unread messages — and sorting through it as a kind of productivity ritual — that an empty inbox felt like a system failure.

I was getting in my own way. I’d second-guess how the script sorted things because I wasn’t the one making the call. I’d peek at the inbox to see if something got missed.

The whole behavior I was trying to automate away, I was recreating in a different form.

After a few more test runs, I looked at the Processed folder, confirmed the sorting was accurate, and made a conscious decision: stop opening the inbox. Go to the folders. Work from there.

That sounds simple. It was the hardest part of the entire build.

What the Email Triage Dashboard Looks Like Now

With the triage script running and the folder structure in place, the Today tab on my dashboard finally had what it needed.

Before: Generic unread counts. How much is piling up.

Now: Three intentional boxes:

• Action Items (red) — what needs a response

• Read Later (blue) — what’s worth reading when I have time

• Substack (purple) — engagement and reading, on its own schedule

Each box links directly to the Gmail label view. I go to the bucket that matches the energy and time I have.

Fifteen minutes between tasks? Check Action Items, knock out quick replies. Slower afternoon? Open Read Later and catch up on content. Ready to engage? Head to Substack and spend time on the conversations that matter.

The email section went from the weakest part of the dashboard to the piece that makes the rest of it work. Because now I’m not spending the first twenty minutes of my day sorting. I’m spending it deciding what to act on.

And with the triage running, the obvious next question was whether AI should handle the responses too.

The Line I Chose to Keep

I considered having AI draft responses. That’s the natural next step, right? Triage the email, then generate a reply so all you do is review and send.

I pulled back. Not because I think there’s anything wrong with it — plenty of people use AI for email drafting and it works for them.

But for the way my brain operates, I need to be fully present in the ask. When someone emails me a question, I need to read it, understand the context, figure out whether it’s technical or logistical or relational. That’s where I serve my clients and colleagues. If AI drafts the response, I’m reviewing words instead of understanding the need.

The triage handles sorting. The responding stays human.

That’s not a limitation of the system. It’s a design decision about where AI helps and where I need to stay in the loop.

What Automating Email Triage Actually Taught Me

Making the most of the tools that were already in my ecosystem was the gold of this whole experiment. Google Workspace, Gemini, and Apps Script were all sitting there waiting to just be connected and used. I didn’t need a new platform or another paid automation tool or the added expense of another AI platform.

But really the tools were secondary. Before any of that mattered, I had to organize what I was automating. 18 years of folders and labels wasn’t a system. It was sediment. Cleaning that up was the unglamorous foundation that made everything else possible.

And through all of this, the hardest part wasn’t the technical build. It was the behavioral changes:

• Trusting the system

• Trusting it enough to stop checking email

• Recognizing that an empty inbox means the automation is working, not that something’s broken

• Knowing where to draw the line between what AI handles and what stays mine

The script is still in testing mode. I need to give it time to work out any of the other kinks. I’m letting it run and watching how it’s sorting and adjusting based on the edge cases that come up. That’s how it should work. Not a launch-and-forget deployment, but building trust — with the system and with myself.

If you’re thinking about automating email triage, start here:

1. Figure out your buckets. What are the three folders that would cover 90% of your inbox?

2. Clean up the mess first. You can’t automate labels that don’t make sense.

3. Use what you already have. If you’re in Google’s ecosystem, the tools are already there.

4. Give yourself permission to feel uncomfortable. An empty inbox will feel wrong at first. That’s the system working, not failing.

The script is the easy part. Changing how you interact with your inbox is the real work.

This is part of an ongoing series documenting the build of a Chief of Staff dashboard — a personal command center for managing two businesses. The email triage was the missing piece that unlocked the Today tab.

Previous in this series:

What are the three folders that would cover 90% of your inbox? Reply and tell me — I’m curious how different they are from mine.

I’ve been building a Chief of Staff dashboard for the past few weeks. It’s my command center for managing the daily operational stuff that keeps both businesses running (and me sane). But there was one piece I kept stalling on: email triage.

I knew I wanted AI handling it. I just couldn’t figure out what that actually looked like.

Then I read ’s 4 Levels of AI Automation on Build to Launch. She breaks down the different levels of automation, from “AI reads your stuff and sorts it” all the way up to fully autonomous agents making decisions on your behalf.

But the line that stopped me wasn’t about the framework. It was this: “I wanted AI to read my inbox for me.”

That was my problem. Stated plainly, without overcomplicating it.

The One Level of Email Automation That Actually Matters

Jenny breaks automation into four levels. The one that matters here is the first: AI reads your email, separates it into categories, and you deal with what’s left.

That’s it. No agents making decisions on your behalf. No complex workflows routing data between platforms. Just sorting.

Her article is written for people choosing between automation platforms.

Builders evaluating which tool fits which job. Most of us aren’t making that decision. We’re trying to figure out what we can do with the tools already sitting in front of us.

That gap is where this gets interesting.

AI Email Triage Without the Fancy Tools

You don’t need a workflow engine to get Level 1 email triage. If you’re in Google’s ecosystem, you already have what you need.

I took Jenny’s concept to Gemini because it’s native to Gmail.

The idea was simple:

• write a script that reads my unread emails,

• uses AI to classify them into three buckets (action item, read later, noise),

• labels them, and archives them out of the inbox.

It was not a clean process.

During the testing — a simple click-the-Run-button process — I had to adjust and readjust because some emails were getting lost in the void.

Turns out, if the script archives a message before the label fully sticks, the email ends up homeless.

No inbox, no folder.

Archived in a catch-all folder with every other email you’ve ever kept. The fix that finally worked was suggested by Gemini: label first, pause two seconds, then archive.

Here’s what my inbox looks like now. Clean. Empty, actually.

This solved one piece of the Chief of Staff dashboard I’ve been building: the triage layer I couldn’t figure out how to automate.

But here’s what the automation didn’t fix: the habit.

Even with everything sorted, I still caught myself checking email whenever time allowed. Treating the triage of email as a badge for productivity honor when it’s really just a bad work habit that needed to be broken.

The sorting is solved. The compulsive checking is the next problem.

Is This Worth Your Time Right Now?

If you’re checking email between client calls whenever time allows, or treating inbox triage like your best productivity process, then yes. This is worth your attention right now.

Not because the concept is hard to implement. It’s not. But because your time and energy are more valuable than sorting emails into folders by hand. The real question isn’t whether you can automate this. It’s whether you’re willing to stop doing it yourself.

Figure out your categories. Find the simplest tool that sorts into them. If you’re in Google’s ecosystem, you already have what you need. The automation is the easy part. Trusting the system enough to stop checking is harder.

Jenny’s full article is here: 4 Levels of AI Automation. It’s worth reading even if you never touch a workflow engine, because the levels help you name what you’re actually trying to build.

Here’s the question worth sitting with: What are the three folders that would cover 90% of your inbox? Action items, read later, and noise worked for me. If you named yours, you’d already have the blueprint for what to automate — and what to stop checking.

This year’s winter jaunt was laid-back St. Augustine, Florida. Getting there and back meant two days in the car — the perfect stretch for catching up on work, reading, and whatever sparks come from hours of uninterrupted road time.

After my turn to drive, I decided to get an article or two into the pipeline. Except the work couldn’t be tackled on my iPad. Pulling out the laptop isn’t usually a big deal, but the computer bag was wedged in the back of the car and getting to it required some gymnastics I wasn’t in the mood for.

That’s where the rubber hit the road on my fancy Cursor content creation process.

The rubber being Cursor. The road being this: every conversation felt like starting from scratch. I was re-explaining myself every time. The context that makes working with Claude feel like working with someone who actually knows me — the memories, the context docs, the way I’ve built up how I operate over dozens of sessions — none of that was there. So while the AI agent was doing its job — technically — I was starting from scratch. Again.

That’s when it hit me: your AI workflow is only as good as what your AI actually knows about you.

Moving from Cursor back to ClaudeAI

The decision to move the full content pipeline out of Cursor had already been made — that part was clear. But mid-migration, something stopped me. The experiment docs were being glossed over and they’re the foundation of every article I write. Get that wrong and everything downstream is shakier than it needs to be.

So before anything else, I dealt with that first.

I had nine experiment files sitting in Cursor as markdown docs. I uploaded them all to Claude, and we assessed the existing Notion database together — what to keep, what to cut, what was missing entirely.

Claude fixed the schema.

The old template sections — Prompts, Inputs, Outputs, Artifacts, Notes, Next Iteration — got replaced with the structure that actually matched how I work: What I Built or Changed, How I Tested It, What Happened, Verdict.

Then the MCP applied all the existing records into the updated database. That’s where it got interesting. The first test run overwrote records instead of updating them. We fixed it and retested. Four rounds before it landed cleanly.

Once the existing data was solid, I added the forward workflow: at the end of any build session, ask Claude to document it directly into Notion. I live-tested this in the same conversation — one API call, all properties and body content written correctly in one shot.

The improvement I didn’t see coming: documenting the build directly through the conversation removes more friction than any tool switch ever could.

The breaking points, or not.

Nothing broke in the technical sense. Which is almost the point.

The friction in Cursor wasn’t loud. It didn’t throw errors or fail visibly. It just quietly required more from me than I realized — more re-explanation, more re-context, more process around the edges. The kind of thing you stop noticing because you’ve adapted around it.

What I didn’t expect was how much I relied on the build notes — the Experiment doc — as the actual foundation of each article. It adds the context, the actual conversation threads from AI and sometimes screenshots.

It was a structural piece that wasn’t getting its due. Cursor’s AI agent didn’t have access to the relationship Claude has built or the conversation memory. That’s not a Cursor problem — it’s just a fundamentally different thing.

Because sometimes broken isn’t when things don’t work, it’s when things are overlooked.

And if I’m honest, I’d been chasing a shinier setup instead of trusting the process I’d already built. The tools that had context — Claude, Notion — were right there. I just had a layer in the middle that didn’t.

If I had to do it again.

Trust the process you already built. Notion had been functioning as my persistent memory all along — storing context, tracking experiments, holding the thread between sessions. Claude had been the thinking partner. Those weren’t gaps to fill with a new tool. They were the foundation worth building deeper into.

I’d stacked a layer on top instead of doubling down on what was working. The switch didn’t require a complicated migration plan. It required recognizing that the combination I was working around was already solving the problem I needed solved.

New and shiny has a cost that’s easy to miss: it starts with zero context. And zero context means starting from scratch. Every time.

Decision one in the bag.

Kill Cursor for content creation. The decision wasn’t about features or capability — it was about context. Notion for persistent memory. Claude for thinking partner and automation. That’s the combination that already knew how I worked.

Cursor wasn’t a bad tool. It was the right tool for a moment that’s passed. The smarter move wasn’t finding something newer. It was recognizing what was already working and doubling down on it.

Notion remembers. Claude thinks and connects. That’s the pairing worth building on.

One more thing worth naming: things move fast in the AI space. What feels like a gap today may not be the stumbling block tomorrow. That’s not a reason to wait — it’s a reason to make decisions based on what’s working now, not what you’re hoping a new tool will eventually solve.

This is Part 1 of a short series on rebuilding the content workflow from the ground up. Getting the experiment documentation right — the soul of every article — was the foundation.

Next up: how the Article CEO workflow sits on top of it, and how the full pipeline runs from first spark to published piece.

One Thing You Can Try Today

Take five minutes and run this prompt against your current workflow:

“I use [tool/s] to do [specific job]. Given what I know about [the other tools I use daily], is this still the right fit — or am I working around it without realizing it?”

You’re not looking for a reason to switch anything. You’re just looking with fresh eyes. The answer might be: this still fits perfectly. That’s a useful thing to confirm too.

I’m big on organization especially when it comes to AI use and conversations. So her guides are always well-organized and specific in a way that makes you slow down and take note even when the technical details aren’t directly relevant to what you’re doing.

I read this one because Cowork is where I’m spending more of my time this quarter, and Karo has a way of laying things out that makes you look at your own setup and think: wait, am I being sloppy about something that matters?

The article covers a lot of ground — connector architecture, permissions, using Notion as persistent memory. Good stuff, worth reading on its own.

But the thing that I got the most out of wasn’t the technical setup of CoWork. It was something simpler underneath it: the names you give your folders are instructions to Claude, not just labels for yourself.

The names you give your folders are instructions to Claude, not just labels for yourself.

Karo’s folder structure is deliberate. Each name signals what Claude should do with what’s inside it. Easy to skim past when you’re looking for the architecture details.

The kind of thing that’s obvious in hindsight and invisible until someone makes it explicit.

Two things I took from Karo’s setup that didn’t require me to build anything new:

Sub-folders beat a flat root. Before reading this, everything except outputs lived in my root folder. One folder. Everything dumped in. It works until it doesn’t — and when it doesn’t, it usually means Claude is filling in gaps you didn’t know you left.

The rename that clarified something I hadn’t noticed. When I ran the article through a conversation with Claude, it flagged one specific thing: my folder called references should probably be called context. I didn’t push back. It made sense immediately.

Here’s why it matters.

References, to me, means sources: supporting documents, things I cite, external material. Context means something different: what Claude needs to understand my world. My voice. My audience. How I think about problems. Those two things were living under the same name, and that name was doing the wrong job.

The practical move is simple: look at your Cowork folder setup and ask whether the names mean what you think they mean to Claude — not just to you. That’s a five-minute audit. It won’t overhaul your system. It might just make it work the way you thought it already did.

If you’re using Cowork and have any kind of folder structure in place, this is worth 20 minutes now. Not to rebuild from scratch — just to look at what you named things, how you’re set up — and whether those names are doing the right job.

If you’re not in Cowork yet, this type of thinking works with other file management best practices. Starting with intentional folder names is a better foundation than cleaning them up later. Either way, go read Karo’s full article. The Notion memory setup alone is worth the time.

Karo’s full article is here:

Product with Attitude

Claude Cowork Guide for Power Users: 50+ Tested Tips on Plugins, Skills, Sub-Agents, and Memory

Read more

a month ago · 128 likes · 15 comments · Karo (Product with Attitude)

One question to sit with:

In your current Cowork setup, is there a folder named something that made sense to you when you created it — but might mean something different to Claude? That’s your starting point.

A friend of mine loves to bake. Cakes, cookies, those little things she drops off that nobody ever turns down. But somewhere between the job, the side gig, the family and everything else life stacks on top — she was running out of time to do it. The baking wasn’t the problem. The process around it was eating the hours she didn’t have.

So I asked her: why not get ahead of it? Do the prep work in bulk when you have a window. Handle the time-consuming parts in advance, so when the hour finally appears, you’re not starting from scratch — you’re just baking.

She looked at me like I’d said something obvious. And maybe I had.

That conversation stuck. Because I’d been having the same one about my own business — just without the baking. Moving information from one place to another. Updating the same record in two tools. Copying what Claude produced into Notion, over and over.

The baking was fine. The prep work was the problem.

And the fix wasn’t somewhere else. It was already in the room.

The problem wasn’t what I had. It was what was missing between them.

The terminology was never built for you

You’ve probably heard this by now: connect your tools. Automate the repetitive stuff. Let AI handle it. Or maybe it comes with a list — MCPs, APIs, automation workflows. Someone making it sound like the logical next step.

And if you’ve ever looked at those words and thought, that’s not for me, you weren’t wrong to think it. For a long time, connecting apps required reading through developer documentation, understanding architecture, building the integration yourself. The barrier was genuinely technical. The conclusion — this isn’t in my lane — was a reasonable read of the situation.

But here’s what changed: everything around those terms did. The terms are the same. What they require from you isn’t.

MCPs. APIs. Skills. Plugins. These aren’t going away — if anything, you’re going to hear them more. But they’re no longer instructions for developers. They’re descriptions of how a system works. And once you understand what each one actually does, in plain language, the next question stops being can I even do this?

It becomes: where does this fit in what I’m already doing?

That’s a completely different question. And it starts with four definitions.

When Claude does the work... sort of

I had Claude do some of it. Updating records in Notion, pulling information across, and handling the pieces I didn’t want to do manually. And sometimes it was great — exactly what I needed.

Other times, it was inconsistent. Spotty results. Updates that half-landed. A process that worked well enough on a good run and let me down on the next.

The fix existed. I knew that. The problem was getting it to work reliably — and that meant setting things up properly, with the right connections in place.

And here’s why that matters for you — especially if you don’t have a technical background.

The path to fixing it runs through terms like MCPs, APIs, Skills, and Plugins. And for most people, that’s exactly where the conversation ends. Not because the concepts are complicated. Because the words signal: this requires a developer. This is not your lane.

That signal is wrong.

The terminology was built for a technical audience. It wasn’t built to keep you out — it just was never translated for someone who runs a business without a coding background. So you keep copying and pasting. You keep doing the manual steps. Not because you can’t use these tools, but because nobody handed you the plain-language version of what they actually mean.

That’s what this is.

Here’s what happens when the terms click.

You stop asking “can AI do this?” and you start asking “which piece handles this?” That’s a completely different question — and it opens up a completely different set of possibilities.

For me, that looked like setting up CoWork, not Claude Code. Most of the conversation has gone in that direction — it’s the more technical option. CoWork is the everyday version. The one built for exactly this: connecting Claude to the apps and spaces you’re already using, without needing a development background.

What I built was a simple connection. My experiment notes on my hard drive. My Notion workspace. My dashboard. My articles. CoWork became the layer that linked them, so Claude could reach across those spaces without me manually carrying the information between them.

Before CoWork, I had something similar running in regular Claude. And it was inconsistent in a specific way — sometimes it would create or update the Notion records exactly right. Other times, it would stop short and hand me code or text to copy and paste myself.

Which, if you think about it, is just the copy-paste tax wearing a different outfit. The connection between Claude and Notion was missing the piece that makes it reliable — the MCP, the API link. Without that, Claude was doing its best with what it had. Which wasn’t always enough.

The copy-paste process didn’t disappear because I found a smarter workaround. It disappeared because I had the right structure in place. Four terms. Four jobs. Each one handles a specific part of how the system works.

That’s what this understanding makes possible for you. Not a complicated build. Just a clear picture of what each piece does — and suddenly, the question isn’t whether you can do this.

It’s where do you want to start?

The four terms, in plain language

So let’s get into the four terms. Not the developer version. The version that actually makes sense for how you run your business.

MCPs — the hallway.

Your business doesn’t live in one room. It lives in Notion, in your inbox, in your calendar, in the documents on your hard drive. MCP is what builds the hallway between them. Without it, you’re the one carrying information from room to room. With it, the information moves on its own.

APIs — the smart lock.

You’re not handing anyone a key to your house. You’re giving controlled access — a code that works for a specific door, for a specific reason, and can be revoked whenever you want. The house stays yours. You just decided who gets through which door.

Skills — the recipe adapted for who’s cooking.

Same kitchen, same base. But a home cook improvises differently than a baker, who measures everything, because the chemistry matters. Skills are how Claude’s instructions get calibrated for the task at hand. What works for syncing documents is set up differently from what works for writing. Same foundation. Different precision depending on what’s actually being made.

Plugins — the meal kit.

Someone has already figured out the ingredients, the sequence, the portion sizes for a specific dish. You’re not building the recipe from scratch — you’re getting a pre-assembled package designed for one job. A sales plugin is a meal kit for prospecting. A marketing plugin is a meal kit for content.

Skills teach Claude how to cook. Plugins tell it what to make and for whom.

MCPs connect the rooms. APIs control who gets through which door. Skills are the recipe adapted for who’s cooking. Plugins are the meal kit — pre-assembled, one job, ready to go.

The companion piece walks through building each of these layers — what setup looks like, what to do with an API key, and how to build a Skill for a specific task. That’s where the how-to lives.

Here’s what staying manual actually costs.

Not in a dramatic way. Just in the quiet, steady way of doing the same task twice because the tools don’t talk to each other yet. Copying what’s in one place into another. Updating the record. Doing it again next week.

It’s not broken. It just never stops being your job.

The other cost is harder to see. It’s the possibilities that don’t show up because the vocabulary hasn’t landed yet. You can’t ask for a connection you don’t have a word for. You can’t build a system around terms that feel like they belong to someone else’s world.

The copy-paste tax is the visible one. The vocabulary gap is the invisible one. And they compound — the longer the terms feel inaccessible, the longer the manual process continues.

Noticing that friction isn’t weakness. It means you’re paying attention to where your time is actually going — and asking whether it has to.

It doesn’t.

Five things worth taking with you

If you only take away five things from this:

1. MCPs connect your tools. Without the connection layer, you’re the one carrying information between rooms. That’s the copy-paste tax — and it’s optional.

2. APIs are access keys, not developer tools. You give controlled access for a specific purpose. The house stays yours. Access is yours to grant and revoke.

3. Skills are how Claude’s instructions get calibrated for the task. Same base, different precision depending on what’s actually being made. A sync task and a writing task don’t run on the same settings.

4. Plugins are the meal kit. Someone already figured out the ingredients and sequence for a specific job. You’re not building from scratch — you’re deploying something pre-assembled for one purpose.

5. The barrier was never a technical skill. It was unfamiliar language. Once the terms land, the question changes from “can I do this?” to “where do I want to start?”

You’re allowed to find this hard.

Not because the technology is complicated. Because the language around it was built for a different audience — and nobody handed you the translation. So you watched the tutorials, heard the terms, and quietly concluded that this level of setup wasn’t for you.

That conclusion made sense with the information you had.

It’s just not accurate anymore.

The tools are there. The connections are possible. What changes first isn’t your setup — it’s the question you’re asking. And the question changes the moment the terms stop feeling foreign.

So here’s what I want to leave you with: what’s one process in your business where you’re still the one carrying the information? Not a general category — a specific thing. The task you do every week that moves the same data from one place to another, because the rooms aren’t connected yet.

That’s your starting point.

And once the terms land, the next question becomes which tool is the right fit for the job you’re trying to do. That’s a different conversation — and one worth having.

If you want to go further, the companion piece walks through building each of these layers, from what to do with an API key to how to build a Skill for a specific task. That’s where the how-to lives.

I was halfway through an article about Claude Code when I caught myself nodding along to advice about git workflows and terminal commands. Things that have nothing to do with how I actually use AI day-to-day.

Not because the developer stuff was interesting. Because buried underneath all of it was something I’d been wrestling with in my own work. The why behind AI going sideways on me.

This week, I read two genuinely excellent articles. Both about Claude Code, which is a developer tool that lets programmers use Claude directly from their terminal instead of the chat interface most of us use. One is even trying to bridge the gap for non-developers. But even that one assumes you’re writing code, managing files, and running commands.

The ideas underneath all of that? They’re not about code at all. They’re about how to work with AI better. And they apply whether you’re a developer or a business owner typing into Claude’s chat window.

So I dug them out. Here’s what I found.

(The articles, if you want the originals: Practice Makes Claude Perfect by Julia Diez, and Claude Code Skills, Commands, Hooks & Agents Guide by Dheeraj Sharma. Both worth reading if you’re technically inclined.)

It’s not a magic box. It’s a contractor.

Julia Diez opens with a reframe that I keep coming back to: Claude isn’t an assistant. It’s “a brilliant contractor who has no memory between work sessions and can only hold a certain number of things in their head at once.”

“A brilliant contractor who has no memory between work sessions and can only hold a certain number of things in their head at once.”

— Julia Diez

In the developer world, this means creating special files that brief Claude Code on the project before every session. Developers literally write a briefing document that loads automatically so Claude knows what it’s working on, what matters, and what the rules are.

You and I don’t have that automatic setup. But we need the same habit.

Why does AI keep missing the mark even when you’ve used it for months? You’re not briefing each session. Yes, Claude has memory now, and it might remember your name and some preferences.

But that’s not the same thing.

Memory is like knowing your contractor’s phone number. A briefing is sitting down with them Monday morning and saying: here’s what we’re working on this week, here’s what matters, here’s what done looks like.

Why does it drift on longer tasks? You handed over a big job without scoping it. Why do results get worse the longer a conversation goes? The job site got cluttered, and nobody cleaned it up.

I’ve done every one of those things. Still do, when I’m rushing.

The developer fix is a special file. Your fix is simpler: at the start of any significant AI task, take thirty seconds to tell Claude what you’re working on, what matters, what the constraints are, and what “done” looks like. Not a novel. A few sentences of context. The kind of thing you’d tell a smart freelancer on day one.

More instructions actually make AI worse.

This one surprised me.

Developers spend a lot of time writing rules and instructions for Claude Code to follow. Sharma’s article gets into the specifics of how to organize them, where to put them, what format to use. But the insight underneath all that structure is simple and it applies to everyone:

If you’ve ever given AI a detailed set of instructions and watched it nail the first few tasks but get progressively sloppier, there’s a reason. AI can only hold so many rules in its head at once. Add too many and quality doesn’t just drop on the extra ones. It drops across all of them.

Developers discovered this the hard way. They’d write hundreds of lines of instructions and wonder why Claude started ignoring the important ones. The fix was cutting back to only what actually mattered for the task at hand.

Same thing applies when you’re setting up a Claude Project or writing a system prompt. Every vague, redundant, or low-priority instruction isn’t just noise. It’s competing with the things that actually matter.

I’ve been guilty of this. Long system prompts full of “nice to have” preferences that I never pruned. If you’ve noticed your detailed instructions working less well over time, this might be why. Short, specific, high-stakes rules outperform long lists of preferences every time.

Plan before you produce.

Julie writes about a Claude Code feature called “plan mode” that forces Claude to map out its approach before it writes any code. Developers use it because building the wrong thing wastes hours.

You don’t need plan mode. You just need to ask.

Her prompt translates directly: “Before you start, walk me through your approach and flag any assumptions you’re making.”

I’ve started using this in almost every session. The reason it matters isn’t technical. AI, like most of us, defaults to action over thinking. Give it a task and it starts producing. That feels like progress. Often it isn’t.

When you ask AI to plan first, you get two things. It thinks through what it’s about to do. And you get a chance to catch misunderstandings before they become a finished draft heading in the wrong direction.

Diez puts it simply: changing direction during planning costs seconds. Changing direction after the fact costs everything.

Worth trying once before you dismiss it. Next time you have a real AI task, start with “before you begin, walk me through how you’d approach this.” See what comes back. Redirect if needed. Then let it go.

One conversation shouldn’t do everything.

Both articles land in the same place: a general AI loaded up with everything you’ve ever needed performs worse than a focused AI given only what it needs for the task at hand.

Developers solve this by building separate configurations for different types of work. They create specialized setups that load only the rules and context relevant to a specific job.

For the rest of us, it’s simpler than that. Stop asking one conversation to do everything.

I see this with my own work. I’ll start a session doing email drafts, pivot to client research, then ask for a proposal outline. All in the same thread. And then wonder why the proposal feels off.

The fix is almost boring. Start fresh conversations for different kinds of work. If you use Claude Projects, give different types of work their own project instead of loading one up with everything.

Smaller scope, sharper results. That’s it.

What I’m actually taking away

The problems both articles tackle are ones you’ve probably had too. AI that forgets, drifts, underperforms, and goes sideways. Developers just got to the solutions first because their tools forced them to think about it.

Brief it like a contractor. Keep your instructions tight. Ask it to plan before it produces. Stop asking one conversation to hold everything.

Not a technology problem. A workflow problem. And it’s one you can start fixing today.

If any of this shifted how you’re thinking about your own AI use, I’d love to hear what clicked. Hit reply and tell me.

DigiNav Compass is for business owners navigating AI decisions on their own terms. If this helped, forward it to someone who’s been frustrated with their AI results lately.

Inspired by information in: Practice Makes Claude Perfect by and Claude Code Skills, Commands, Hooks & Agents Guide by

Every session started the same way.

Open a new conversation, load the three docs, explain what I was working on, explain how I worked, and explain what I would and wouldn’t do. AI would take it in, do something reasonable with it, and we’d move forward. Then I’d close the tab.

Next session: start over.

This was early, before AI tools had real memory, or right at the edge of it. All three foundation docs were in place by then. The Business Snapshot, the Audience Profile, the Voice DNA. Loaded together, they gave me better output than I’d gotten before. I thought that was the fix.

The problem showed up when I’d ask for help thinking through a decision. The answer would come back technically right, sensible on paper, but wrong in ways I couldn’t always name immediately. Suggestions that ignored a second business I was running. Directions that assumed a work style I don’t have. Boundaries none of the docs had any way of knowing existed. I’d add the missing context manually. The session would improve. I’d close the tab. Next session: start over.

Business, audience, voice: the three docs tell AI about the operation. They say nothing about the person behind it.

Why This Is Harder Than It Looks

The standard advice is to build the three foundation docs and call it done. Business Snapshot. Audience Profile. Voice DNA. It makes sense. You’ve given AI the business context, the audience context, and the communication style. The logic is the same one we use when laying a building foundation: pour it once, get it right, then build on top of it.

The advice isn’t wrong. The three docs do what they’re supposed to do.

What they don’t do is tell AI how you work. Your decision-making style. What drains you. When you do your best thinking. What you’d never agree to, regardless of how sound it looks on paper. The reality of running a second business alongside the first. None of that is in a Business Snapshot. None of it belongs in a Voice DNA doc. It doesn’t have a home yet. The conventional wisdom skips the part nobody talks about: the person behind the operation.

A foundation without the framing that goes on top of it is still just concrete. It’s a starting point, not a finished structure.

What I Tried That Didn’t Work

So I tried the obvious thing first. I went back into the Business Snapshot and added a section. A few lines about how I work best: the hours I protect, the second business, the things I wouldn’t do regardless of what the numbers said. The logic was solid. The Business Snapshot was already the doc I loaded first. If I put the missing context there, it would be there.

It helped for about two sessions. Then the same drift came back. The Business Snapshot was built to describe the operation — the model, the audience, the positioning. When I added personal operating notes to the bottom of it, the doc did what docs do: it held everything without prioritizing any of it. AI would take in the full thing and give more weight to the business description than the three lines about how I work.

I’d patched a doc that wasn’t broken to solve a problem it was never built to solve. And I nearly convinced myself it was working. The sessions weren’t obviously broken. The output was still reasonable. But reasonable isn’t the same as right, and I was still adding the same context manually, session after session, the same way I had been before I touched the Business Snapshot at all.

Half-right output is harder to catch than wrong output. Wrong output is obvious. Half-right looks reasonable until you try to act on it and realize it was built for a version of you that doesn’t quite exist. I had documented the business, the audience and the voice. I hadn’t documented myself. And I’d spent time patching a doc instead of building the one that was actually missing.

What Actually Shifted

What finally changed wasn’t adding more to the three docs. It was realizing the three docs were never built to answer those questions.

Each one was doing its job. The Business Snapshot covered the business. The Audience Profile covered who I was talking to. The Voice DNA covered how I sound. Together they did what they were designed to do, and still left a gap I kept filling manually every single session.

Two things were missing that had names once I looked at them directly. The first: Personal Context. Not communication style (that’s what Voice DNA covers). Operating style. When I do my best thinking. What drains me. My non-negotiables. The behind-the-scenes reality of running two businesses at once. How I actually make decisions, not how I’d describe my decision-making process if someone asked. The difference between those two things is larger than it sounds.

The second: Product/Offer Context. What I’m building toward, whether the offers are fully formed or not. What I’d never build, even if it made sense on paper. What success looks like in 12 months. Without it, every planning session defaulted to what had worked for everyone else before, solutions built on hustle-culture assumptions that had nothing to do with how I wanted to work or what I was actually building toward.

Once both existed, the sessions changed. AI stopped suggesting strategies that required energy I don’t have at the time of day I do most of my work. The rules I’d built around energy and recovery stopped being invisible constraints I had to re-explain every time. Planning had somewhere to land.

I had documented the business. I hadn’t documented myself. Those are two different documents.

The change from here doesn’t arrive all at once.

Build is where you are after the docs are in place. The foundation is real. That’s the table stakes.

Refine is the first few weeks of use. You notice something’s still off, open the doc, update a line. The next session is better. This is the system working, not failing.

The compound is harder to see from inside it. Sessions get easier. You stop re-explaining yourself. The output starts fitting in ways that accumulate quietly.

Operating differently isn’t a destination. It’s what’s already happening if you’ve made it to compound.

Here’s What This Looks Like in Practice

You now know what two docs are missing. While you’re building them, the foundation you already have can handle four plays. Each one pressures a different part of your context so you can see what’s holding and what’s missing. Run them with three docs. Run them again with five. The difference between those two sessions is where the remaining gap shows up.

Play 1: Decision Testing. Run it before committing to anything, new tool, new offer, new direction. It tests a decision against your actual business context instead of general reasoning. Why it matters: a decision that fits your business on paper might not fit how you work or what you’re building toward. Upload: Business Snapshot. Add Personal Context and Product/Offer Context when you have them.

Play 2: Map What You Actually Need. Use it when you know what you’re working toward but can’t see clearly what’s between you and it. It skips the 90-day roadmap and gets to the smallest useful next step. Why it matters: Personal Context shows whether the path forward actually fits how you work; Product/Offer Context gives the mapping somewhere real to land. Upload: Business Snapshot and Audience Profile. Add the two context docs when you have them.

Play 3: Blind Spot Recognition. Use it when the audience feels right on paper but the content isn’t landing the way you expect. It surfaces the gap between your interpretation of their problem and what they’re actually dealing with. Why it matters: knowing what you’re building toward changes which audience blind spots matter most. Upload: Audience Profile. Add Product/Offer Context when you have it.

Play 4: Strategic Reflection. Run it at the end of a month or a project cycle. It finds the patterns in your own work before you build more: what’s emerging, what’s stalling, what question you should actually be sitting with. Why it matters: this play does the most work with the full five docs loaded. Patterns that look like business problems often turn out to be operating problems, and that only surfaces when Personal Context is in the room. Upload: all three docs. Add Personal Context and Product/Offer Context when you have them.

When I run these, what surprises me is how quickly the misfit shows up. The plays don’t need the two extra docs to run. They need them to stop giving you answers that are half right. The companion piece walks through each play in practice: the prompts, the process, and what done looks like. Same format as the starter kit, with interview prompts, synthesis prompts, and what a finished doc actually looks like for Personal Context and Product/Offer Context.

What It Costs to Stay Stuck

Running without these two docs doesn’t stop the work. It just means some of your time and energy go toward compensating for what isn’t documented yet.

Bad output is easy to spot. You see it, you fix it, you move on. Misfit output is different. It looks reasonable. It fits the business. It passes the first read. The problem surfaces when you try to act on it and realize it was built for a version of you that doesn’t quite exist, someone with different hours, different constraints, a different sense of where this is heading. So you correct it manually. Add the context that’s missing. Get a better answer. Close the tab. Next session: same thing.

The energy drain isn’t the bad sessions. It’s what you’re doing in the good ones. Every time you re-explain your working hours, your boundaries, your direction, that’s a doc that doesn’t exist yet doing its work anyway, through you, one session at a time. The work gets done. It just takes more out of you than it should. Without Product/Offer Context, AI defaults to what’s worked before for someone else, in a different kind of business, with different values about how work should feel. The answers point in a direction that isn’t quite yours, and you spend energy steering back each time.

Noticing this friction isn’t a sign that something’s broken. It’s pointing directly at what’s missing.

Key Takeaways

If you take away only four things from this, make them these.

1. Business, audience, voice, and then you. The three foundation docs cover the operation. They say nothing about the person behind it. For a solo business owner, those aren’t the same thing.

2. Half-right output isn’t a prompting problem. It’s a missing-docs problem. If AI keeps coming back with answers that look reasonable but don’t quite fit, the gap is in what hasn’t been documented yet, not in how you’re asking.

3. Two docs fill what the first three can’t. Personal Context captures how you work, not just how you sound. Product/Offer Context gives AI a direction to orient around, rather than defaulting to someone else’s playbook. Both answer questions the foundation docs were never built to answer.

4. The plays work now. They’ll work better with five docs loaded. Run them with what you have. Pay attention to where the answers still feel slightly off. That friction is showing you exactly what to build next.

You’re Allowed to Find This Hard

Building the first three docs is hard in a specific way. You’re answering questions about the business: what it is, who it serves, how it sounds. Those questions have answers, even if they take work to surface.

Personal Context and Product/Offer Context are harder in a different way. They ask you to document how you actually work, not how you’d like to work. To articulate a direction that might not be fully formed yet. To be honest about constraints and non-negotiables that feel uncomfortable to put in writing because putting them in writing makes them real. That’s worth naming. I still catch myself skipping the personal docs when I’m in a hurry, loading three instead of five and then wondering halfway through the session why the output keeps needing correction.

A half-formed direction doc is more useful than no doc. You don’t need certainty to build either of them. You just need enough honesty to give AI something real to work with instead of letting it fill the gap with someone else’s assumptions about how a business like yours should run. Start with one line that’s true. Update it when something shifts. That’s the whole process.

The companion piece covers how to build them: same format as the starter kit, with interview prompts, synthesis prompts, and what a finished doc actually looks like.

Subscribe now

What’s one thing you find yourself re-explaining to AI session after session? Not a business detail. Something about you: how you work, what you need, what you’d never do. Drop it in the comments.

Missed the article? Read the companion piece to “The Workshop I Built Was Wrong.”

Before you start: what your AI context foundation looks like when it’s done

Most people build context docs the wrong way because they don’t know what they’re building toward. So let’s show you the destination before you start packing.

A working AI context foundation isn’t one long document. It’s a folder structure with specific files doing specific jobs. Here’s what that looks like:

Read more

Why your AI output keeps coming back flat

Feedback and interactions were off. Not wrong, just flat.

You know the feeling. Something doesn’t feel right, but you can’t quite put your finger on it. Like making your favorite chocolate cake, following the recipe to a tee, using all your favorite ingredients, and it’s still a little off. Nobody sends it back. They still eat the cake. But it’s not the one they talked about the next day.

That’s what was happening to my writing. One week I had the perfect three layers and everyone raved. The next time, nobody said a word but they still showed up. Comments that circled around something without landing. Shares that were quieter than expected.

So I did the reasonable thing. I opened my Voice and Tone doc and started tightening it. Added more examples of what I didn’t want. Made the language more specific. Documented a few phrases that kept creeping into drafts I didn’t like.

I closed the doc feeling like I’d fixed the recipe. The next article came back the same way.

It took longer than I’d like to admit to figure out what I was actually doing. The voice wasn’t the problem. The structure was. The way I was presenting information (the flow, the sequence, the shape of an argument) wasn’t in my Voice and Tone doc. It wasn’t in any of my docs.

I had a full set of context docs. Business Snapshot. Audience Overview. Product Strategy. Storytelling Guide. All the right ingredients.

None of it answered the question my articles were actually asking.

The docs weren’t wrong. They were answering the wrong questions entirely.

Why “more context” is enterprise advice for a small business problem

The standard advice makes sense. Document your context. Give AI your voice, your audience, and your business background. The more it knows, the better it performs. Most of us have heard this, tried this, and watched it work, at least partially.

The advice isn’t wrong. It was just written for a different version of the tools and for a different scale of operation.

The frameworks most of us are following came from developers and prompting experts building large systems. Complex pipelines. Processes that needed every variable documented because the cost of getting it wrong was high. Their rules made sense for what they were doing.

When you apply that logic to a small business, it doesn’t tighten your output. It just gives you more to maintain. The docs grow, the updates pile up, and before long, you’re working on your context docs instead of the thing they were supposed to support.

I was spending more time updating my context docs than actually using them.

The goal was never to document everything. It was to remove the guesswork. Those are not the same job.

The over-documentation trap (and the template spiral that followed)

The problem wasn’t that I needed better docs. It was that I was building the wrong kind.

The original approach made sense. AI needed everything handed to it. It couldn’t hold context between sessions, couldn’t infer what you meant, and couldn’t reason about your business without explicit instruction. So you gave it everything. Voice down to specific phrases you’d never use. Audience down to what kept them up at 3 am. Background detailed enough to onboard a new hire.

I was still following those rules when I built my Content Lab (where all my content work lives) and started laying out my LifeOS dashboard (a personal productivity system I was building in Notion). And for a while, it felt like the right call.

When I finally identified the structural problem with my articles, I did the right thing. I started building writing templates. Specific ones for the actual use cases I was working with: experiments I was running, tools I was testing, and prompts I was stress-testing. Each one had its own shape and flow.

And then I kept adding more.

More templates, more use cases, more variations. No core set to anchor them. So the supporting docs (tone, audience, what to stay away from) got muddy. AI couldn’t figure out which flow to follow, so it defaulted to whatever pattern felt closest. The output got inconsistent in a whole new way.

I still catch myself doing this. Starting a new use case and reaching for a new template instead of asking whether one I already have could do the job.

I had graduated from the wrong foundation to the wrong working layer. Different problem, same root cause: building more instead of building better.

The three-layer AI context foundation that fixed it

What finally changed wasn’t the documents themselves. It was the question I was asking about them.

I had been asking “what’s missing from this doc?” every time something went wrong. Which meant every problem sent me back into the same pile of files, adding more to the docs that didn’t need more.

The better question turned out to be: which layer is this problem actually in?

That’s a different question. And it changes where you look.

A living context foundation isn’t one long document or even a tight set of core files. It’s built in layers, each one doing a different job:

The foundation is who you are, how you sound, and who you’re talking to. Most people have this, at least partially. It’s table stakes, not the finish line.

The working pieces are how you structure and present information. Templates, offer documents, and the shape of how you think through a problem. This is the layer most people skip entirely. It’s also the one that changed my output quality more than anything in the foundation layer.

Your running record is what you’ve tested, what worked, what didn’t, and what you learned. It’s the layer that lets AI push back rather than just execute. Without it, you have a capable partner with no history of how your business actually works.

The foundation tells AI who you are. The working pieces teach it how you think. The running record gives it something to measure against.

When I stopped patching the foundation and started building the missing layer, the output settled. The articles found their shape. The foundation stopped being something I was constantly fixing and started being something I was building on.

How to audit and update your AI context docs

Three shifts worth making, in order:

1. Build in layers, not in length.
Start with your foundation if you don’t have one. If you do have one, look at what’s next. Do you have a writing template, or a document that captures how you structure information? Do you have anything that tracks what you’ve tried and what you learned?

Each layer lives in its own document. Not one long file that keeps growing. A connected set you can open, update, and put back without touching the rest.

2. Review on a rhythm, update only what drifted.
Every few months, unless something significant changes. Open the relevant document, ask AI to review it against what’s new. Sometimes nothing needs updating — and that’s the system working, not the system failing. You’re not looking for what’s wrong. You’re checking whether it still reflects where you actually are.

3. Let AI do the seeing you can’t.
This one surprised me. When I started adding experiment notes to my context — what I was building, testing, learning — AI flagged something I hadn’t noticed myself. I had been telling my agents to break everything down into plain language, no jargon, keep it accessible. But when I wrote those experiment notes, I was writing like I was back in a developer meeting. Project briefs. Technical shorthand. The language of someone deep inside the work.

AI couldn’t reconcile the instruction with the example. And just like that, I couldn’t pretend I didn’t know. My content had been talking at my audience instead of with them — and no amount of audience profiling would have caught it. The problem wasn’t in the profile. It was in how I was showing up in my own docs.

Here’s a prompt you can use to audit a document you already have:

I'm going to share one of my context documents with you.

Once I share it, tell me:
1. Which layer does this belong in — foundation (who I am, voice, audience),
   working pieces (how I structure information, templates, offers), or
   running record (what I've tested and learned)?
2. What's in here that still feels current and accurate?
3. What feels like it was written for an older version of my business?
4. What's missing that would help you act as a real partner, not just a generator?

Don't tell me what to fix yet. Just tell me what you see.

The companion piece walks through building each layer from scratch — what goes in each document, the prompts for creating them, and what they actually look like.

The hidden cost of outdated context docs

Every session where AI guesses wrong, you’re editing. Every month a doc ages unreviewed, you’re re-explaining. Every output that’s almost right but not quite — that’s not a prompt problem. That’s a foundation problem.

The harder cost to see: you can stay busy tweaking docs and feel like you’re making progress. But if the missing layer never gets built, nothing changes. You’re not stuck because you stopped trying. You’re stuck while trying the wrong thing.

That friction you keep feeling isn’t weakness. It’s pointing at exactly what needs attention.

Key takeaways

If you only take away four things from this, make it these.

1. The docs aren’t wrong — they’re answering the wrong questions. More context doesn’t necessarily lead to better results. The goal was never to document everything. It was to remove the guesswork. Those aren’t the same job.

2. You can’t fix a structure problem in a voice document. When output is off, identify which layer the problem is actually in before you touch anything.

3. A living foundation is built in layers, not in length. The foundation tells AI who you are. The working pieces teach it how you think. Your running record gives it something to measure against. Each one is a different document doing a different job.

4. AI can surface contradictions you can’t see from inside. When your instructions and your examples don’t match, AI will find it. Add your experiment notes, your test results, your real work — and let it show you what you’re missing.

Start here: find the layer you’re missing

Most people built their context docs once and moved on. Going back to revisit them feels like admitting they weren’t enough.

They were enough. For then. The tools changed, and the job changed with them. That’s not a failure — it’s just where we are.

The shift that’s actually hard isn’t the tactical one. It’s accepting that something you built carefully and deliberately might need a new layer — not because you did it wrong, but because you’ve outgrown what it was designed for.

You’re allowed to find that hard.

What’s one document or template you built a while back that still makes sense on paper — but you’re starting to suspect isn’t working for where you are now? Not a general category. A specific thing. Drop it in the comments and I’ll tell you which layer I’d look at first.

If you want to build the layers from scratch, the companion piece walks through all three — what goes in each document, the prompts to create them, and what done looks like.

Five Tabs, Three Failed Dashboards, and One Decision

I had five tabs open every morning. Gmail for personal. Gmail for the business. Google Calendar. Google Tasks. And a Notion dashboard I’d built three different times — each version more organized than the last, each one quietly abandoned within weeks.

The data organization in Notion was solid. I’d give it that. But the UI never worked for me, and “organized” doesn’t matter if you stop opening it. Some days it was a forgotten wasteland.

Meanwhile, the real work — triaging two inboxes, checking what’s on the calendar, figuring out what actually matters today — was scattered across tabs I had to manually stitch together every morning. That daily stitching was bogging me down and stressing me out.

Before: five tabs, Notion ignored.
After: one dashboard, one rhythm.

I didn’t need another productivity system. I’d tried that. What I needed was something tailored. Built around how I actually work, pulling from the tools I was already using, structured around my energy and my priorities. Not someone else’s template.

So I built it. Using Claude, Claude Code, and Cursor, I built an AI Chief of Staff dashboard that does what no off-the-shelf tool could: sees everything in one place and helps me structure my day around it.

I’m a developer. I could have mapped this out the traditional way — architecture docs, wireframes, weeks of planning before writing a line of code. But that’s exactly the cycle I wanted to break.

What an AI Productivity Dashboard Actually Does

It connects to the tools I’m already using — two Google Workspace accounts, Google Tasks, Google Drive and eventually Notion — and pulls everything into one screen. Email counts from three sources. Today’s calendar. Tasks. Brain dump notes I’ve captured throughout the day.

Then the AI does the part I used to do manually: it builds my rhythm.

“Build My Rhythm” looks at all of that context — commitments, emails, tasks, my top five priorities for the week, appointments, brain dump notations. Then it generates time-blocked working sessions for the day. Not a task list. Not a project plan. Rhythm blocks. Each one has a purpose, a start time, and an end time. Mode-based, not checklist-based.

Think of it like a chief of staff who reviewed your calendar, scanned your inboxes, checked your priorities and handed you a structured day before your first cup of coffee. Except it costs pennies a day and runs on Claude’s API (an API is just a way for one app to talk to another — in this case, the dashboard asks Claude to think through your day and send back the plan).

The goal wasn’t another task list that would fade away. It was to use my best work times and workflows to structure my day.

Why Generic Productivity Tools Keep Failing

Here’s the pattern I keep seeing — in my own attempts and in conversations with other creators.

You find a tool that’s almost right. Notion’s data organization is genuinely good. Google Workspace handles email and calendar well enough. So you try to make them work together.

You build a Notion dashboard. You set up filters. You create views and databases. And for a while, it feels like progress.

Then you stop opening it.

Not because the system was bad. Because it wasn’t yours. It was someone else’s structure, with your data poured into it. The friction was just high enough that on a busy morning, you’d skip it. And once you skip it twice, it’s over.

My friend hit the same wall. She liked Notion’s organization — same as me — but not the UI or the usability. Someone else’s system almost worked. So she built her own dashboard to solve it.

That’s the part most people miss. The problem isn’t discipline. It’s fit. Generic tools assume a single inbox, a single calendar, and a single way of working. I have two email accounts, newsletter folders, weekly priorities that live in a different system and brain dumps that need to feed into how I plan my day. No off-the-shelf tool handles that — because it wasn’t designed for my workflow.

The problem isn’t discipline. It’s fit.

How I Built a Custom AI Dashboard in Days

I didn’t follow a roadmap. I followed a pattern that kept repeating: figure out what I need, keep what’s already working, and let AI handle the parts I don’t want to spend weeks on.

Step 1: Define what your day actually needs.

Before I touched any code, I mapped out what was stressing me out. Three email sources that needed triaging every morning. A task list of must-dos. The five things I want to accomplish each week to move my business forward. My calendar commitments. And a place to capture ideas throughout the day without breaking flow.

That’s it. Not a feature list — a friction list. What’s slowing me down? What am I forgetting to check? What keeps falling through the cracks?

Step 2: Keep what works. Replace what doesn’t.

Google Workspace was working: email, tasks, docs, calendar. I wasn’t going to replace those. Notion’s data organization was working. I wasn’t going to abandon that either. What wasn’t working was the layer on top: the thing that pulls it all together and makes it usable.

So the dashboard became a lens, not a replacement. It connects to Google’s APIs and shows me unread counts across all three email sources with “Triage →” links that open the right Gmail label. It pulls calendar events from both accounts. It reads my tasks.

Quick Capture writes brain dumps straight to Google Drive with auto date headers and a “Captured Today” count.

The tools stay. The view changes.

Step 3: Let AI build it — and design it.

This is where it got interesting. I saw Kim Doyal’s dashboard and loved the layout— clean and easy to navigate. That was my missing visual reference. So I uploaded a screenshot to Claude and asked it to help me write the proper prompt for how it should be coded.

Claude handled the reasoning and planning. Claude Code wrote the application code. Cursor kept everything in one workspace while I worked. The Claude API powers the daily rhythm generation: “Build My Rhythm” sends all my dashboard data to Claude and returns a structured day, color-coded by category.

Here’s what it actually took: a code editor, a hosting platform, and API access. That’s the infrastructure. The thinking is the part only you can do. What do I need? What’s already working? What should the day look like?

The AI handles the technical translation. You bring clarity to your own workflow.

I went from concept to a working dashboard in days, not weeks. Not because I skipped the hard parts — because the hard part was knowing what I needed. And I already knew that.

Tailored means yours. Your dashboard won’t look like Kim’s or mine. It shouldn’t.

What Building Your Own Dashboard Actually Takes

If you’ve ever written a brief for a contractor — “here’s what I need, here’s how I work, here’s what matters” — you have the skills this takes.

Building a tailored dashboard isn’t a coding exercise. It’s a clarity exercise. Once you know what you need — your inputs, your workflow, your priorities — AI walks you through the build. Step by step. Clear instructions. Each piece connects to the next. Think of it less like programming and more like following an SOP that gets written for you as you go.

Claude, Claude Code and Cursor handle the technical translation. You follow the steps.

What they can’t do is tell you what your morning needs to look like. They can’t decide that you need to triage three email sources before your first creative block. They can’t know that your best thinking happens before noon, or that your weekly priorities need to be visible while you plan your day.

That’s the work. And it’s work you’ve already done — you just haven’t written it down in a way that becomes a system.

The scary part isn’t the technology. The scary part is admitting that the tools you’ve been using aren’t working and committing to something built around how you actually operate. Once you make that decision, the build is the easy part.

Key Takeaways

If you take away only five things from this, make them these.

1. The problem isn’t discipline — it’s fit. If your productivity system keeps becoming a forgotten wasteland, it’s not because you’re lazy. It’s because it wasn’t designed around how you actually work.

2. Start with your friction list, not a feature list. What’s slowing you down? What are you forgetting to check? What keeps falling through the cracks? That’s your blueprint.

3. Keep what works. Replace what doesn’t. You don’t need to abandon Google Workspace or Notion. You need a better layer on top — a lens that pulls it all together.

4. AI makes the build accessible — but only you can define the need. The technical parts are handled. The hard part is knowing what your morning, your workflow, and your priorities actually require.

5. Tailored isn’t one-and-done. Your solution keeps evolving because your work does. Phase 1 ships. Phase 2 fixes and automates. The system grows with you.

The Cost of Staying Scattered

Here’s what staying in the cobbled-together setup actually costs you.

Every morning you spend stitching tabs together is a morning you’re not doing the work that moves things forward. Five minutes here, ten minutes there — checking this inbox, switching to that calendar, opening a Notion page you haven’t touched in a week. It adds up.

Not just in time, but in mental load. By the time you’ve assembled the picture of your day, you’ve already burned through your best energy figuring out what to do instead of doing it.

And every system you’ve abandoned? That wasn’t a failure of discipline. That was a signal. The tool didn’t fit, so you moved on rather than forcing it. The problem is that “moving on” usually means moving to another generic option that will hit the same wall.

That’s the real cost. Not the wasted setup time.

The slow bleed of mornings that never quite start right. The weekly priorities that drift because they weren’t visible when you were planning. The brain dump ideas that never fed back into your rhythm because they lived in a different tool.

You already know what you need. The question is whether you keep adapting to tools that weren’t built for you — or build something that was.

Start With Your Friction List

When nothing fits, build it.

That’s not a slogan. It’s what I did when three versions of Notion dashboards failed. It’s what Kim did when she hit the same wall. And it’s what the tools — Claude, Claude Code, Cursor — are making possible for anyone willing to start with one question: What does my day actually need?

My dashboard pulls from two email accounts, Google Tasks, Google Calendar, Google Drive and soon Notion. It generates rhythm blocks based on my energy, my priorities, and my commitments. Yours won’t look anything like that. It shouldn’t.

Maybe yours needs to surface client deadlines alongside your content calendar. Maybe it needs to track invoices and project status in one view. Maybe it’s simpler — just your top three priorities and today’s calendar, visible the moment you open your browser.

Whatever it is, it starts with your friction list. What’s not working? What are you stitching together every morning? What keeps getting ignored?

I’m still building. Now that Phase 1 is shipped, it’s time to test and find the parts that aren’t quite right. I can already see a few tiny adjustments before I move on to Phase 2, the automation layer that will make it a true chief of staff. Tailored isn’t one-and-done. It evolves because the work does.

If you’re sitting on a version of this problem — tools that almost work, systems you keep rebuilding, mornings that start scattered — I’d love to hear what your friction list looks like. Reply and tell me what’s not working. That’s where it starts.

And if you want help figuring out what your tailored solution could look like, book a quick session and we’ll cut through the noise together.

I saw someone’s Claude Code content system and thought I’d found the answer. Run a command, AI generates an article, done. Automation. Structure. Efficiency. Exactly what I needed.

So I started rebuilding my workspace to work like theirs. I copied their automation scripts into my content workspace. I mapped out their workflow: brief the AI, let it research and draft, and review the output. Clean. Systematic. Impressive.

(Quick note: Claude Code is terminal-based, Cursor is visual interface-based. Both use Claude AI, with different execution styles. More on that in a minute.)

Halfway through the rebuild, I realized what I was actually doing: automating myself *out* of the creative process.

Their system was brilliant—and it worked perfectly for their workflow. But here’s what I missed: even though I can build and code, when I’m creating content, I need to think *creatively*, not *technically*. I need to be part of the process throughout—asking questions, making judgment calls, shaping direction as ideas emerge.

I was building a vending machine—insert prompt, receive content—when what I actually needed was someone to think alongside me.

The tool wasn’t the problem. My approach to using it was.

Understanding AI Tools: Agents, Rules, and Skills

Before I explain what went wrong, here’s what these tools actually are—because the terminology gets confusing fast.

Agents (in Claude Code) are automation scripts. You give them a job in the terminal; they do it and return output. Think of them like hiring someone to complete a task while you’re away. You brief them; they execute; you review the results.

Rules (in Cursor) are IDE guidance. They tell the AI how to behave when you’re working together in real-time. Think of them as giving someone your preferences before you collaborate. “When I’m writing marketing copy, use this voice. When I’m coding, follow these conventions.”

Skills (in Cursor) are interactive workflows. You and the AI work through a process together, step by step. Think of them like having a structured conversation with someone—you’re both present, making decisions, shaping the outcome as you go.

Same AI. Different execution models. Different levels of participation are required from you.

The question isn’t “which tool is better?” The question is: which execution model fits the kind of work you’re doing?

Why Automation Fails for Creative Work

Here’s what I almost did (and what I see a lot of people do): I approached content creation from a *technical* mindset instead of a *creative* one.

The technical mindset says: “How do I make this efficient? How do I build a system that runs a process and produces output?” It’s the same thinking you’d use to set up email filters or schedule social media posts in advance. Figure out what repeats, build the system once, and let it run.

That works beautifully for repetitive tasks. But creativity isn’t repetitive. You can’t automate taste. You can’t script insight. You can’t batch-produce your voice.

What I realized halfway through rebuilding my workspace: I was trying to factor myself into the process “in big chunks”—at the beginning (write the brief) and at the end (edit the output). Everything in the middle? Hand it to the machine.

That’s not collaboration. That’s a production line.

And here’s what that actually costs you: the work feels hollow. All those little moments where you’d normally ask a follow-up question, and the whole direction shifts? You miss them.

The judgment calls that make it sound like *you*? They’re not there. You end up managing AI output instead of actually creating something.

It’s not the tool’s fault. It’s what happens when you try to completely remove yourself from the creative process.

So I stopped trying to copy their system and started rebuilding for how I actually work. Not “how do I make this more efficient,” but “how do I stay in the conversation while still getting structure and support?”

Three decisions changed everything.

How to Structure AI Collaboration (Not Automation)

Step 1: Separate Workspaces by How You Think, Not What You Build

I used to have everything in one workspace: code projects, content drafts, someone else’s automation setup, and my positioning docs. Every time I opened Cursor, the AI loaded context for *all of it*—coding guidelines when I was writing, editorial voice when I was debugging.

The fix wasn’t organizing by file type. It was organized by *workflow type*.

What I did:

• Created a “Builds” folder — All code projects (where automation makes sense)

• Created a “Lees-Space” folder — All content work (where collaboration makes sense)

• Created a “Client-Workspace” folder — Future client projects

Inside Lees-Space, I created another separation: a content-lab subfolder for editorial work and a marketing-assets subfolder for conversion copy. Each has its own rules folder, so the AI loads the right context for the right job.

Why this matters: When you’re creating, the AI should load your voice guide and editorial process—not your coding configs and debugging tools. Separation isn’t about organization. It’s about focus.

Step 2: Build Roles for the AI, Not Scripts

Instead of building automation scripts that “go do the work and come back,” I built rules that define how the AI collaborates with me during different phases of content creation.

What rules are: Think of them as instruction files that live in your workspace. When you’re working in Cursor (the visual editor), the AI reads these rules and adapts its behavior to match. They’re like giving someone your collaboration preferences before you start working together.

What I actually created:

• 800-article-ceo — The strategic interview role. I answer questions, the AI structures my brain dump into a blueprint.

• 810-article-write — The drafting partner role. The AI suggests how to frame sections, I write and edit to match my voice.

• 820-qa-voice — The voice checker role. I review, the AI spots where I’m drifting from my positioning.

• 830-seo-optimizer — The visibility role. I approve decisions, the AI helps optimize for search without killing the voice.

The numbers ensure they load in order—content strategy first, then drafting, then refinement, then optimization. The .mdc file extension just means “markdown with cursor rules”—nothing fancy.

These aren’t scripts. They’re collaboration agreements. The AI knows what role to play, and I’m in the conversation the entire time.

The moment this clicked: I was about to convert someone else’s SEO automation script into my system. Then I realized—I don’t want the AI to do SEO for me. I want it to help me think through SEO decisions. Same job. Different execution model. I built a rule instead of a script, and suddenly I was part of the decision-making process, not just reviewing the output.

Step 3: Keep Yourself in the Conversation

This is the part that’s easy to miss: collaboration requires real-time participation. You can’t batch it.

What this looks like in practice:

• When I’m blueprinting, the AI asks me three strategic questions and waits for my answers before building the outline. I’m not feeding it a brief and walking away—I’m answering in the moment, and my answers shape what gets built.

• When I’m drafting, we move through the sections section by section. The AI suggests how to frame a section; I write it in my own words, we review it together, and adjust before moving forward. I’m not editing a completed piece—I’m shaping it as it emerges.

• When I’m optimizing for search, the AI proposes changes, and I approve or reject them one by one. I’m not reviewing a batch of edits—I’m making judgment calls in real time.

The transferable principle: If you can’t be part of the conversation during the work, you’re not collaborating—you’re delegating. And delegation works great for tasks that don’t require your taste, but terrible for work that does.

What This Really Requires

Here’s what this approach doesn’t require:

• You don’t need to be a developer

• You don’t need to understand how AI models work under the hood

• You don’t need to write code or live in the terminal

Here’s what it does require: knowing how you think when you’re creating something.

Do you need to be part of the conversation as ideas take shape, or are you comfortable handing off a brief and reviewing the result? Do you think in back-and-forth dialogue, or do you think in structured plans you execute alone? Do you make your best decisions in the moment, or after you’ve seen the full picture?

There’s no right answer. But there is a fit question.

Some people can hand off creative work and edit the result. Others lose their voice that way. Some people think best when they’re reacting to something in real time. Others need space to process alone first.

Neither is better. But if you’ve ever felt like something was “technically fine but not quite right,” and you couldn’t figure out why until you realized you weren’t part of shaping it—that’s the signal. You don’t need better tools. You need a process that fits how you actually think.

TL:DR

If you only take away 4 things from this post, make it these:

Automation and collaboration are different execution models. Agents automate (you brief, they execute, you review). Rules guide (the AI adapts to you in real time). Skills collaborate (you work through it together, step by step). Same AI, different levels of participation.

You can’t automate creativity. The technical mindset (make it efficient, eliminate manual work) works for repetitive tasks. But creativity requires taste, judgment, and your voice—and those can’t be scripted. You can structure collaboration, but you can’t automate insight.

Separate your workspace by how you think, not what you build. Code projects and content creation require different workflows. When they share the same workspace, the AI loads irrelevant context every time. Separate them so the AI focuses on what matters for the job at hand.

If you’re not in the conversation during the work, you’re delegating, not collaborating. Delegation works for tasks that don’t require your taste. Collaboration is required when the work needs your voice, your judgment, your real-time decisions. Know which one you’re doing.

The Real Cost of Automating Creativity

Here’s what happens if you keep trying to automate creativity:

You’ll spend weeks building the perfect system. You’ll set up agents, write detailed briefs, and refine your prompts. The AI will produce content. You’ll edit it. And something will feel off.

The work will be fine. Technically correct. But it won’t sound like you. The little moments where your perspective comes through—the turns of phrase, the judgment calls, the tangents that actually make the point land—they’ll be missing. You’ll read it back and think, “This is almost right, but not quite.”

And here’s the part that’s hard to spot until you’re in it: you’ll start adjusting yourself to fit the system. You’ll write briefs that produce better output. You’ll edit in a way that preserves what the AI generated. You’ll optimize for the tool rather than the idea. You’ll become a prompt engineer managing a production line instead of a creator making something that matters.

Let’s do the math: You spend 2 hours building the brief, the AI works for 30 minutes, and you spend 3 hours editing the output to sound like you. That’s 5.5 hours. You could have written it yourself in 4 and actually enjoyed the process.

The efficiency promise is a trap. You’re not saving time. You’re spending it differently—and losing your voice in the process.

Ready to Rebuild Your Process?

So here’s my question for you: What’s one piece of content you’ve been trying to create, and what’s stopping you from just sitting down and making it?

Is it that you don’t have a system? Or is it that the system you’re trying to build is getting in the way of actually creating?

Because here’s what I help people with: figuring out how to use AI as a thinking partner instead of a replacement for thinking. Not “here’s the tool,” but “here’s how to structure collaboration so you stay in the driver’s seat.” If that sounds like the kind of conversation you need to have, let’s talk.

Want the actual files I built for this? I’m sharing the full breakdown—the .mdc rule files, the workspace structure, the conversion process from agents to rules, plus screen recordings of how it all works in practice—as a companion piece for paid subscribers.

Inspiration & Credit:

This article was inspired by the excellent work of on Claude Skills, ’s Claude Code writing system, and ’s Cursor-based workshop on The Hub Workshop.

Their approaches to AI collaboration helped me see what was possible—and gave me the language to articulate what I was building.

Three Projects, Zero Code, One Week

I kept running into permission issues on my Mac. Folders I couldn’t access, files that wouldn’t move. The kind of thing that makes you realize you’ve been kicking the can on how you organize your digital life for... a while.

After fixing the permissions problem (another AI project, another story), I was already in cleanup mode. And everyone’s been talking about AI agents and tools that do the work for you, specifically Claude’s new CoWork feature. Me being me, I needed some real projects to throw at it.

The criteria were simple: tackle something that would take more of my time than I wanted to give, have it solve a real problem, and factor in more use cases for the future.

So I picked three.

• A MacBook hard drive stuffed with files migrated from multiple machines over the years.

• A Dropbox folder holding 10+ years of documents spanning several brands.

• And hundreds of Midjourney image files with names like `leedrozak_A_woman_seated_at_a_cluttered_desk_covered_in_scatt_f928b109-0e14-4709-a6d0-a1e3bb3632b6_1.png.`.

No code. No terminal. No developer skills for any of them.

And here’s the part that surprised me: the tool wasn’t the hard part. The thinking before I opened it was the hard part.

Every article I’ve read about CoWork tells you to point it at a folder and watch it go. That’s like telling someone to hire an employee and just let them figure it out.

The people getting frustrated with CoWork are skipping the planning. The people getting value from it are doing what good managers do: defining the what before they unleash the how.

So What Is CoWork, Actually?

Let me skip the jargon for a minute.

You already know how to use Claude in a chat. You type a question, and Claude answers. That’s a conversation. CoWork is different. Instead of asking Claude for advice, you’re handing Claude a task and letting it do the work.

Think of it this way. Regular Claude is like calling a smart friend and asking, “How would you organize this mess?” CoWork is like that friend coming over, rolling up their sleeves, and actually sorting through the pile with you.

The technical term is “agentic AI,” which means Claude can take actions on its own, step by step, checking in with you along the way. It can read your files, move them, rename them, create new documents, and build spreadsheets. All on your actual computer. You choose which folders it can see, and it asks before taking big actions.

Here’s the part that matters for people who don’t write code: CoWork was built specifically so you don’t need a terminal. It lives inside the Claude desktop app, same place you already chat. You describe what you want done in plain language, point it at a folder, and it gets to work.

That’s it. That’s what it is.

The question isn’t whether the technology works. It does. The question is whether you give it enough to work with.

If you want to see CoWork in action before diving into the how, here's a quick walkthrough.

Why Most First Experiences Disappoint

Here’s the thing about CoWork that nobody is writing about.

Most people’s first experience goes like this: They open it, type something vague like “organize my Downloads folder,” point it at 200 files, and wait. CoWork does... something. It creates folders. It moves files around. And the result is... fine. Maybe. Or maybe it sorted your tax documents into a folder called “Miscellaneous PDFs” and put your client contracts next to your takeout menus.

Then they close it and think, “Well, that was underwhelming.”

I almost had that experience myself. The first time I sat down with my MacBook drive cleanup, my instinct was to just point CoWork at the whole drive and say, “fix this.” But I’ve been around long enough to know that when you hand a capable person a vague task, you get a vague result.

The pattern I keep seeing, in my own work and with clients, is the same one: people jump to the tool before they’ve done the thinking.

They skip planning because it feels like the boring part. But planning isn’t busywork here. Planning is the entire job. CoWork handles the execution. You handle the strategy.

And that distinction? That’s the plot twist nobody’s talking about.

CoWork doesn’t need your technical skills. It needs your management skills.

The Framework: Specs, Blueprint, Roadmap

Here’s what actually worked for me this week. Before I opened CoWork for any of these three projects, I worked through the same three questions in the same order.

Step 1: The Specs (What do I actually want?)

This is where most people stop too early. “Organize my files” is not a spec. That’s a wish.

A spec answers: What does the finished version look like? What are the categories? What are the rules? What should be kept, trashed, or flagged for me to decide?

For my MacBook drive, the spec was straightforward: I had files migrated from several old machines. I needed duplicates identified, old system files flagged for removal, and everything else sorted into folders that matched how I actually work (not how my old computers were organized).

For my Dropbox, the spec was more complex: 10+ years of documents across multiple brand iterations. I needed files sorted by which brand they belonged to, with anything outdated moved to an archive folder, and current working files surfaced to the top.

For my Midjourney images, the spec was creative: rename every file so the name tells me what the image is about (subject) and how it feels (vibe). Instead of that AI-generated string of characters, I wanted filenames like woman-desk-thinking-contemplation-decisions-papers.png.

Here’s the kicker about the Midjourney project. The original filenames already contained the prompt I’d used to generate each image. Words like “cluttered desk” and “half-open window” and “focused expression” were buried in those long, ugly filenames. So CoWork wasn’t guessing from scratch. It had context to work with. I gave it something to build on.

That’s what a good spec does. It gives the worker enough context to make smart decisions.

Step 2: The Blueprint (How should it approach this?)

The blueprint is where you anticipate the decisions CoWork will have to make, and give it your preferences before it starts.

For the MacBook drive: “When you find duplicates, keep the most recent version. If a file hasn’t been opened in 3+ years and isn’t a legal or financial document, flag it for review but don’t delete it.”

For the Dropbox folder: “Documents with ‘DigiNav’ in the filename or content belong to the current brand. Anything referencing [old brand names] goes to archive. If you’re unsure, put it in a ‘Review’ folder and I’ll decide.”

For the Midjourney images: “Rename using this pattern: subject-descriptors-mood-vibe.png. Keep it lowercase, use hyphens between words, and focus on what’s visually happening in the image plus the emotional tone.”

See the difference? The spec says what you want. The blueprint says how to handle the judgment calls. Without a blueprint, CoWork makes those calls for you. Sometimes that’s fine. Sometimes you end up with your client proposals filed under “Miscellaneous.”

Step 3: The Roadmap (What order, and where do you check in?)

The roadmap is your sequence. It’s especially important for bigger projects.

For the MacBook drive, the roadmap was simple: scan first, show me a summary of what you found, then sort. I wanted to see the lay of the land before anything moved.

For the Dropbox folder (the biggest project), I broke it into phases: start with just the top-level folders. Show me what you’d do before you do it. Then go deeper one folder at a time. I didn’t want CoWork tearing through a decade of files without checkpoints.

For the Midjourney images, the roadmap was: rename a batch of 10 first. Let me see if the naming pattern works. Then do the rest.

That last one turned out to be smart. After the first batch, I adjusted a few of my naming preferences before letting CoWork finish the other hundreds of files. Ten minutes of review saved me from renaming everything twice.

What This Really Requires (Hint: Not Technical Skills)

Here’s what I want my not-so-technical friends to hear, because this part matters.

Nothing I did this week required coding. Nothing required a terminal or command line. Nothing required understanding APIs or scripts or any of the vocabulary that makes people’s eyes glaze over.

What it did require:

Knowing what you actually want. Not “organize this” but “here’s what organized looks like for my situation.” That’s not a tech skill. That’s a management skill. It’s the same skill you use when you brief a contractor, or explain a project to a virtual assistant, or onboard a new team member.

Thinking about edge cases before they happen. What should CoWork do when it finds a file it can’t categorize? When there are duplicates? When something could belong in two places? You don’t need to catch everything. But anticipating the obvious judgment calls saves you from cleaning up the cleanup.

Starting small and iterating. Every single project went better because I didn’t hand CoWork the whole thing at once. I tested on a small batch, reviewed the result, adjusted my instructions, and then scaled up. That’s not caution. That’s how good project management works.

If you’ve ever managed a person, delegated a task, or written instructions for someone covering your work while you’re on vacation, you have the skills CoWork needs. The barrier isn’t technical. It’s the willingness to do the thinking first.

If You Only Remember This

If you only take away five things from this entire post, make it these.

1. CoWork is Claude with its sleeves rolled up. Instead of giving you advice in a chat window, it actually does the work on your computer. Same Claude, different mode.

2. The tool isn’t the hard part. The brief is. Vague instructions get vague results. Clear specs, a blueprint for judgment calls, and a phased roadmap make the difference between “meh” and “wow, that just saved me an entire weekend.”

3. You don’t need technical skills. You need management skills. If you can explain a task to a capable human, you can use CoWork. The skills that matter are knowing what you want, anticipating decisions, and reviewing in stages.

4. Start small. Always. Test on a batch of 10 files before you unleash it on 1,000. Review the first pass before trusting the rest. This isn’t being timid. This is being strategic.

5. Context is your superpower. My Midjourney renaming project worked because the original filenames already contained prompt information. CoWork wasn’t working blind. Give it something to build on and it builds well.

The Real Cost of Skipping the Thinking

I know what you might be thinking: “That planning sounds like a lot of work. Can’t I just... try it and see what happens?”

You can. And you might get lucky.

But here’s what “trying it and seeing what happens” actually costs. You spend 45 minutes watching CoWork do something you didn’t quite want. Then you spend another hour undoing what it did. Then you try again with slightly better instructions. Then you tweak again. And again.

Three hours later, you’ve “saved time” by spending more time than it would have taken to do it manually.

I know because that’s exactly the pattern I see with every new tool, not just CoWork. The tool gets blamed for the result. But the result was set the moment you skipped the thinking.

The 15 minutes I spent writing specs and a blueprint for each project? That wasn’t overhead. That was the entire reason the projects worked. It’s the same reason you’d never hand a contractor your house keys and say “renovate something.” You’d give them a plan first.

That friction you feel about slowing down to think before acting? That’s not weakness. That’s 17 years of business experience telling you something important: tools work when the thinking is done. Not before.

What Are You Putting Off?

Here’s what I’d love to know.

What’s the project on your computer that you keep putting off because the manual version feels overwhelming? The folder you haven’t touched in years. The files with names that mean nothing. The digital junk drawer you close as soon as you open it.

That’s probably a CoWork project. And the first step isn’t opening CoWork. It’s answering this: What does “done” look like, specifically, for you?

If you can answer that, you have your spec. And you’re already further than most people get.

Your turn…tell me what that project is. I’m genuinely curious.

And if you want help thinking through the specs-blueprint-roadmap for your specific situation, let’s talk. That’s exactly the kind of thinking work I do. Not pushing buttons for you. Helping you name what “done” looks like, because that’s harder than it sounds.

I thought I was ahead of the curve. I’d built Claude Skills—voice guidelines, content repurposing workflows, the works. Felt pretty good about it. Then put out a call last week asking people to share what they’d built. And to say people delivered is an understatement.

Writers maintaining voice across months of content. Consultants with context libraries that eliminate the “let me explain my business again” dance. Systems that work across any project, not just the one they were built for.

I looked at my setup. What I’d built was solid—but it was trapped. Locked inside specific projects as instructions. Every time I started something new, I was rebuilding context instead of deploying it. I’d been building rooms when I should’ve been building infrastructure.

The Real Gap Nobody Talks About

Most people think the problem with Claude is consistency. The AI gives you gold one day, garbage the next. So you save the prompts that worked. You build custom instructions for your projects. Maybe you create a Skill or two. You’re doing the right things.

But here’s what I discovered looking at what others had built: the real issue isn’t whether you’ve set things up. It’s whether you’re thinking big enough about what that setup could do.

I had good stuff. Voice guidelines that actually captured how I write. Content workflows that saved me hours. But they lived inside specific projects as instructions. My Substack project had one setup. My client's work project had another. My brainstorming space had... nothing, really. Just me re-explaining the context every time.

The people getting genuinely consistent results? They weren’t just building for individual projects. They were building for their whole process—voice that deployed whether they were writing a newsletter, drafting a client proposal, or outlining a workshop. Context that didn’t need to be copy-pasted or recreated. It just existed, ready to use wherever they were.

Here’s what that gap was costing me:

• Duplicate effort rebuilding context across projects

• Inconsistent outputs because each project had slightly different instructions

• The mental load of remembering which project had which setup

• Useful things I’d built that sat unused because they weren’t accessible elsewhere

The fix wasn’t building more. It was rethinking what I was building for. Not project-specific instructions. Something you set up once and stop thinking about—because it just works wherever you are.

So what does that actually look like?

How I Rebuilt My Approach

The Creative QA Skill by Mariam Vossough stopped me cold.

Mariam had built something specifically for catching weak spots in drafts—not grammar or typos, but the structural stuff. Unclear transitions. Arguments that don’t land. Sections that drag. The kind of feedback you need after you’ve reworked something three times and can’t see it clearly anymore.

I’d been missing that. I thought my content process was solid, but I didn’t have anything that checked for weak spots after the drafting and redrafting were done. That was gap number one.

But then I started thinking bigger. A Creative QA check shouldn’t just work on Substack articles. What about YouTube scripts? Content repurposing? Website copy? The underlying need—catching weak spots in something I’ve already worked and reworked—shows up everywhere. Why would I build something that only works in one place?

That’s when the real pattern clicked.

I looked at what I’d already created. Voice guidelines, content workflows, repurposing frameworks. All solid. All trapped inside specific projects. My Substack project had context my YouTube project couldn’t access. My content repurposing project duplicated half of what lived in my drafting project. I’d built useful things, but they didn’t talk to each other.

Here’s what I tried:

1. Audited what I actually had. Listed every project and its instructions. Asked: is this specific to one use case, or is the underlying need something I hit repeatedly?

2. Identified the core that applied everywhere. My voice guidelines? Needed everywhere. My content pillar definitions? Same. A QA checklist? Definitely not a one-off.

3. Rebuilt as account-level tools. Pulled what I’d created out of individual projects and rebuilt them as standalone pieces that could be accessed from anywhere.

4. Tested across contexts. Took the rebuilt voice setup and used it for a Substack draft, a YouTube outline, and a landing page. Same foundation, three different outputs. It worked.

The surprising part wasn’t that this approach was better. It was how much mental overhead I’d been carrying without realizing it. Remembering which project had which instructions. Recreating context I’d already built. Wondering if my Substack voice guidelines matched what I’d set up for client work.

When I stopped building for single projects and started building for my whole process, that overhead disappeared.

Here’s what I finally understood: the question isn’t “what does this project need?” It’s “what’s a problem I solve over and over—and how do I build something once that handles it everywhere?”

How to Build for Your Whole Process

Why Project-Locked Instructions Were Costing Me

Every time I started a new project, I was rebuilding context. Copy-pasting instructions from one project to another. Wondering if my voice guidelines here matched my voice guidelines there. What I’d built was useful—but only in the single place I’d built it.

Which meant I was doing the same setup work repeatedly, just in different containers.

Here’s What Changed: Building at the Account Level

The shift was moving what I’d created out of individual projects and into account-level custom setups—where they’re available everywhere, triggered automatically based on what I’m working on.

You’ll find this under Settings > Profile > Settings > Capabilities > Skills in Claude. That’s where Skills live at the account level, separate from any individual project.

Now, when I ask Claude to help with DigiNav content, my voice setup activates. Not because I remembered to paste instructions. Because I built triggers that recognize the context.

The Structure That Makes It Work

I let Claude handle the formatting, but everything I build now has three parts:

• Metadata: What this is for and when to use it

• The Core: The actual instructions, guidelines, or framework

• Supporting Resources: Any documents it needs to reference

The Trigger Setup

This is the part I was missing. What you build needs to know when to activate. My voice setup triggers on:

• Requests to write DigiNav content

• Mentions of “Lee’s voice” or “DigiNav style”

• Content about AI/automation for thoughtful business owners

• Keywords like “clarity before automation” or “thinking partner”

No manual activation. No remembering which project has which instructions. It just shows up when it’s relevant.

The Question That Filters Everything

Before building anything now, I ask one question:

Am I using this in more than one project—or is this a one-off use case?

If it’s one project, it stays as project instructions. If it shows up across multiple contexts, it becomes something I build once and use everywhere.

Try This: Audit Your Current Setup (15 minutes)

1. List every project you’ve created in Claude—OR think about the threads you find yourself starting over and over again

2. Look at the custom instructions in your projects, or notice what context you keep re-explaining in those repeated threads

3. Ask: what’s duplicated? What do I rebuild or re-explain because I couldn’t access it elsewhere?

4. Those duplications are your first candidates for building bigger

What Others Are Actually Building

When AI Blew My Mind put out that call, the responses didn’t just show me what was possible. They showed me how differently people were thinking about the problem.

The article organized submissions into categories, and each one revealed a different angle on thinking bigger.

Writers and Content Creators built for voice consistency, editorial feedback, and content repurposing. Not "here's how to write a blog post"—but "here's how to maintain my voice whether I'm drafting a newsletter, scripting a video, or writing a sales page." One setup, multiple outputs.

Marketers built for audience analysis, campaign planning, and messaging frameworks. The pattern: instead of rebuilding their brand positioning every time they started a new project, they created something that carried that context forward automatically.

Business Ops built for process documentation, meeting summaries, and decision frameworks. These weren't tied to a single workflow—they were designed to plug into whatever came up.

The thread that connected all of them: nobody was building for one use case. They were building for repeated problems that showed up across their work.

That’s the shift I’d been missing. I was asking “what does this project need?” They were asking “what problem do I keep solving—and how do I stop solving it manually every time?”

Looking at what others built didn’t just give me new ideas; it also inspired me. It gave me a different question to start from.

The Shift

I started this thinking I was ahead. I’d built things. I was using Claude more intentionally than most people I know.

Then I saw what others were building, and realized the gap wasn’t effort—it was approach. I was building for projects. They were building for problems that repeat.

The shift isn’t complicated. It’s just a different question to start from:

What do I keep solving manually that I could solve once?

You don’t need to rebuild everything. Start with one thing—the context you’re most tired of re-explaining. Build it bigger. See what changes.

And if you want to see what sparked this whole rethink, check out the 6 Claude Skills examples from the AI Blew My Mind community. The examples might make you realize you’ve been thinking too small, too.

It worked for me.

Last week, I was updating a client's course content. New lessons, revised material, the usual.

The old me would have opened both documents side by side. Gone line by line. Compared, edited, revised. Checked my work. Revised again. It’s how I’ve done content updates for years... because that’s how you do it right.

I caught myself reaching for that familiar process. And then I stopped.

Instead, I uploaded both versions to Claude and asked it to compare them and suggest changes. Ten minutes later, I had a clear summary of what needed updating. But here’s where it got interesting. I grabbed the code from the existing page and asked Claude to make the adjustments directly.

What would have taken me half a day took less than an hour. Same quality. Fraction of the time. Saved my sanity and saved the client money.

That moment stuck with me. Not because of the time saved (though that was nice). Because I almost didn’t do it. My old rules were pulling me back toward the line-by-line approach, even though I knew a better way existed.

“The hardest part of working with AI isn’t learning the new stuff. It’s unlearning the rules I spent years acquiring.”

That line came out of my mouth during a conversation with Kim Doyal. She paused, said it was quite the aha moment, and told me I should share it.

So here I am.

Your experience is the problem.

Here’s what nobody tells you about being good at what you do.

The principles that made you successful? The hard-won knowledge from years of trial and error? The instincts you’ve built through thousands of hours of practice?

They can become the exact things holding you back.

Not because they were wrong. They weren’t. They worked beautifully... in the context where you learned them.

The problem is, context has changed. Dramatically. And we’re still running old programs in a new operating system.

I’ve been in this game for over seventeen years. I remember hand-coding HTML in a text editor. Building databases from scratch. Debugging systems line by line. Every one of those experiences taught me something valuable. Every one of them created a rule in my head about “how things work.”

Rules like:

• Research thoroughly before you start anything

• Build it yourself if you want to understand it

• Follow the established process because that’s how professionals work

These weren’t just habits. They were principles I’d earned. The kind of hard-won knowledge that becomes automatic.

And automatic is exactly the problem.

Here’s what unlearning actually looks like in practice.

You sit down to work. You know there’s a faster, smarter way to approach the problem. You’ve seen it. Maybe even used it once or twice. But something in your brain keeps pulling you back to the familiar path.

That pull isn’t ignorance. It’s experience.

And that’s what makes it so hard to override.

I catch myself doing this constantly. I’ll start a project with every intention of using AI tools to move faster. Halfway through, I’m back in my old patterns. Researching for hours before taking action. Following processes designed for a world that no longer exists.

The wheel spins, but the cart doesn’t move.

What’s actually happening is a conflict between two kinds of knowledge. There’s what I know intellectually (AI can handle certain tasks faster and often better). And there’s what I know in my bones (the accumulated instincts from thousands of hours of doing things a certain way).

When those two conflict? Bone-deep knowledge usually wins. Not because it’s right. Because it’s automatic.

The difference between people who adapt quickly and those who struggle isn’t intelligence or technical skill. It’s having clear context for what you’re actually trying to accomplish.

The breakthrough wasn’t forcing myself to use new tools.

It was building a foundation that made the shift feel natural.

When you know your business deeply (what makes it work, what makes it unique, what problems you’re actually solving), you can evaluate new approaches without losing yourself in them. You can ask, “Does this serve what I’m already doing well?” instead of “Should I do what everyone else is doing?”

That foundation becomes a filter. It helps you decide what to keep from your old playbook and what to let go of. Without it, you’re just grabbing at tactics with no way to evaluate whether they fit.

I’ve been building what I call a context library. A collection of documents that capture the essential context about my business, my approach, and my thinking. Sounds almost too simple to matter.

But here’s what I noticed: When I start a conversation with Claude using that context, the results are dramatically different. Not because the AI is smarter. Because it’s working with material that reflects my actual situation.

The irony?

Building that context library required me to unlearn one of my deepest habits. The assumption that context lives in my head and doesn’t need to be articulated.

For years, I operated with implicit knowledge. Things I understood so well I never bothered to write them down. That worked fine when I was the only one doing the work.

But AI can’t read your mind. It can only work with what you give it.

Catching old patterns is the key.

If you want to start noticing where your old rules might be creating friction, here’s something you can try this week.

Next time you sit down to work on something and feel that familiar pull toward your usual approach, pause. Ask yourself three questions:

1. What rule am I following right now?

Name it out loud. “I need to research this thoroughly before I start.” “I should figure this out myself before asking for help.” “I need to have all the information before I can make a decision.”

Just making the rule visible is half the battle.

2. Was this rule built for this situation?

Most of our rules were built in a different context. The rule might have been perfect for 2015. The question is whether it still fits in 2025.

3. What would I try if I loosened this rule for one hour?

You’re not abandoning the rule forever. You’re experimenting with holding it lightly. What would you do differently if you gave yourself permission to try another way?

Here’s what this looks like in practice.

Say you’re working on a proposal and catch yourself deep in research mode. Gathering information, reading articles, compiling notes.

Pause and name the rule: “I need to understand everything before I can write anything.”

Ask if it fits: “This rule helped me avoid embarrassing mistakes early in my career. But right now, I’m not writing a dissertation. I’m drafting a proposal I’ll revise anyway.”

Try loosening it: “What if I spent 20 minutes talking through my initial thinking with Claude, let it surface questions I haven’t considered, and then did targeted research on the gaps?”

Here’s a prompt you can copy and paste:

I'm working on [describe the task]. Before I dive into research, help me think through this:

1. What are the key questions I should be able to answer?
2. What assumptions am I probably making that I should check?
3. What's the minimum I need to know before I can start a rough draft?

Push back if you think I'm overcomplicating this.

That’s the shift. Not from careful to careless. From automatic to intentional.

Here’s what staying stuck in old patterns actually costs you.

• Time you can’t get back. Every hour spent on the line-by-line approach when a smarter method exists is an hour you could have spent on work that actually requires your judgment.

• Money (yours or your client’s). That course update I mentioned? The old approach would have cost my client significantly more. Not because I was padding hours. Because the process itself was inefficient.

• Mental energy for the wrong things. The cognitive load of grinding through tasks the hard way leaves you depleted for the work that matters. The strategic thinking, the creative problem-solving, the relationship building.

• Falling behind while feeling busy. This is the sneaky one. You’re working hard. Putting in the hours. But the people who’ve loosened their grip on old rules are moving faster with less effort. And the gap widens.

The friction you feel isn’t a sign that you’re behind or not getting it. It’s a sign that you’ve invested deeply in your craft.

The question isn’t whether you’ll feel resistance. It’s whether you’ll let that resistance make your decisions for you.

The weight of experience.

I want to say something that might sound obvious, but needs to be said anyway.

You’re allowed to find this hard.

If you’ve built a career doing things a certain way, and now the landscape is shifting, it’s completely reasonable to feel friction. That friction is evidence that you’ve invested deeply in your craft. That’s not a weakness. That’s the weight of experience.

The goal isn’t to become someone who never hesitates. It’s about becoming someone who can sit with the discomfort of not knowing, try a different approach, and honestly evaluate whether it worked.

I still catch myself spinning my wheels. I still default to old patterns more often than I’d like. But I’m getting better at noticing when it’s happening.

And that noticing? That’s the skill.

Sometimes you have to unlearn to relearn. That’s not failure. That’s growth with more layers.

I’m curious about your experience with this.

What’s one rule or process you learned years ago that you suspect might be holding you back now?

Not a general category. A specific thing. The way you research. How do you start projects? What do you think you need to know before you can begin?

One thing I’m working on:

I’ve been developing a Context Library Workshop. A structured exercise to help you build three cornerstone context pieces for your business. These are the documents that capture what makes your work valuable, how you approach problems, and what you’re actually trying to accomplish.

I’m looking for two people to work through this with me. Whether you’re just starting to explore AI tools or you see the opportunities and want to move more intentionally, getting this foundation in place changes how you work with AI.

If that sounds useful, mention it in your reply or send a DM. Tell me where you are in your AI journey, and I’ll follow up with details.

Last week, I got a prompt from The Neuron that looked genuinely useful. Instead of saving it, I tested it. Took ten minutes. Refined it for my actual workflow. Used it twice that day. Deleted the original.

That’s when it hit me: the prompt that works is the one you test today. The one you save for someday? That’s just a different kind of hoarding.

I didn’t always think this way. For months, I did what most people do. Subscribed to newsletters specifically for their prompts. Copied the good ones into a Notion database. Tagged them. Told myself I’d circle back when I had time.

My prompt library grew. My actual prompt usage didn’t.

Sound familiar?

We spent years accumulating free PDFs, swipe files, and courses we never finished. We told ourselves it was research. Preparation. Building a toolkit for someday.

Then AI showed up, and we started doing the exact same thing with prompts. Different medium. Same pattern. Same graveyard.

The database gets bigger. The “someday” pile grows. And the gap between collecting and actually using widens every week.

Why Your Prompt Organization System Isn’t the Problem

Most people think the problem is organization. They believe if they just had a better system... better tags, better folders, a smarter way to categorize prompts... they’d actually use them.

But here’s what I discovered: the system isn’t the problem. The collecting is.

Every time you save a prompt “for later,” you’re making a tiny decision to not engage with it now. And that decision compounds. One saved prompt becomes ten. Ten becomes fifty. And somewhere along the way, the act of collecting starts to feel like progress.

It’s not. It’s a preparation theater.

I know this because I lived it. My Notion database had prompts organized by category, use case, and even AI model. Beautiful system. I opened it maybe once a month.

Meanwhile, the prompts I actually used? They never made it into the database at all. I tested them in the moment, refined them, and moved on.

The library was a monument to good intentions. The real work happened outside of it.

If you keep building the collection, here’s what happens:

• You spend more time organizing prompts than testing them

• You forget why you saved half of them in the first place

• You feel behind even though your database is full

• You mistake the size of your library for readiness

The uncomfortable truth? A smaller prompt habit that you actually use beats a massive library you admire from a distance.

What I Learned When I Stopped Saving Prompts

I realized my prompt library wasn’t helping me when I went looking for something I knew I’d saved. Took me fifteen minutes to find it. Then another ten to remember why I thought it was useful. By the time I actually tested it, I’d burned almost half an hour on a prompt that didn’t even work for my situation.

That was my wake-up call.

The system I built to save time was costing me more than it saved.

This is the part when I realized.

I already had everything I needed to use prompts effectively. I just had it backwards. I was treating prompts like collectibles when they’re actually disposable tools. You don’t save a sticky note forever. You use it, then throw it away.

What if I treated prompts the same way?

Put this to the test.

Instead of randomly saving prompts gained for others, I put it to the test first:

1. No more saving by default. When I saw a promising prompt, I tested it immediately or let it go.

2. 10-minute rule. If I couldn’t test and evaluate a prompt in 10 minutes, it wasn’t worth my time right now.

3. Refine or delete. After testing, I either adapted it for my specific workflow or deleted it entirely. No “maybe later” pile.

4. One active prompt per category. Instead of fifty options for summarization, I kept one that actually worked.

What surprised me was how little I missed. The prompts I let go? I never thought about them again. The ones I tested and refined? I used them repeatedly.

After a few weeks, something shifted.

“The value of a prompt isn’t in the saving. It’s in the testing.”

I stopped being beholden to new prompts. I stopped opening newsletters with the thought of “I should save this.” Instead, I read them with a simple filter: Is this useful to me right now? If yes, test it. If no, move on.

My prompt “library” shrank to maybe a dozen. My actual prompt usage doubled.

This pattern applies beyond prompts

It’s the same trap with tools, templates, frameworks, and tactics. We collect because collecting feels safe. Testing feels risky. What if we pick wrong? What if there’s a better one?

But here’s what I learned the hard way: the prompt you tested and refined for your workflow will always outperform the “perfect” prompt you saved but never touched.

The gap isn’t between good prompts and bad prompts. It’s between tested and untested.

The 10-Minute Framework That Replaced My Prompt Database

Why “Save for Later” Was Costing You

Every prompt you saved without testing created a small decision debt. You told yourself you’d evaluate it eventually. But eventually never came, and now you have a database full of untested possibilities and no clear sense of which ones actually work.

Which means you’re no closer to using AI effectively than you were before you started collecting.

Here’s what changed for me: I stopped asking “Is this worth saving?” and started asking “Is this worth ten minutes right now?”

The 10-Minute Prompt Test

When you encounter a new prompt, run it through this filter before you do anything else:

1. Test it raw. Copy the prompt exactly as written. Run it with a real task you’re working on today. Not a hypothetical. Something actual.

2. Note what breaks. Where did the output miss? Too generic? Wrong format? Missing context about your situation?

3. Refine once. Make one adjustment based on what broke. Add your context, change the output format, and narrow the scope. Run it again.

4. Decide: use, adapt, or delete.

   • If it worked after one refinement, save your version (not the original)

   • If it needs heavy modification, it’s not the right prompt for you right now. Delete it.

   • If it flopped completely, delete it without guilt.

Total time: 10 minutes. You now know more about that prompt than you would after six months in a database.

Two Prompts Worth Testing Today

Here are two from The Neuron that passed my filter. Don’t save them. Test them.

The “Compare and Decide” Prompt:

Compare [Option A] vs [Option B] for [my situation]. 
Output a table with: features, tradeoffs, risks, cost/time, best-fit. 
Then give a recommendation with clear reasoning and "if X, choose A; if Y, choose B."
Research and show any hidden costs.
Include a short 'What would make me regret this?' section for each option, and end with a 3-step next action plan (trial, pilot, or due diligence).
Give a confidence level regarding how likely it is to be the right choice given what you know about my needs today and me as a person.

Best for: Tool decisions, vendor comparisons, build vs. buy choices.

Downside: Requires clear context about your situation upfront or the output stays generic.

The “Give Me Options” Prompt:

Generate 10 distinct approaches to solve [problem]. 
For each: give a one-line summary, best use case, and one downside. 
Then recommend the top 2 based on [my priority: speed / cost / quality / risk].

Best for: When you’re stuck on approach and need to see the landscape quickly.

Downside: Can feel overwhelming without a clear priority filter.

The Prompt You Keep

After testing, your saved prompts should meet one criteria: you’ve used them at least twice on real work.

Not “this looks useful.” Not “I might need this.” You’ve tested it, refined it, and it delivered.

Everything else is decoration.

The Real Reason Most Prompts Fail (It’s Not the Prompt)

When I talk about using AI and LLMs, my clients often feel frustrated because their results are usually… off.

They believe the problem is finding (copying) the right prompt. The magic combination of someone else's ideas that unlocks useful output.

But here’s what I’ve noticed: the prompts aren’t the issue. The context is.

That “Compare and Decide” prompt above? It works beautifully when AI knows your situation, your priorities, and your constraints. Run it cold, with no context? You get generic output that requires heavy editing.

This is why prompt collecting fails. You’re gathering tools without giving them anything to work with. It’s like collecting recipes but never stocking your kitchen.

The shift happens when you stop hunting for better prompts and start giving AI better context. A clear description of their business. Their audience. Their voice. Their constraints.

Suddenly, even simple prompts work harder.

My prompt library got smaller. But my context documents got richer. That’s what actually moved the needle.

How to Evaluate Any Prompt in 10 Minutes

Here’s the smarter approach, step by step.

The Old Way: Save prompt. Tag it. Tell yourself you’ll test it later. Open your database in three months and wonder why you saved half of what’s there.

The Smarter Way: Test immediately. Refine once. Decide now.

The Exact Process

Step 1: Grab a real task (2 minutes)

Don’t test prompts with hypotheticals. Find something you’re actually working on today. An email you need to write. A decision you’re weighing. A document you’re drafting.

Step 2: Run the prompt raw (3 minutes)

Copy it exactly. Paste it into your AI tool with your real task. See what happens without modification.

Step 3: Identify the gap (2 minutes)

Where did the output miss? Usually it’s one of three things:

• Too generic (needs your specific context)

• Wrong format (needs output structure specified)

• Wrong scope (needs narrower focus)

Step 4: Refine and rerun (3 minutes)

Make one adjustment. Add context about your business. Specify the format you need. Narrow the scope. Run it again.

Step 5: Make the call

• Works after one refinement? Save your refined version.

• Needs heavy rework? Not the right prompt for you right now. Delete it.

• Flopped entirely? Delete without guilt.

You just learned more in 10 minutes than you would in six months of saving.

TLDR Version

• Collecting prompts feels productive, but creates the same “someday” pile as PDFs and courses

• The value of a prompt is in the testing, not the saving

• 10 minutes of real testing beats six months in a database

• Prompts fail because of missing context, not because they’re the “wrong” prompt

• Keep only what you’ve used twice on real work. Delete everything else.

You don’t need a bigger prompt library.

You need a clearer filter for what’s worth your time and a better context to make any prompt work harder.

The prompts you test today will always outperform the collection you admire from a distance.

So here’s my question: What’s one prompt you’ve been “saving for later” that you could test in the next 10 minutes?

One More Thing

If you noticed the real issue here... that prompts fail because of missing context, not missing prompts... you’re ready for the next step.

Next week, I’m running a workshop: Teach AI Your Business Once.

In this working session, you’ll build a simple Context Library for your business. Core Identity, Voice & Tone, and Audience documents you can drop into any AI tool.

Instead of starting from scratch every time, you’ll leave with infrastructure that makes AI sound more like you and need far less editing.

No more prompt hunting. No more “someday” piles. Just context that makes everything work better.

After reading ’s piece about using AI in browsers, I knew I was only scratching the surface with Claude on Chrome.

I mean, I’d been using it. Diagnosing web issues for my WordPress agency. Summarizing articles and videos. The usual stuff. It worked fine for that.

But where I missed the mark was execution. The doing part. The stuff that eats hours every week without me even noticing.

What Changed This Morning

This morning, I had Claude triage my inbox from the last two weeks of messages. Not just scan them. Actually sort through the chaos and surface what mattered.

Then it added two critical tasks to my calendar with links back to the original emails. Created a priority list of outstanding items. The whole thing took maybe fifteen minutes.

Here’s what that actually gave me: I could make decisions based on needs and urgency instead of funneling messages to figure it out myself.

That funneling? That’s the hidden time killer. You don’t track it because it doesn’t feel like work. It feels like checking email. But it’s actually decision fatigue dressed up as productivity.

The prompt I used:

Review my inbox from the last two weeks. Categorize messages by:
- Requires action from me (with urgency level)
- Waiting on someone else
- Reference/FYI only
- Can be archived or ignored

For anything urgent, identify the specific next step and suggest calendar time to handle it.

The Insurance Quote Experiment

Seeing how I want to get some new insurance quotes, I pulled a copy of my policies, extracted the details, and had Claude help me complete the quote forms.

If you’ve ever filled out insurance forms, you know the drill. They want the same information formatted slightly differently. Policy numbers here, coverage limits there, effective dates in this format, not that one. It’s tedious and error-prone.

With Claude seeing both the source documents and the quote form, it became actionable instead of a copy-paste marathon. Easy to complete a few quote requests.

The prompt I used:

I'm looking for new insurance quotes. Help me complete this quote form:
1. Fill in my standard info: [paste your details or reference open document]
2. For coverage questions, reference my current policy details
3. For coverage needs: [your requirements or "match current coverage"]
4. Review each completed section with me before proceeding

STOP before hitting submission.

And Yes, Still Solving Web Issues

Of course, I also solved some simple web issues. That’s still valuable. A client’s page wasn’t showing some errors, and instead of digging through dev tools myself, Claude diagnosed the issue in about thirty seconds. And it became a quick one-minute fix on my end.

The prompt I used:

This page isn't loading correctly. Check:
- Console errors (explain in plain English, not dev speak)
- What's failing to load and why
- Whether this is a browser/cache issue or a site problem
- Give me 2-3 things to try, starting with the simplest

That saved me precious time. But it’s also what I was already doing. The inbox triage and form completion? That’s new territory.

The Real Shift: Eliminating the Mental Refocus

Here’s the thing about working in the browser with context-aware AI: it helps eliminate the need to refocus across multiple screens or copy and paste.

Every time you switch tabs to grab information, then switch back to enter it somewhere else, your brain has to reorient.

Where was I?
What was I doing?
What comes next?

Multiply that by fifty times a day, and you’ve lost hours to context switching without ever being able to point to where they went.

When Claude can see what you’re looking at and what you’re working on simultaneously, that switching disappears. The information flows where it needs to go without you being the conduit.

What I’m Testing Next

I’ve got a few experiments queued up that align with how I actually work:

1. Content research synthesis. When I’m pulling together a cornerstone article, I usually have five or six tabs open with reference material.

   Instead of reading everything, taking notes, then writing... having Claude build a synthesis document while I browse. What themes keep appearing? What contradicts? What’s missing?

2. Workflow documentation. I’ve got processes I do repeatedly but haven’t documented.
   Next time I walk through one, I’ll have Claude watch and capture the steps as I go. Real documentation from real work instead of trying to remember later.

3. Subscription audit. Opening each tool I’m paying for, having Claude pull the pricing page and feature list, then building a comparison of what I’m actually using versus what I’m paying for.
   The annual “why do I have this?” review, but faster.

The pattern is the same: anywhere I’m currently the middleman between information and action, Claude might be able to handle the translation directly.

Tools Worth Trying

If you want to experiment with browser-based AI, here’s where I’d start:

Claude for Chrome (what I’m using). The extension sits in your sidebar, and you can see whatever tabs you have open. You control when it’s active. It waits for your approval before taking action, which matters if you’re cautious about AI doing things autonomously.

Wispr Flow (voice layer). If typing prompts interrupt your flow, Wispr adds voice dictation. Talk to Claude instead of typing. It helps you stop self-editing while typing so you can get your real ask in the first place.

Your existing tools first. Before adding anything new, check what you already have. ChatGPT has a browser feature. So does Perplexity. If you’re paying for something with browser capability, test the edges of what it can do before subscribing to something else.

The point isn’t to collect more tools. It’s to actually use the ones you’re already paying for.

The Permission You Might Need

If you’re like me, you’ve probably pigeonhole your AI tools into specific use cases. “This is my writing tool. This is my research tool. This is my code helper.”

But browser-based AI doesn’t care about your categories. It sees what’s on screen. That’s it.

The question isn’t “what is this tool for?” The question is “what can this tool see, and what could it do with that visibility?”

I used Claude in Chrome for diagnostics and summaries because that’s where I started. The inbox triage and form completion were always possible. I just never asked.

Maybe you haven’t either.

What’s one thing you do in your browser every week that involves shuffling information between tabs? That’s probably your next experiment. Reply and tell me what you’re going to try.

If You’re Catching Up

This connects to a few experiments I’ve been running:

• Small experiments during chaos. Same energy as today’s piece.

• Why I moved my Weekly 5 from Claude to Notion. Tools should fit where your work already happens.

Inspired by Joel Salinas’s article on AI browser usage. His take focused on safety and the choice between dedicated AI browsers versus extensions. Mine is simpler: I was underusing what I already had.

Two lightweight experiments that solved a problem I didn't know I had.

My son’s birthday is New Year’s Eve.

For the last 30+ years, the week between Christmas and New Year’s isn’t about wrapping up and relaxing. Between birthday logistics and the last week of the current year, I usually don’t take my breather before January hits.

The “new year, new me” energy doesn’t land for me until January 3rd at the earliest.

By then, everyone else is already running.

I used to fight that timing. Now I work with it.

These last few weeks, I’ve been running lightweight experiments... not to overhaul anything, just enough to keep my head in the game.

Two of those experiments connected in a way I didn’t expect.

A Simple Weekly Planning System (Built in Claude)

I created a simple planning system called the Weekly 5.

The idea: Pick five things each week that advance DigiNav. Not necessarily revenue-generating, just forward motion.

Sometimes it’s a new experiment. Sometimes it’s cleanup and organization. Sometimes it’s learning something I’ve been putting off.

I built it as a Claude project to handle three things:

• Weekly reflection on what got done

• Planning the next week’s five priorities

• Checking my calendar for actual time available

It wasn’t difficult to create since Claude helped me write the instructions.

Here’s the core prompt (cleaned up so you can adapt it):

You are assisting with a Weekly Reset.

Context:

The week is the unit of commitment.
Exactly five items define success.
Everyday/maintenance work must NOT be included.
This is a light-capacity week unless stated otherwise.
Items must be finishable in one sitting or two short sessions.
You may make strong suggestions, but I make final decisions.

Inputs you will receive:
Brain dump list
Weekly items candidates
Calendar constraints (if provided)

Your tasks:
- Identify which candidate items are actually everyday/maintenance work.
- Identify which items are too vague or too large as written.
- Propose shrunk, finishable versions of those items.
- Recommend a final set of exactly five items that fit the week’s capacity.
- Wait for explicit confirmation before writing anything to {{your database}}.

Do not optimize for productivity. Optimize for clarity, calm, and finishability.

Once the five items are locked in, they get written to a Notion database with the week’s date. Simple view: what’s due between Monday and Sunday.

What I learned:

• Simplified the review and planning process significantly

• Got too granular at first, which made the whole thing cumbersome

• The sweet spot: Claude does the sorting, I do the input

It was working.

But there was a problem. The system writes to Notion... except when it doesn’t. The connection wasn’t reliable, which meant I was still manually copying things over.

Creating a Custom AI Agent in Notion

Separately, I’d been experimenting with Notion AI.

I came across an article on Solopreneur Code by @anferneeck about creating a custom AI agent in Notion. The approach clicked for me... a structured prompt that gives the AI agent clear modes and context.

I already had a mascot named VITA. She’d been sitting in my brand assets without a real job. This felt like a good use for her.

I loaded in the context documents I’d already built:

• Audience profiles

• Tone and voice guidelines

• Content themes

• Content workflow

• Product strategies

• And more

The setup took about 20 minutes. A good use of time for the clarity it would save me in the long run.

The modes I settled on:

• Foundation: Brainstorming, Project Planning, Strategy

• Execution: Content, Marketing, Sales, Email Communications

• Support: Decision Making, Research & Learning

What started as trying the prompt turned into a game plan to streamline Notion and use the space better.

And VITA worked well. Really well.

For tasks that involved writing to Notion databases, having the AI agent live inside Notion made the whole process smoother.

Why the Weekly 5 Belonged in Notion All Along

Here’s where the two experiments collided.

The Weekly 5 writes to a Notion database. That’s the whole point... tracking what I commit to, what I complete, what sits in limbo.

The reflection and planning process generates entries that need to be updated in that very database.

I’d built it in Claude because that’s where I was already working and Claude is able to write to Notion.

But the output connection sometimes worked and other times not.

Which meant I was constantly copying things over, creating friction I didn’t need.

The realization: The Weekly 5 should live where the database lives. Not where I happened to be comfortable. Not where I’d already started. Where the work actually belongs.

The Feature I Didn't Know Notion Had

One reason I’d kept the Weekly 5 in Claude: calendar integration.

Part of the Friday planning process involves looking at my upcoming week... what commitments are already locked in, whether I’m overloading myself before I even start.

Claude can connect to Google Calendar. Notion couldn’t.

Or so I thought.

Turns out Notion added Google Calendar integration recently. It can’t write or push notifications, but it can read. It can pull my commitments into the planning view.

That was the last barrier. Gone.

Stop Asking "Which Tool Is Best"

This wasn’t a dramatic pivot.

It was a small adjustment that removed friction I’d been tolerating.

But the underlying principle matters:

Sometimes the right tool choice reveals itself when you stop asking “which tool is best” and start asking “where does this work actually live?”

I didn’t need a better planning system.

I needed to stop fighting against my actual workflow.

The Foundation That Made Both Experiments Easy

Both experiments moved quickly because I had context documents ready.

Business positioning. Voice. Audience profiles. Frameworks... all documented and portable.

When I created VITA, I didn’t have to explain my business from scratch.

When I moved the Weekly 5 to Notion, the context came with it.

That portability is the thing I keep coming back to.

Your AI tools are only as useful as the context you give them. And the context you’ve already documented is usable anywhere.

I’m running a Context Library workshop in January focused on exactly this: building the foundation that makes every AI tool work harder.

More details coming soon.