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.

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.

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.

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.

Sometimes you have to step back from big projects and just work on the little things.

Right now, I’m in the middle of buying and selling a house, surviving a move, and managing the holidays. I don’t have bandwidth for major initiatives. Honestly? I don’t want to start anything big at the end of the year anyway.

But here’s what I’ve learned about momentum: it doesn’t require massive action. It requires forward movement. Any forward movement.

So this week, instead of building grand systems or launching new offers, I focused on three small experiments. None of them is a game-changer on its own. But stacked together during a low-bandwidth season? They’re exactly what kept me from stalling out completely.

Maybe one of these will spark something for you. Or maybe it’ll just show you that you’re not in this chaos alone.

Small Wins Aren’t Consolation Prizes

Most people think progress requires significant blocks of time. The big project. The complete system overhaul. The perfect conditions.

But here’s what I discovered while juggling moving boxes and family obligations: waiting for perfect conditions is how momentum dies.

The real issue isn’t that you lack time for big projects. It’s that you’ve convinced yourself that small projects don’t count.

They do.

When I looked at what actually moved my business forward this week, it wasn’t some grand strategy session. It was three simple experiments that took maybe an hour each. And now I have:

• A daily inbox triage that saves me 20 minutes of decision fatigue every morning

• Actual feedback on my prompting habits from the AIs I use most

• A reflection process that’s helping me think clearly about 2026 without the usual productivity planning pressure

If I’d waited for “real time” to work on “real projects,” none of this would exist.

Here’s the cost of waiting: You lose the compound effect of small wins. One tiny improvement doesn’t feel significant. But three small wins this week, plus three next week, plus three the week after? That’s how you end a chaotic season ahead instead of behind.

How Three Simple Experiments Became Actual Systems

I’ve been running experiments all year. Taking existing processes and adding AI or automation to them. Figuring out where the human hand matters and where it doesn’t.

But here’s what kept happening: I’d run an experiment in Claude, then another in ChatGPT, and I was all over the board trying to find what I needed later.

So I created a simple Notion page with toggle dropdowns. For each experiment, I capture three things:

1. The initial prompt or brainstorming session (linked to the conversation)

2. The output (what actually got built)

3. A brief explanation of what worked or didn’t

That’s it. Nothing fancy. But now, when I look back, I can see what I’ve already figured out. No more recreating the wheel.

Here’s what emerged from this week’s experiments.

Experiment 1: Newsletter Triage (The Daily Inbox Problem)

I subscribe to a lot of Substack newsletters. You all sharing information is amazing. But it becomes overwhelming when you see how many unread posts are waiting.

I wanted something simple.

Look at what’s in my inbox > Triage it > These are the ones to read first. These can wait. These you can skip entirely.

So I started a brainstorming conversation with Claude. And one of the first things it said was: “This is gonna take some time because you have everything in one bucket, and there are things that aren’t important in the immediate.”

Fair point.

We came up with a new label structure in Gmail. I now have three labels under my main Substack catch-all:

• Politics (separate because it’s not business-relevant daily)

• System notifications (subscriber alerts, follows, etc.)

• Triage (the actual newsletters I need to sort through)

Then I built a Claude project. All I have to do is click “Triage please,” and it looks at what’s in my inbox and breaks it into:

• Read first and respond (time-sensitive or directly relevant)

• Skim later (might be useful, not urgent)

• Skip (not relevant today)

That’s it. I click a button. I get a game plan. I’m not staring at 47 newsletters trying to decide where to start.

Time invested: About 45 minutes for the Gmail restructure and Claude project setup.

Time saved: 15-20 minutes of decision fatigue every single morning.

Experiment 2: Evaluate My Prompting (The Self-Audit)

AI has changed exponentially lately. I wanted to ensure the context I provided, and the way I prompted, were making the best use of the tools.

So I ran a simple experiment. Same prompt in both ChatGPT and Claude:

“After looking at how I prompt for results, please tell me how I’m doing, how can I improve, and what I’m missing. Format the output with clear headings and organization.”

What ChatGPT said: You’re a highly specific user with a strong system mindset. Here’s what you’re doing well, where you’re struggling, what you’re missing, and how to improve. Then it offered to create a cheat sheet and template for more consistent prompting.

It also noted that I randomly jump from thought to thought. (ADHD kicking in. Guilty.)

What Claude did differently: It didn’t just immediately respond. It said, “I’ll be happy to do this, but I need some context here.” I had to point it to projects we’d already worked on and recent conversation threads. Then it went back, reviewed everything, and gave me feedback based on my actual patterns.

Both approaches were useful. But they confirmed something important: the same prompt in different AIs gets different results. And if you’re using multiple tools, it’s worth understanding how each one processes your requests.

The output: I now have clearer templates for both platforms. And a list of habits to break (like assuming the AI remembers context it doesn’t have).

Time invested: About 30 minutes total.

Ongoing value: Better responses from every future prompt.

Experiment 3: The 2026 Reflection (Not a Productivity Plan)

Since I have some downtime during this chaos, I wanted to reflect on 2025 and think about what I actually want for 2026.

But here’s the thing: I didn’t want the same old “map out the year” productivity planning that everyone does in January. I wanted to gut-check and vibe-check everything.

So I started with a prompt:

“You are my favorite thinking partner. Today we’re going to just talk about planning for 2026. I don’t want the same old planning everyone else does. I want to be asked questions that make me think about what really matters to me in the upcoming year.”

Then I added backstory. What’s happening in my life right now. Some things I’m planning to tackle. Random context that felt relevant.

I used Whisper Flow to speak it instead of typing. That way I didn’t self-edit. It came out in my actual words.

What happened in ChatGPT: It reframed what I said to confirm it understood. Then it started asking me questions about what was important. When I told it this wasn’t about productivity or actual planning, just thinking about what matters, it adjusted. At one point it asked: “Who are you becoming right now?”

That question hit different.

What happened in Claude: Similar start, but Claude kept trying to pull me back toward implementation planning. I had to keep redirecting it. When I said I just wanted to experiment and not worry about outcomes, it started swearing at me. (Overcorrected when I asked it to be less sterile. Had to tell it to dial back the cuss words.)

The ChatGPT conversation stayed more even-keeled for this particular use case.

Where I landed: I’m still working through this one. But I’ve already surfaced some important themes:

• Replace some agency income so I can decide what to do with that business

• Learn by doing, not consuming (I noticed I was taking in too much content without applying it)

• Get back to the version of me who experimented without worrying about outcomes

Time invested: About an hour across two sessions.

Ongoing value: Clarity I wouldn’t have gotten staring at a blank planning doc.

The Real Lesson: Using AI Doesn’t Have to Be Complicated

These three experiments have something in common.

None of them required building massive automations. None of them required technical expertise. None of them required waiting for the perfect project.

They’re just simple applications of AI that saved time, improved my process, or helped me think more clearly.

• Triaging newsletters so I have a game plan instead of a full inbox

• Evaluating my prompting so I get better responses from the tools I already use

• Reflecting on the year with a thinking partner instead of a blank page

Everything doesn’t have to be about creating these big vibe-coded automations or game-changing systems. Sometimes it’s just about making better decisions and thinking about things differently.

What This Looks Like in Practice

When I talk to people about AI integration, they usually think the problem is not knowing which tools to use. Or not having enough technical skills. Or not having time for “real” implementation.

But here’s what the conversation usually reveals: they’re waiting for conditions that don’t exist.

The moment things shift is when they realize small experiments count. That you can make meaningful progress in an hour. That “low bandwidth season” doesn’t mean “zero progress season.”

One person told me, “I keep thinking I need a whole day to work on my systems.” And I asked, “What could you figure out in 45 minutes?”

She built a client intake triage that same afternoon. Nothing fancy. Just a Claude conversation that helps her prioritize incoming requests. Took her less than an hour.

That’s the principle: Progress doesn’t require perfect conditions. It requires permission to start small.

The Small Wins Framework (For Your Own Chaos Season)

Here’s exactly how I approached this:

Step 1: Identify one friction point you deal with repeatedly (5 minutes) What’s something that annoys you every day or every week? For me, it was the newsletter inbox. For you, it might be deciding what to work on first, or processing client requests, or planning your content.

Step 2: Ask an AI to help you think through it (15-30 minutes) Don’t start with “build me a system.” Start with “help me think through this problem.” Let the conversation surface what’s actually causing the friction.

Here’s a prompt you can steal:

“I have a recurring friction point in my work: [describe it]. I don’t need a complete solution yet. I need to understand why this keeps being annoying and what a simpler approach might look like. Ask me clarifying questions before suggesting anything.”

Step 3: Build something small you can test immediately (15-30 minutes) Not a complete system. Just one piece you can try tomorrow. The newsletter triage wasn’t a complete email management overhaul. It was three labels and a Claude project. That’s it.

Step 4: Capture what you learned (5 minutes) Add it to a simple tracking system. The prompt, the output, what worked. Future you will thank present you.

Time invested: About an hour per experiment.

Compound effect: Three small wins this week means you end December ahead instead of behind.

Your December (And Beyond)

You can see that none of these experiments are revolutionary on their own.

But stacking small wins during the low-bandwidth season? That’s how you keep momentum without burning out. You don’t have to wait for the perfect project or perfect conditions to make progress.

The real question isn’t “What big thing should I build?” It’s “What small thing could I figure out this week?”

So here’s what I want to know: What’s one small friction point in your work that you’ve been ignoring because you’re waiting for time to “really fix it”?

Reply and tell me. I want to hear about your small win.

VIDEO: Want to see these three experiments in action? Watch me walk through the Notion setup, the newsletter triage, and the 2026 reflection process: Three Small Wins for Momentum.

This is Week 3 of the “Planning Without Burning Out” series. Missed the earlier pieces?

• Week 1: How Hierarchy Planning Beats Balance Every Time

• Week 2: What I’m Actually Doing in Survival Mode

Next week: How these small experiments connect to the bigger picture of getting your context right before building plans. (Hint: It’s related to the SHIFT Your Context Workshop launching in January.)

My vision is usually close. It’s just never quite right.

Enter my husband. I’ll pick out a paint color that looks like it fits, and he’ll take one look and say something like, “This gray looks good in a small swatch but in this big room with three windows it will be ugly and bland.” Then he’ll add some white, remix the color, and suddenly the color works. Not the version in my head—a better version that actually functions in reality.

The running joke in our family: I’ve never picked a paint color that made a wall untouched.

Here’s what I didn’t realize for years: he’s not correcting me. He’s testing my theory against reality and adjusting it based on what he discovers. He treats iteration as part of design, not a sign design failed.

I was treating iteration like a dirty word.

Where Content Planning Becomes the Problem

I learned the hard way that this pattern shows up everywhere—not just in paint colors, but in systems I build.

Most people think the problem with content strategy is that you haven’t planned far enough ahead. So they plan more. They create detailed spreadsheets, map quarterly themes, anticipate every pillar and angle. They let AI generate topics based on business strategy. Then they sit down to execute.

But here’s what I discovered: the problem isn’t that planning is bad. The problem is confusing a complete mental picture with a complete design.

I spent hours mapping out 12 weeks of content for DigiNav. I had the whole thing visualized: brainstorm topics → map to refined stories → pick or create supporting video → write the article. Clean. Systematic. Complete.

I created a spreadsheet with topics, themes, which content pillar each one served, video descriptions—the whole thing. It looked perfect on screen. Organized. Strategic. Like if I just executed this plan exactly, 12 weeks of content would flow out seamlessly.

Then I opened the database in Notion and felt it immediately: this is generic fluff.

Not because the topics were wrong. Not because the framework was broken. But because I was looking at a list of content ideas that could work for anyone. They didn’t spark anything. They didn’t feel like me. They felt like exactly what AI generates when you ask it to plan content from strategy—structurally sound, contextually hollow.

Here’s where most people get stuck: They interpret that disconnect as a planning failure. They should have thought it through more. They need better strategy. So they go back and replan, hoping that more detail will create alignment.

But that’s not what was happening. And that’s not what fixes it.

When the Plan Met Reality

I looked at my beautiful 12-week plan and realized something: I’d planned the content without testing whether the planning process itself actually worked.

I’d done exactly what I do when I visualize a room. I’d created a complete picture in my head and assumed executing it would be the same as building it. Except it wasn’t. Because the moment I started executing, reality showed up.

So I stopped trying to execute the plan and started asking a different question: Why does this feel wrong?

I created a new Claude thread. I added my business context, my content pillars, my framework. And then I said: “Look at this 12-week plan I created. Something feels off. Help me diagnose what it is. This isn’t implementation—let’s talk about it. Ask me questions to clarify and call me out on my stuck points.”

Here’s what Claude came back with: “I find a disconnect. It’s structurally correct, but contextually hollow.”

That sentence stopped me. Because that was exactly it. The plan was structurally correct. It hit all my pillars. It was organized by theme. It showed strategy. But it wasn’t connected to anything I was actually building or thinking about.

Then Claude asked: “What are you actually building and navigating right now? What’s the real difference between a topic that feels generic and a topic that says, ‘Oh, I have something to say about that’?”

And finally: “Should the planner generate topics based on your real-time work rather than a pre-planned calendar?”

That’s when it clicked. The problem wasn’t that I needed to plan better. The problem was that I was treating the plan as a blueprint rather than a hypothesis. I was confusing “I’ve thought this through” with “I’ve tested this and know it works.”

From Generic Topics to Real Angles

The False Start: More Detailed Planning

My first instinct was to fix it by planning better.

So I went back to the original prompt. Made it more detailed. Added more context about my voice and approach. Specified exactly which framework should appear in which piece. Added more specificity about tone, structure, engagement hooks.

That made things worse. More planning didn’t produce better content. It produced more overthought, more constrained content that felt even further from what I actually wanted to say.

I was writing to the system instead of writing to discover what I actually thought, which is exactly the opposite of staying authentically me.

The Turning Point: The Diagnostic Question

Then something shifted. When I asked Claude to help me diagnose instead of fix, it asked me: “What are you actually building, learning, navigating right now?”

And I realized: I am building something. I’m actively working on refining my content automation process. I’m discovering what works and what doesn’t. I’m navigating the tension between planning and executing. I’m building in public, showing the messy middle. That’s real work. That’s material.

But my 12-week content plan didn’t reflect any of that. It was theoretical topics, not real work.

That’s when I understood. I wasn’t generating content topics from thin air—I was trying to. Which meant everything was generic.

My husband doesn’t visualize room color better than I do. He relies on his experience as a commercial painter to test the theory against reality. He observes what actually happens, then adjusts based on data. He treats iteration as part of design.

I was treating my planning the same way I treat visualizing rooms: as if the first picture were the final answer.

The Experiments: Testing Different Approaches

1. Tried: Let Claude generate 12 weeks of topics upfront based on my business pillars and strategy .
   Result: Organized spreadsheet. Generic topics. Nothing sparked. Felt hollow.

2. Tried: Abandon the plan entirely and write intuitively whenever I felt inspired.
   Result: Some alive pieces. No coherent strategy across them. Scattered and chaotic.

3. Tried: Identify real work I’m doing, then ask Claude to extract 5-7 different angles from that one project.
   Result: Content ideas that felt alive. Grounded in actual work. Strategic without feeling generic. Each angle sparked something.

Number three changed everything.

Angle Extraction Instead of Topic Planning

Here’s what finally clicked: I don’t need a content planner that generates topics from strategy. I need a content angle extractor that takes work I’m already doing and shows me all the different ways I can present it.

Claude said it perfectly: “What you’re actually doing is not talking about planning content. You’re talking about extracting content angles. And that’s different than planning content.”

Think about the difference:

Content Planning: “Based on your business strategy, here are topics you should cover this quarter”

Angle Extraction: “You’re working on X right now. Here are 5-7 different angles you could pull from that work that would matter to different parts of your audience”

They sound similar. They’re completely different.

Content planning starts from nothing. It generates ideas from strategy, which defaults to generic. Angle extraction starts from real work and multiplies it. It takes something alive and shows you all the ways it connects.

When I stopped asking Claude “what should I write about?” and started asking “I’m working on this—what angles can I pull from it?”—everything shifted. The content felt true. It felt grounded. It felt like mine.

Why This Looks Different When You Understand It

When I work with clients building content systems, the conversation usually starts the same way: “I need better content strategy.”

But when I dig deeper, I find they’re doing what I was doing. They’re asking AI to generate topics from strategy rather than extracting angles from the work.

One client told me: “I have plenty of content ideas when I’m working with clients. But when I sit down to plan content, nothing comes to me.”

That’s not a planning problem. That’s a sourcing problem. When you’re in the middle of real work—solving a client problem, building a system, discovering something—you see multiple angles naturally. You see how it connects to different parts of your business. You see how different audiences would relate to it.

But when you sit down to plan content in the abstract, you have nothing to extract angles from. You’re generating from strategy, which always feels generic because it’s not grounded in anything real.

Here’s the principle that applies: Generic content comes from planning without material. Grounded content comes from extracting angles from real work.

How to Actually Plan Without Overplanning

This is where most people trip up. They hear “extract angles from real work” and think it means abandoning planning. That’s wrong. It means planning differently.

The Old Way: Generate topics upfront → organize them → execute them

The Smarter Way: Do real work → extract multiple angles → organize by pillar → execute the angles

Here’s exactly how:

Step 1: Identify Real Work You’re Actually Doing (No Time Limit)

Don’t try to think of content ideas. Instead, notice what you’re actively building or navigating right now.

Examples:

• You’re refining a process in your business

• You’re working through a client problem

• You’re discovering something that changes how you think

• You’re building a system or framework

• You’re navigating a tension or challenge

Write it down: “I’m currently working on: [specific real thing]”

Step 2: Ask Claude to Extract Multiple Angles (15 minutes)

Now ask Claude: “I’m working on this [real thing]. Here are the different audiences I serve: [list them]. What are 5-7 different angles I could pull from this work that would matter to each of them?”

You’re not asking it to generate topics. You’re asking it to help you see all the ways your real work connects to different problems people are facing.

Step 3: Evaluate Which Angles Spark Something (5 minutes)

Read through the angles. Notice which ones make you think “oh yeah, I have something to say about that” vs. which ones feel obligatory.

The ones that spark you are the ones grounded in your real thinking. Those are the ones worth writing.

Step 4: Organize Angles by Pillar and Timing (10 minutes)

Take the angles that sparked you and map them:

• Which content pillar does this serve?

• When does this fit in your business cycle?

• What order makes sense?

This is the only planning you need. Not “what should I write about this quarter” but “of the angles I’ve identified from real work, how do I organize them?”

Step 5: Execute One Angle (Time Varies)

Write the piece. Don’t try to work ahead on all seven angles. Just do the next one.

While you’re writing, notice what else you’re discovering. Let that inform what comes next.

Step 6: Repeat With Your Next Real Project

Once you’ve extracted and executed the angles from the first project, move on to the next real work you’re doing. Extract angles from that. Repeat.

Why This Works:

You’re never scrambling for content ideas because you’re mining them from work you’re already doing. You’re never starting from nothing (which is how generic happens). The content stays grounded because it’s anchored in real problems and real building. And you maintain strategy without forcing ideas to fit a predetermined plan.

You’re not abandoning planning—you’re sourcing from reality instead of strategy alone.

The Stakes of Staying in Topic-Planning Mode

If you keep thinking perfect planning comes before real work, here’s what happens:

• You generate topics from strategy that feel generic because they’re not grounded in anything

• You sit down to write and feel uninspired because there’s no material to extract from

• You force yourself to write to the plan instead of writing what you actually think

• Your content feels obligated, not owned

• Meanwhile, builders who extract angles from real work are creating content that feels alive, specific, and grounded

The real cost of planning topics upfront isn’t the time spent planning. It’s the authenticity lost by generating from strategy instead of extracting from work. It’s the weekly scrambling because you have no material to pull from. It’s the generic feeling that follows you through every piece.

The Permission You Need Right Now

Here’s what I’ve learned about staying authentically you while building strategically: Grounded content doesn’t come from better planning. It comes from extracting angles from real work.

My husband didn’t paint the wall untouched because he had a better mental picture than I did. He painted it untouched because he tested the theory against reality and adjusted based on what he discovered.

Taking time to identify real work before extracting angles isn’t indecision. It’s strategy.

Launching content that comes from actual work rather than forcing it through a predetermined plan isn’t a weakness. It’s how strategic builders actually work.

The content works better because we adjusted based on real material. The system works better because we iterated based on work, not theory.

Not because we planned better the second time.

Because we let reality inform the decision.

One Final Thought

The shift from “generate content topics from strategy” to “extract angles from real work” isn’t a small change in process. It’s a fundamental change in where your ideas come from and why they land.

Your real work is abundant with content angles. You’re just not extracting them yet. You’re trying to generate from thin air instead.

Stop planning your content in the abstract. Start mining it from work you’re actually doing.

Your first piece doesn’t need to be perfect. It needs to be grounded in something real. Everything else follows from there.

Start there.

Here’s what actually happened.

The Part That Was Working

The StoryRefiner is my custom Claude project that takes rough story drafts and extracts key components for my content system

Story Refiner was solid. It took my rough stories and turned them into polished assets with all the components I needed: emotional arc, key details, lesson anchors, SHIFT stages, and headlines.

Beautiful output. Everything formatted. Ready to use.

Then I had to copy each piece into Notion manually.

Split screen. Copy from Claude. Paste into the Notion field. Back to Claude. Copy the next piece. Back to Notion. Repeat.

It worked. But every time I switched screens, I lost momentum.

So I asked Claude: “I’m looking to build a skill that sends my refined stories to my Notion database Master: Story_Components”

The Conversation That Changed Everything

Claude needed to see my database structure first. I sent the link. It fetched everything and saw all my fields: Story Snapshot, Headlines, Scene Snapshots, Emotional Beats, Lesson Anchors, Key Details, my SHIFT framework stages, and YouTube URL.

Claude noticed something: the StoryRefiner output included a Refined Core Story section, but my Notion database didn’t have a property for it. Two options—add a field or work around it.

I explained that the refined story should go in the page body due to its length. The components go in the properties.

Then Claude asked the question that set the automation into play: “For the Name property, what should it be?”

Options included using the first headline, theme keywords, manual entry, or auto-generating from content pillars.

Pause for thinking here...

I’d been thinking about automating this part of the step next. But this question made me realize something.

I manually create a short 3-5 word title for each story.

That title—that’s where I decide what this story is about, a memory jogger if you will. It helps me remember, and it was the most energy-intensive part of the process.

Until I realized that in the refiner, the AI names the thread (three to five words). Problem solved. I’ll just copy and paste that part.

That became the unlock. The “let’s kick this thing off” moment.

So now I just needed to figure out how to kick off the skill at this point.

And that is where the first “aha” automation moment came into play. How would it (it being Claude) know which database to put the story into?

Because in my mind, I’m working from one database at a time, but Claude thinks differently, at least from a Skills perspective.

After some back-and-forth, we landed on adding Notion integration instructions (Option 3) at the end of the StoryRefiner system prompt.

Option 1: Skill (Cross-Project)

Works anywhere in Claude (any project, any chat)
You copy StoryRefiner output, paste in any conversation, say “send to Notion”
Flexible but requires copy/paste between projects

Option 2: Direct Integration in StoryRefiner Project

Add instructions directly to StoryRefiner’s system prompt
After refining, you just say “send to Notion” in same conversation
No copy/paste needed
Lives only in that project

Option 3: Notion Connector in StoryRefiner Project

Use Claude’s built-in Notion integration
StoryRefiner can directly create pages without skills
Simplest approach if you ONLY do this in one project

When It Broke (Repeatedly)

I added the instructions to the StoryRefiner project and started testing.

“Tool execution failed.”

We adjusted. It worked.

By the next morning, it broke again.

Over three days, we cycled through fixes:

• disconnected and reconnected the Notion integration (worked temporarily),

• removed the MCP connection Claude said I didn’t need (same results)1

• tweaked the project instructions (temporary success)

• switched from browser to desktop app for stability (helped, but issues continued)2.

Each fix worked. Then broke.

And each time it broke, Claude wanted me to use manual entry.

Me: “I DO NOT WANT MANUAL ENTRY. We had this working before, so it’s doable unless you can’t continue to handle the workload or automation.”

We were chasing the wrong problem—focusing on MCP connections. I fed Claude screenshots from both API setups.

Then I tried the desktop app again and got a specific error:

Response [{”type”: “text”, “text”: “Tool execution failed”, “uuid”: “8a7011eb-672b-49bd-bb94-21f6c811ab46”}]

Claude saw it immediately:

“I see the problem now! Look at the JSON - all the property names and values are wrapped in backticks (`) instead of double quotes (”).”

Invalid JSON. That’s why it kept failing.

The automation was breaking because of an invisible formatting error in the instructions—like using tablespoons instead of teaspoons in a recipe, where everything looks fine until nothing works.

We fixed the instructions. Reran the tests.

Everything worked.

What This Actually Taught Me

The questions that moved things forward weren’t about building better automation. They were about clarifying what I was protecting.

“For the title, what should it be?” Revealed the title is strategic—it frames the story. That’s mine to decide.

“Should we add a Secondary SHIFT field?” Revealed I was trying to capture too much. The primary stage is enough.

“Look at the JSON - see the backticks?” Revealed a formatting issue I couldn’t see just by looking at the output.

“Try the desktop app instead of the browser.” Revealed the problem wasn’t the logic—it was platform stability.

The Stuff That Happened Along the Way

The backtick bug: One wrong character took the whole process down. I asked for fully rewritten instructions after each change, but I didn’t ask for proper formatting.

The auth instability: Using the browser app isn’t the same as using the desktop app.

The oversimplified instructions: When I fixed the backtick issue, I removed the property mappings. I should have asked for the fully corrected and formatted fix.

None of these were complicated. They were just stuff that happens when you’re building something real.

What to Check When Your Automation Breaks

Is your trigger clear? The 3-5 word title became my trigger. One manual input triggers the automation.

Are you automating strategy or logistics? The title frames the story—that’s strategic. Extracting components—that’s logistics.

Is the formatting actually valid? Backticks vs. quotes. One character. Check your JSON or ask if the instructions are properly formatted.

Is your connection stable? Sometimes it is the connection, so test different scenarios—browser versus desktop.

Did fixing one thing break another? Simplifying the fix of the backtick bug removed the property mappings. Keep a log of the changes you are making.

The Actual Lesson

The clean demo shows what works. The messy conversation teaches you what to protect.

I protected the strategic decision—the title that frames the story.

I automated the logistics—extracting and recording components.

The automation that works isn’t the one that does everything. It’s the one that handles the tedious stuff so you can focus on the decisions that actually matter.

That’s what the video doesn’t show. And that’s what actually matters.

I read the tip in an organizing blog: turn all your hangers backward, then flip them forward as you wear each piece. After a few months, you’ll see exactly what you actually wear versus what’s just taking up space. Simple, clean, done.

So I did it. Hung up all my clothes, flipped the hangers backward. And honestly? It worked for the first part of the purge.

But what they don’t consider: half my closet isn’t hung up at all.

I have jeans folded in a drawer. Sweaters stacked on a shelf. Tees in a separate section. Then there are the pieces that aren’t regular wear—the wedding outfit, the funeral dress, the timeless blazer I wear twice a year but absolutely need. The shoes, belts, accessories that live in their own ecosystem.

The hanger method solved for some of my clothes, but it completely ignored the complexity that actually mattered. I could turn hangers backward all day and still have half my wardrobe making its own decisions in drawers and shelves I wasn’t tracking.

Simple systems look good on paper. But they break the second you acknowledge what’s actually real.

That’s when I realized: the method wasn’t wrong. It was just in the wrong place.

And that’s exactly what happened with my Story Bank.

The Workflow Problem I Didn’t See

I wanted to systematize story extraction. So I built the Story Refiner to pull notes and the start of a personal experience and create ONE comprehensive entry: emotional arc, key details, lesson anchor, best SHIFT stage, story snapshot.

Then I built a complicated Notion database to hold it all. Multiple fields. Nested properties. Filters. Related databases.

It was comprehensive. Strategic. On paper, it seemed perfect.

But here’s what I actually needed to do to create content:

1. Brainstorm content ideas

2. Choose a topic

3. Find a story that matched that topic

4. Extract the components that served that specific piece

5. Write the article

6. Publish

7. Repurpose

I had Story Refiner extracting and storing stories before I knew what topic I was writing about. The database was full of pre-refined stories with pre-determined uses. But I wasn’t using them during content creation—I was creating content first, then trying to force stories into topics they didn’t naturally fit.

The method wasn’t broken. It was just in the wrong place in my workflow.

You Can’t Extract Before You Know What You’re Extracting For

Most people think when a system isn’t working, they didn’t execute it well enough. Need to refine it. Tweak it. Make it work better.

But here’s what I discovered: sometimes the problem isn’t the method. It’s when you’re trying to use it.

If you try to solve a decision before you have the information you need, here’s what happens: you build something comprehensive that attempts to anticipate every possibility. You end up with options that feel like they could work but don’t actually serve your current need. You skip the system during real work because you already know what you need. You eventually abandon it because it’s trying to solve a problem you don’t actually have yet.

That’s not poor execution. That’s a method placed too early in your workflow.

Here’s what I was missing: I thought Story Refiner should extract five possible uses for every story. But I didn’t have a topic yet. I was trying to extract for theoretical uses instead of extracting for actual needs.

The database was trying to solve “what could this story be used for?” before I’d answered “what do I actually need to write about today?”

Different questions. Different information available. Wrong point in the process.

How I Realized the Workflow Was the Problem

The moment I really understood something was wrong was when I sat down to create content.

I’d choose a topic. Open the Notion database. Look for stories that matched. Find pre-refined stories with their five suggested uses. None of them felt right because they were refined for theoretical possibilities, not this specific piece I was writing.

So I’d skip the database and just write from memory.

The system I’d built wasn’t getting used during the actual work. That’s data. The method wasn’t in the right place.

So I asked a different question: when do I actually have enough information to decide which story components matter?

Answer: after I’ve chosen the topic.

Not before. After.

That’s when I understand what this piece needs. That’s when I can ask “what emotional arc serves this topic?” That’s when I can extract components that actually fit.

So I moved the entire process.

Instead of: Brainstorm → Extract stories → Choose topic → Write

I rebuilt it as: Brainstorm → Choose topic → Extract components for this topic → Write

Story Refiner didn’t move. The timing did.

Now the database wasn’t holding five pre-refined uses. It was holding the raw stories. When I chose a topic, I used Story Refiner in that moment to extract the components that served that specific piece.

Same tools. Same process. Different place in the workflow.

Everything changed.

The Smarter Approach: Map Your Workflow, Then Place Your Method

Here’s how to recognize when your method is placed too early—and how to move it to where it actually works.

Step 1: Map Your Entire Actual Workflow (10 minutes)

Don’t think about what should happen. Map what actually happens.

Ask: from idea to completion, what are my actual steps?

For content creation, mine is:

1. Brainstorm content ideas (what topics matter?)

2. Choose a topic (what am I writing this week?)

3. Match story + lesson to that topic (which story serves this specific piece?)

4. Write the article

5. Publish

6. Repurpose

Write yours down. Step by step. What you actually do.

Step 2: Identify Where Your Method Is Placed Right Now (5 minutes)

Look at your workflow and ask: at which step am I currently trying to use my method?

For me: I was trying to use Story Refiner at Step 1 (brainstorm). I was extracting and storing before I knew what I’d need.

Where is yours placed?

Step 3: Ask: Do I Have Enough Information Here? (5 minutes)

This is critical. At the step where your method is placed, do you have enough information to make the decision your method is supposed to help with?

For me: at the brainstorm step, I don’t know what topic I’m writing about. So I can’t extract components that serve a specific topic. I don’t have enough information.

At Step 3 (after choosing topic), I do. That’s when I can say “this topic needs this emotional arc” or “this needs this key detail.”

Where do you have enough information to use your method? That’s where it belongs.

Step 4: Move Your Method to the Right Point (10 minutes)

Take your method and place it at the step where you actually have the information you need.

For me: move Story Refiner from Step 1 (before topic choice) to Step 3 (after topic choice).

New workflow:

1. Brainstorm content ideas

2. Choose a topic

3. → Use Story Refiner to extract components that match THIS topic

4. Write the article

5. Publish

6. Repurpose

Same method. Different place. Now it serves an actual decision.

Step 5: Test During Real Work (1 week)

Use the method at its new place in your workflow during actual content creation.

Do you use it? Does it give you what you need? Does it make the work smoother?

For me: yes, yes, and yes. When I choose a topic and immediately extract components for that topic, the method becomes essential instead of optional.

Why this works: you’re not forcing a method into a step before you have the information you need. You’re placing it where it actually serves a decision you’re making. Which means you use it.

Here’s the Prompt You Can Use for Your Own Workflow

Use this with Claude or your AI tool to find where your method should actually be placed:

I’m trying to streamline my [specific process: content creation, client onboarding, project management, etc.].

Here’s my current workflow from start to finish:
[Describe each step of what you actually do]

I built a system/method to [describe what you’re trying to do].

But I’m trying to use it at this point in my workflow: [describe when]

And I’m not actually using it because [describe the friction].

Help me:
1. Map out where this system/method is currently placed in my workflow
2. Identify what information I have at that point vs. what information I actually need to make this decision
3. Find the actual point in my workflow where I’d have enough information to use this method effectively
4. Redesign the workflow to place the method at that point instead

Show me step-by-step what my workflow should look like with the method in the right place.

What Other Creators Miss About Method Placement

When creators get stuck with systems that don’t work, they usually think it’s an execution problem. But sometimes the problem is simpler: the method is trying to solve something before you have enough information.

One creator built a client intake form that asked 20 detailed questions about their needs, budget, timeline, and past experiences.

Comprehensive. But she was using it before the initial conversation.

The prospect didn’t know enough about what she offered to answer accurately. She moved it to after the first call, when they both understood what they were looking for.

Same form. Different place. Suddenly it worked.

Another built a decision framework with five criteria for evaluating opportunities. Good framework. But she was evaluating opportunities before she understood what her business actually needed. She moved the framework to after she’d clarified her strategy. Same framework. Suddenly it made sense.

Here’s what they had in common: they placed their methods too early in their workflow, before they had enough information. The methods weren’t wrong. The timing was.

The shift happens when you ask: at what point do I actually have enough information to use this method? And then move it there.

For me, it was realizing Story Refiner needed to be used after topic choice, not before. Once I moved it, everything worked.

Where in your workflow is your method placed too early?

The Real Cost of Methods Placed Too Early

If you keep trying to use a method before you have enough information, here’s what happens:

You build the method carefully. You prepare comprehensive inputs. You try to use it during real work and realize you don’t have what you need yet. You skip it and solve the problem manually. You feel like the method failed. You eventually abandon it because it’s creating friction instead of removing it.

That’s not failure. That’s misplacement.

But here’s what changes when you move your method to where you have enough information:

You build the method for actual use. You place it at the decision point where you need it. You use it immediately during real work because it serves what you’re actually deciding. You get the efficiency you hoped for because the method is doing what it’s supposed to do at the right time.

That’s when methods actually work.

From Early to Right-Timed

I didn’t move Story Refiner GPT. Story Refiner stays exactly where it is—as the first step, extracting everything from every story.

Here’s what actually changed: I started recording the components in Story Bank itself.

Before, Story Refiner extracted emotional arc, key details, lesson anchor, best SHIFT stage, story snapshot. But those components lived nowhere accessible. They weren’t in the database. They were just in my head or scattered in notes.

So when I got to Step 3 (choosing a topic and matching a story), I couldn’t actually search the components. I couldn’t filter by “stories with vulnerability arcs” or “stories that teach Filter-stage lessons.” The components existed but weren’t recorded in a way I could use them.

Now, every component Story Refiner extracts gets recorded directly in Story Bank. Emotional arc as a field. Key details as a field. Lesson anchor. Best SHIFT stage. All searchable. All filterable.

That’s the only change. Story Refiner still runs first. Still refines. But now those components live in the database where I can actually automate the matching.

Now automation can help me find which story serves which topic because the components are recorded and searchable in Story Bank.

Same Story Refiner. Same extraction power. But the components being recorded in the database is what makes the whole system work—because it enables automation to match stories with topics during the actual content planning step.

The backward hanger trick works if you record which hangers got flipped. Without that record, you can’t see the pattern. Story Refiner works. But without the components recorded in Story Bank, you can’t automate the matching. Recording them in the database is what made everything automatable.

Watch me walk you through my journey of building the Story Refiner, a powerful and highly-refined content story workflow that hit a snag when automating the process.

Here’s What You Should Actually Be Doing

Look at one system or method you built that isn’t getting used during real work.

Ask yourself: at what point in my workflow am I trying to use this? Do I have enough information here to make this decision?

Be honest. Most unused systems are placed too early, before you have what you need.

If yours is, don’t rebuild it. Just move it to where you actually have the information.

The backward hanger trick didn’t fail because the method was wrong. It failed because you can’t track what you wear while you’re getting dressed. The complicated Story Bank didn’t fail because the method was wrong. It failed because you can’t extract for a specific topic before you’ve chosen one.

What method are you placing too early in your workflow? Reply and tell me what you’re maintaining at the wrong point in your process.