Over the last four months, I have been running Q&A sessions with paid members of AI Maker.

Here are some type of questions that I’ve received so far:

1. How do I create a master prompt that understands my writing?

2. Can I turn client call transcripts into LinkedIn ideas?

3. Where should my research live?

4. Should I use Claude Code, Cowork, Codex, or another agent?

5. How do I build reports and decks that are reliable enough to use with clients?

But the more I think about it, the more I realize these questions are just two versions of the same problem.

First, some people create a new AI project for every kind of work.

One Claude Project for writing, another for research, another for a client, another for a new business idea. Then a few custom GPTs, saved prompts, half-finished skills, and too many MCP tools connected because they looked cool but aren’t actually useful.

This can help for a while. But every project will evolve and develop its own instructions, files, prompts, and corrections. Soon, the person has to remember which project contains the latest rule, where the best reference file lives, and which version of the process produced the result that meets their standards.

Second, other people have not defined a strong process yet.

They know how to do the job through experience, but the steps, required input, and quality bar still live mostly in their head. When they ask an agent to help, they give it the task without explaining how to do it properly.

In one case, the process is scattered across too many places. In the other, the process has never been written down clearly enough for an agent to follow.

Both lead to the same problem: bad outputs that you can’t really trust.

That is why I keep returning to one question:

“How do I turn the way I work into a process an agent can repeat and I can trust?”

At a high level, that process needs six parts:

1. One repeated job with a clear starting point

2. The real input the agent needs

3. A process the agent can follow

4. A reviewable output

5. A written standard the output must pass

Whatever that goes into the job can be completely different.

What do I mean by that is a creator may start with a rough idea and end with a newsletter draft. A consultant may start with a client call and end with a proposal. A manager may start with weekly updates and end with a team brief. A researcher may start with a question and end with a report.

The input, process, output, and standard will change, but the basic shape stays the same.

Whether you use Claude Code, Cowork, Codex, or another agent, you still need to make those decisions before the agent can repeat the work reliably.

How do you make an AI agent workflow more reliable?

Reliable output requires more than a good prompt or a capable model.

Every run will be different. The research changes. Client information changes. The process gets adjusted. The output changes depending on the situation. Even your quality bar should get sharper as you learn more about your work.

Reliability comes from making those moving parts clear enough to inspect. Before each run, the agent should know:

• What information it needs before starting

• Which process and decision rules currently apply

• What it is responsible for producing

• Which standards the result needs to pass

• Where your corrections should be saved for the next run

REQUIRED INPUT
        |
        v
CURRENT PROCESS AND DECISION RULES
        |
        v
REVIEWABLE OUTPUT
        |
        v
CURRENT QUALITY CHECK

Once those pieces are clear, you can compare one run with the next. If the result changes, you can see whether the source material changed, the process was updated, the output requirement shifted, or the quality standard became clearer.

Your work keeps evolving, but the changes become deliberate and traceable. That is what makes the system more reliable over time.

Subscribe now

Start with one repeated task for your AI agent

To turn one repeated job into a process an agent can follow, I would begin with four questions:

1. Work

What repeated job do you want the agent to handle?

Keep this simple and don’t overthink. “Help me run my business” is difficult to define. But, a job that starts with a recognizable input and ends with a reviewable deliverable is small enough to build.

For example, creating a newsletter post from a brain dump of ideas, building a high‑quality report deck from research data, or turning a client transcription into a proposal deck.

2. Input

What does the agent need before it can begin?

This might include research, notes, transcripts, client documents, datasets, meeting updates, or brief.

3. Output

What should exist when the work is finished?

A newsletter draft. A client session plan. A weekly team brief. A research report. The output needs a clear format and a place where the agent should save it.

4. Key standard

What must be true before you would accept the result?

For writing, the standard might be preserving your argument, voice and verifying current claims. For consulting, every recommendation may need to trace back to the client’s information. For research, facts, inferences, and recommendations may need to remain clearly separated.

Write those four answers down in one place:

WORK
The repeated job I want the agent to perform.

INPUT
The files or information that begin the job.

OUTPUT
The deliverable that should exist when the job is complete.

KEY STANDARD
The most important requirement the output must pass.

And let’s look at this from a broader perspective based on the job type:

Notice that the details change across each kind of work, while the shape stays the same. Every job begins with specific input, produces a defined output, and has one standard the agent can use to judge the result.

What should an AI agent folder include?

Once the job is clear, you can give each part a place in a local computer folder that your agent can find and use again.

Here is the basic folder:

your-agent-job/
├── CLAUDE.md   --> the project direction for Claude
├── AGENTS.md   --> the project direction for ChatGPT/Codex
├── input/      --> real sources material
├── output/     --> the finished deliverable
├── standards/  --> quality requirement to generate outputs
└── .claude/
    └── skills/ --> specific task level instruction for Claude
└── .agents/
    └── skills/ --> specific task level instruction for Claude

Allow me to explain for each of them:

The main folders

The main folders, input/, output/, and standards/, give your work a place to live.

• The input/ folder contains the real source material the agent needs before it starts.

• The output/ folder gives the finished deliverable a clear place to go.

• The standards/ folder contains the quality requirements the agent should use to review that output.

The instruction file

Without the instruction file, the main folders are still just a collection of folders and files. The agent needs something that explains how those pieces fit together and what it should do when a request comes in.

That is the job of CLAUDE.md or AGENTS.md.

The instruction file tells the agent what this project is for, where the inputs and standards live, where it should save the outputs, and which Skill to use when a certain request comes in. This is what ties the folders together so the agent does not have to guess what to read or what to do next.

Skills for specific tasks

Skills sit one level below that.

Skill is important because sometimes a simple prompt isn’t enough to generate reliable output. Some tasks require a more specific process the agent needs to follow. It can be time-consuming if you have to write everything by hand every time you want the agent to do repeatable tasks.

That’s why we need Skill. A Skill is like a saved instruction that the agent needs in order to generate reliable results repeatedly by following a specific process.

For example, you might ask the agent to turn one newsletter into a LinkedIn post, a Substack Note, and an X thread. The instruction file tells the agent where to find the source newsletter and the standards for each channel. A content repurposing Skill gives it the exact steps for turning that source into three different outputs.

If you are a researcher, the instruction file might tell the agent where the research questions, source rules, and report templates live. A research Skill can then tell it how to search the internet for a topic, review the sources, separate evidence from inference, and generate the final report in the format you already defined (html, ppt, docs, etc).

Use this Skill when you want a task executed properly with a minimal margin of error.

External access through MCP or CLI

If the job needs information outside the local folder, MCP or command-line tool can give the agent access to it.

For example, MCP might let the agent read a document from Google Drive. Or you could ask the agent to read all of your Gmail inbox, X bookmarks, create tables in Notion, and build you a banner for your marketing campaign.

Without MCP or CLI connections, the agent can’t reach out to the outside world to interact with the apps you use on a daily basis. This keeps all your work trapped on your local computer and still requires you to copy and paste everything manually.

I know you don’t want that.

With MCP or CLI, the agent can do all of this for you and execute on your behalf.

Build the first working version

In the rest of this post, you will start with a blank job system and fill it with your own Work, Input, Output, and Key Standard.

At each step, I will show how this works across multiple job types—creators, consultants and coaches, managers, researchers, and business owners—including templates that use those five folder shapes.

By the end, your folder will be able to take one real input, follow a defined process, create a reviewable output, and check it against a written standard.

The goal is a small system you can run again every day.

In the end, you’ll end up in the place where you spend less time babysitting the agent so you can deploy 5-10 agents to do more work and eventually become more productive than you ever be.

Choose the folder shape that matches how your work repeats

You may already have Claude Projects, saved prompts, and partial systems scattered across different places. I’ll assume that you have now defined one job, the input it begins with, the output it should create, and the standard it needs to pass.

What we need to do now is giving those pieces a folder structure the agent can follow.

Choose the example closest to how you work, then rename or remove anything you don’t need.

I am showing the Claude Code version below to keep the trees readable. If you use ChatGPT/Codex, replace CLAUDE.md with AGENTS.md and .claude/skills/ with .agents/skills/.

For creators

Read more

My post about taking Andrej Karpathy’s LLM Wiki idea and turning it into an AI Second Brain inside Obsidian has become one of the most popular posts I have published for paid subscribers.

A lot of you found that framework useful. You downloaded the starter kit, copied the structure, changed the categories, and started building LLM wikis around the things you care about. I loved seeing that because the original setup solved a problem I had struggled with for years. It gave all those articles, notes, and ideas somewhere to go, then let Claude build the connections I rarely had the patience to maintain myself.

I have been using my own version for a while now. The more I use it, the more I notice where the first version starts to break down. Here are three problems that kept appearing:

Problem 1: My Inputs Were Scattered Before They Reached the Wiki

The first limitation appears before anything reaches my wiki pages.

Every time I find something interesting on the internet, it never arrives through one neat input; it’s all scattered:

1. I find things on X and save them to my bookmarks.

2. I have articles and videos sitting in Readwise.

3. I watch long podcast conversations that contain five ideas I want to remember, plus a guest I will probably come across again.

4. Then I have my own scattered thoughts. Some are developed enough to save. Others need a conversation before I even understand what I am trying to say.

The original system could ingest a URL and generate connected wiki pages. But, it needed better ways to handle all these other inputs without forcing me to process each one manually.

So I started adding new paths into the Second Brain.

1. Podcasts now have their own flow. I can save a transcript through Obsidian, run one command, and let Claude identify the show, host, guest, and durable ideas before adding them to the wiki.

2. X bookmarks and Readwise saves go through a filter first. The system reads what I saved, compares it with what the wiki already knows, and helps me decide whether I should read it, think about it, ingest it, or let it go. If you’ve been using X and Readwise to save insightful content, you’re going to like this new workflow.

3. On the other hand, my own thoughts have a different path. I can use a Reflect command that asks me questions one at a time. It waits until I have worked through the thought before turning it into a page. The reason I do this because a personal reflection should sound like something I actually believe, not a polished lesson Claude invented from one unfinished sentence.

Then I ran into a second limitation as the wiki grew.

Problem 2: The Wiki Became Harder to Search as It Grew

I had given Claude a folder full of pages, but whenever I asked it questions about my second brain, it still depended on whether it could retrieve the right context at the right moment.

In the first version, Claude started with index.md, guessed which page titles looked relevant, and used tools like Grep to search for matching words. Grep is a command-line tool used to search for specific text patterns within files. It can tell the agent which files contain a given string, but it does not tell the agent which five passages matter most to the question.

That difference becomes expensive once the wiki reaches 100 pages or more. Claude can open a large pile of files and spend more tokens reading them, or it can make an argument from the smaller set it happened to find. A page can also use completely different words from my question, leaving Grep with nothing useful to match.

Artem Zhutov's QMD breakdown helped me put this problem into clearer words. In his demonstration, Claude's normal file search took around three minutes and returned 300 files. QMD returned a much smaller, more relevant set almost immediately.

I learned about QMD through Tobi Lütke, the CEO of Shopify. He built QMD, a local search engine for notes, documents, transcripts, and knowledge bases, using Qwen3 with LoRA.

QMD ranks exact keyword matches, finds ideas expressed in different words, and reranks the candidates before Claude opens the files. The search models run locally on my computer. Claude can search the wiki, the original sources, and full podcast transcripts, see a short list of promising passages, then read only what it needs.

This is how the architecture looks:

This gives Claude a more practical form of memory. It spends fewer tokens opening weak matches and has a better chance of finding the page I forgot existed. The underlying notes and local index can also keep working if I use another agent later.

But the goal I want in this battle of Grep vs QMD is to give the agent a much better starting point than simply guessing from an ever‑growing index.

Problem 3: What Was I Going to Make From All of This?

Once I had captured all this material, filtered it, connected it, and made it searchable, what was I going to do with it?

I didn’t want the Second Brain to become another place where all my lessons and insights from the information I’ve consumed waste away. I wanted it to bring old ideas back, help me work through tensions in my own thinking, and eventually give me something I could use.

That led to the final pieces of the upgrade:

• A Weekly Review command resurfaces older connections I did not remember to search for.

• A Draft command searches what the wiki already knows, gathers the evidence and counterarguments, shows me what is missing, and helps me turn the material into a writing brief. It only writes the draft after I approve the direction.

The full system now follows this path:

In this post, I am going to show you how each stage works, how to set up QMD and Readwise, how the podcast, X bookmark, reflection, and drafting commands fit together, and how to add the whole upgrade to the LLM Wiki you already built.

By the end of this post, you’ll have a complete second-brain folder that you can either use as-is or modify for your topic of interest. It contains all the custom commands I use and cover in this post.

Whether you run this on Claude Code, Cowork, or ChatGPT Work, it will work.

I’m convinced this might be the most comprehensive post on building your AI second brain at an advanced level, and I’m sharing it all right here in this post.

So buckle up—this is going to be a long one! 🔥

Saved Material Starts Where My Attention Already Goes

As I mentioned earlier, my old AI second brain workflow was limited to capturing only URLs from information I found on the internet, usually online articles, because Claude could fetch them easily.

But the way I consume information is scattered.

I hear something during a podcast. I bookmark a post while scrolling through X. I send a long article to Readwise because I want to read it later. Then a thought comes to me while I am walking, having dinner, or talking with someone.

Each one contains a different kind of material. They also need different treatment before they belong in the Second Brain.

These are the four entry points I use now.

1. Podcasts Through Obsidian Web Clipper

Podcasts have become one of my biggest sources of ideas. A good two-hour conversation can introduce me to a new person, challenge something I already believe, and give me several threads I want to explore later.

Saving the episode link is rarely enough. By the time I return to it, I have forgotten which part actually important. A title like “14 Patterns Behind the World’s Greatest Minds” tells me almost nothing about the specific idea I wanted to keep or where it appeared in the conversation.

Obsidian Web Clipper gives me a better starting point. When a podcast has a transcript available, I can save the full transcript into the Clippings/ folder in my Second Brain. That folder now works as a visible queue. Anything sitting at the root is waiting to be processed. Once an episode has been handled successfully, it moves into Clippings/ingested/.

I can open the folder and immediately see whether I have a podcast waiting. I do not need another tracker to remember what I have processed.

The transcript also preserves the original conversation. Later, when Claude creates a condensed source note or a wiki page, I can still trace an idea back to the timestamp where the guest said it.

But you don’t need to use Obsidian Web Clipper if you don’t want to, you can also use Readwise Reader, which supports videos, to access the podcast, as we’ll get into soon.

2. The Things I Bookmark on X

X is where I come across many of the new tools, arguments, experiments, and workflows I want to look at again.

Bookmarking takes less than a second. I save it and keep moving.

The problem usually appears later. My bookmarks contain everything together: long X Articles, thoughtful threads, product launches, short opinions, AI tutorials, and posts full of hype that promise nothing tangible.

All these become wasted if I don’t have a way to process them together.

This is where the new upgrade comes in. It gives those bookmarks a path into the Second Brain without requiring me to copy every link into Obsidian or Claude manually.

Claude can pull a recent batch, read the complete post or article, and compare its actual claim with the pages already in my wiki.

I will show you that command in the next section. The important part here is that X remains where I discover and save things. The Second Brain handles what happens after the save.

3. Articles, Videos, and Newsletters in Readwise

Readwise is a slightly different input because it already contains more information about how I consume information on the internet.

It knows what I saved, whether I opened it, how far I read, and which passages I highlighted. In fact, Readwise tracks my reading progress and provides clues about what I found useful. And the best thing about Readwise is that it handles multiple content formats—whether it’s articles, videos, podcasts, tweets, PDFs, emails, etc.

I might have a long article sitting unopened in my Reader inbox. That does not mean Claude should immediately summarize and ingest it for me. Sometimes the best next step is for me to read it first. If I have already read most of it and highlighted three sections, the system can pay attention to those passages when deciding how the document relates to the wiki.

The new Readwise connection lets Claude read the inbox and the full documents without moving or deleting anything. Readwise stays as my reading and saving tool. The Second Brain helps me decide which documents deserve more attention and what they might add to the ideas I already have.

Later in this post, I’m going to show you how you can connect your agent to the Readwise CLI.

4. My Own Scattered Thoughts

The final input does not come from the internet at all.

Sometimes I have a developed thought I can write down clearly. Sometimes I only have one sentence or short aphorism, like “hard work is overrated” or “AI is a reflection of its human.”

I know something is there, but I have not worked out the argument yet.

I can drop the thought into inbox/ folder without choosing a category, adding tags, or formatting it. The folder is designed for quick capture. Claude can help classify and process those notes later.

For thoughts that feel more personal or unfinished, I can start /reflect instead. Claude asks me one question at a time and follows what I actually say. Nothing becomes a wiki page until I tell it that the insight is ready to save.

To do this, you’ll need to use Obsidian Sync for $5/month so you can start capturing your fleeting thoughts on mobile and have them sync instantly to your local computer. Then, once you’re in front of your computer and ready to think deeper, you can start the ingesting process.

You can watch my recent One Shot Show session, where I demonstrated how ‎⁠/reflect⁠ works.

That gives my own thinking a proper place beside articles and podcasts. The wiki can contain what other people taught me, alongside the beliefs, questions, and experiences I am still working through myself.

The four paths now look like this:

Podcast transcript -> Clippings/
X post             -> Bookmarks
Article or video   -> Readwise Reader
Personal thought   -> inbox/ or /reflect

I built all these paths systematically before ingesting them into wiki pages. But all these processes come from the natural way I consume information, so it doesn’t really add more work for me. I can just live my life normally, and every once in a while during the week, I only need to process the new information in my Obsidian into something worth saving—something that gives me more insight into any information I consume.

A saved item is a signal that something caught my attention. The next stage helps me decide what kind of attention it deserves.

Subscribe now

Filter What Each Save Deserves

In the first version of my Second Brain, I made the important decision before I ran the command.

I chose an article because I had already read enough to know it belonged in the wiki. Then I copied the URL and asked Claude to ingest it.

X bookmarks and Readwise changed that.

Saving something in either tool is fast. Sometimes I save because the idea is genuinely important. Sometimes the title catches my attention and I want to investigate it later. Sometimes I am simply curious for five seconds.

Those are all valid reasons to save something. They are not equally good reasons to turn it into permanent knowledge.

I needed a decision layer between saving and ingesting.

The filter asks one question about every item:

“Does this contradict, complicate, or add meaningful evidence to something already in my Second Brain?”

That question creates four possible outcomes:

1. Drop: The item adds nothing useful. It might repeat an idea I already captured, announce a tool with no deeper argument, or point to something too thin to preserve.

2. Read: The material looks substantial, but I have not read it yet. The honest next step is for me to read it before Claude turns someone else’s argument into part of my knowledge base.

3. Think: The item touches something I am already working through. It might challenge one of my pages or open a personal question that deserves reflection.

4. Ingest: The source contains a developed argument with enough substance to add to the wiki.

The filter process only recommends the next step; it doesn’t automatically create a reflection page or generate a new wiki page. I still decide what I want to do with it.

That boundary is important to me because I want the Second Brain to help me make better choices without quietly making those choices for me.

To put it simply, I want to make sure that I’m still sitting in the driver’s seat, not my AI. I want to make the whole decision so it sharpens my thinking instead of dulling it over time.

Filter My X Bookmarks With /triage-bookmarks

Let’s dive into how my X bookmarks and ingest process, which is called /triage-bookmarks actually work.

Once X is connected, I can run:

/triage-bookmarks 20

The number is optional. It tells Claude how many recent bookmarks to review. I used 20 for my first live test. You can also say something like “last week” or “the last 7 days.”

The command starts by checking a small ledger of bookmarks it has already judged. Every X post has its own ID, so Claude can skip anything from an earlier run instead of spending time debating the same bookmark again.

It then pulls the new bookmarks and reads the actual content.

For every bookmark it can read, Claude turns the post into a plain-language claim and searches my Second Brain with QMD. It looks for the pages most likely to relate to that claim, then checks the relationship.

Does the post repeat something I already know? Does it sharpen an existing page with a more useful mechanism? Does it pull against one of my beliefs? Does it introduce a substantial new argument? Or did I bookmark a product announcement that will probably mean nothing to me in two weeks?

This is where the command became more useful than a normal bookmark summary.

A summary would organize all 20 posts and make the pile bigger. /triage-bookmarks is allowed to say that most of the pile does not deserve another step.

Here is what happened when I ran the triage bookmark on my latest 20 bookmarked posts on X:

20 bookmarks reviewed
17 dropped
2 marked Think
1 recommended for Ingest

Eighteen of the 20 bookmarks were about AI tooling. Model releases. New skills. Product demonstrations. Claude commands. ChatGPT Work. Grok 4.5. GPT-5.6. Motion graphics. Design tools.

My bookmarks showed a week of trying to keep up with what was changing. My wiki showed something different. Almost none of those tool updates had contributed to the ideas I was actually developing.

That gap became the real finding. The things that catch my attention while scrolling and the things that deepen my thinking overlap much less than I expected.

Only one of the 18 AI-related bookmarks survived, and it survived because it contained a real argument rather than another announcement.

The Two Posts That Made Me Think

The first Think result came from Amanda Orson. Her post asked a simple question: what will remain true over the next ten years?

That collided directly with my About Me page. A lot of my thinking is built around agency, taking an idea from your head and making it real. Amanda’s post added another question: where should that agency be directed?

Her advice to build around things that do not change also connects with my page about Light Mode and Heavy Mode. Heavy work is usually slow and deliberate, such as writing books or building companies. Light work is fast and iterative, such as tweets, short-form content, or hot takes. Here’s the Light vs Heavy Mode that my page referred to:

Working Theorys

Make Something Heavy.

We instinctively tie weight to value…

Read more

a year ago · 2583 likes · 259 comments · Anu

The second Think result was an old Tim Ferriss post about dreamlining.

This one found a genuine hole in my wiki.

I already had a page called “You Can’t A/B Test Your Life.” The central idea is that life cannot be run in parallel. Once you make a decision, the useful move is to commit instead of constantly comparing it with the paths you left behind.

Ferriss starts one step earlier. What happens when you cannot clearly articulate what you want in the first place?

His method is mechanical. Write down five things you want across a six or twelve-month timeline. Turn vague states like “being confident” into something you can do. Then take one small step now.

My wiki had a lot to say about commitment after making a decision. It said very little about how we form the desire before that decision.

That’s why the command suggests that I think about this if I want to add it as part of my wiki pages, so it can complement or add tension to my existing pages.

The One Ingest Candidate

The only Ingest recommendation was George Sivulka’s “You Just Hired a Million Bad Employees”.

The post framed large-scale agent deployment as a management problem. That put it in direct conversation with my existing page about the Orchestration Tax, where I argue that human attention becomes the serial bottleneck when too many agents need review.

The command did not treat the shared topic as enough. It recommended reading the full piece before committing it to the wiki. If the article contained a developed argument about defining work, evaluating agents, and managing the system, it could materially extend the existing page.

Ingest is a recommendation to inspect the source more closely. It is not automatic approval.

What Got Dropped

The 17 drops fell into a few clear groups.

1. Model and product announcements: ChatGPT Work, Grok 4.5, GPT-5.6, Claude /checkup, HeyGen motion graphics, and Open Design. Useful updates, but mostly changelogs.

2. Skill releases: Apple design, animation-improvement skills, and another skills tutorial. These might be useful to install or test. They gave me little to think about.

3. Lists for someone else’s situation: executive AI questions, build lists, and generic resources without a developed argument.

4. Pointers and reactions: quick demonstrations, reactions to product news, and posts pointing toward someone else’s work.

The filter also surfaced one decision that was harder to make.

I had saved a David Senra post about Breville’s “A Bit More” button. The design principle was genuinely useful: observe what people repeatedly do, then design around that behavior instead of relying only on what they say.

David already had a page in my wiki, but the idea collided with nothing else. I had no active product-design or customer-research thread for it to sharpen. Creating a link through the author would have made the wiki look more connected without adding more value to the topic I care about.

The command dropped it and flagged it as the arguable call. I could loosen the rule later and allow a strong new idea to start its own thread. For this run, I kept the bar where it was.

After reporting the results, the command records every verdict in inbox/x-bookmarks-processed.md:

Date | Post ID | Author | Verdict | Why

That file is working state. QMD does not index it, and Claude does not treat the verdicts as knowledge. It exists so the next run knows what has already been reviewed and, over time, I can see which bookmarks actually became reflections or wiki pages.

Filter My Readwise Inbox With /triage-readwise

Readwise needs a slightly different filter because it knows more about what I did after saving something.

When I run:

/triage-readwise yesterday

Claude pulls unjudged documents from my Reader inbox. With CLI connection, it can see the document type, reading time, how far I progressed, and any highlights I created. The command then reads the full source before deciding what deserves another step.

The extra signal here is my reading behavior, because Claude can see how far I’ve progressed on specific content formats. Since Claude can read the entire piece, it can compare my progress against completion. In the end, it can suggest that I either read it to the end or drop it entirely if I already have a sharper page in my Wiki instead.

My first live run found only three saves, all from July 21, 2026:

3 documents reviewed
2 dropped
1 recommended for Read
0 completed

The one survivor was the only piece I had not opened.

Read: “Dreams of Stability” by Anu.

Working Theorys

Dreams of Stability

Everyone says they hate the question: What do you do? It’s cliché and reductive. But nobody stops asking, and nobody stops answering. Because the answer is never just about what you do. It’s about what people think you’re worth, and what you want people to think you’re worth…

Read more

6 months ago · 357 likes · 39 comments · Anu

The essay argues that stability has become a status symbol in tech. As AI makes skills easier to replace, the fallback options that once made risk feel survivable may be disappearing.

That challenges my existing page on Uncertainty Tolerance.

But I was still at 0 percent on the essay. The right next step was to read it, then use /reflect to decide whether it changes my view. Ingesting it first would have left me with a neat summary of an argument I had never formed an opinion about.

The two drops were quicker calls:

1. “How to think” by Craig Perry: I was 30 percent through it. Its argument about judgment and context was already covered more sharply in my Independent-Mindedness page through Paul Graham’s work.

2. Matt Pocock’s Agentic Engineering Workflow: I was 70 percent through the video. Its main claim, that AI handles more tactical programming while human skill sets the ceiling, already appeared across AI as a Mirror for Thinking, Use Agents or Be Left Behind, and Learn to Ship.

Two of the three saves were about AI and tech, and both were dropped. That does not mean the filter penalizes AI. It means my Reader inbox was drifting toward the same topic, while my wiki already held stronger versions of those ideas.

This tiny first run showed why the Read verdict matters.

The command records every verdict in inbox/readwise-processed.md so it does not review the same documents next time. It also leaves Reader untouched. Nothing is archived, moved, tagged, deleted, or marked as seen.

Now that you’ve seen how many filters I had to put on my saved materials before they deserve their own place as wiki pages in my second brain, you can see why I’m so selective. I don’t want to include anything I don’t fully understand, so these filters are a required part of the whole system.

Every saved material needs to go through a review, but only the useful ones continue. Some deserve a dedicated wiki page. Others deserve my attention first.

Now, let’s dive into how to install Readwise CLI and connect it to your agent.

How to Set Up Readwise

Readwise is the only new source in this workflow that needs its own connection. I use the official Readwise CLI mainly for two reasons:

1. It is more token-friendly. Claude can request a short list of documents first, then open the full text only when it needs to judge a specific item.

2. It connects directly to the Readwise API. Once I log in, Claude can retrieve my Reader documents, reading progress, and highlights through specific commands. That connection also remains useful when I want the agent to do something outside the main second-brain workflow in this post.

Install the Readwise CLI

Open your terminal and run:

Read more

If you are building an audience, a newsletter, a coaching business, or a company online, you need some way to see whether the work is going anywhere.

Google Analytics will not explain your whole business. But it can show you whether people are finding your site, where they came from, which pages are bringing in new people, and whether they stay long enough to care.

But, the problem starts after the tracking is set up.

Maybe you review Google Analytics every week, but still spend time clicking through traffic sources, landing pages, and search performance before turning it into a summary.

Or maybe you are more like me. The reports are there, but you keep putting them off because opening them feels like starting a small analysis project from scratch.

Every Monday, six CSV reports arrived in my inbox: traffic sources, landing pages, search queries, and engagement data from Google Analytics and Search Console.

I had already set up the reports I wanted. But some weeks, I skipped them completely because opening the files still felt like starting a small analysis project from scratch.

And when I did open them, I still had the same problem.

The numbers were there, but the insight was not obvious.

One recent week, my overall traffic fell 11%. That sounds bad until you look closer. Organic clicks grew 4%. Search impressions grew 8%. Average session duration went up 20%.

So what happened?

Fewer people came to the site, but search was still moving in the right direction and the people who arrived were staying longer. The real drop was coming from direct traffic, not search.

That is useful information. But I had to compare separate reports and figure out the story myself before I could see it.

So I built a weekly Claude Code routine that creates an Artifact report:

1. The routine is the repeatable Monday job. I packaged its instructions as a Claude skill, so I do not need to explain the reports, comparisons, or output format again every week.

2. The Artifact is the visual report the skill creates. It brings the separate CSV files into one place, with the charts, tables, and weekly summary I need to review.

Every Monday, Google sends the same six reports with the dimensions and metrics I already care about. Then I run a routine in Claude that reads the CSV files from my email and turns them into a visual Artifact report.

More importantly, it saves the raw data and finished report in a dated folder. After a few weeks, I do not just have a snapshot. I have a history I can compare.

In this post, I will show you the exact setup: the reports I schedule, the email routine, the Claude skill that generates the Artifact, and the folder structure that stores every week of data.

All of these can be applied across Claude Code Desktop, Cowork, and ChatGPT Work.

What you will have after you set this up

The goal is to design the reporting once, then stop rebuilding it every week.

When your scheduled reports arrive on Monday, Claude will trigger the skill automatically. It already knows which email attachments to find, what each CSV contains, how to compare this week with last week, how to create the Artifact, and where to save everything.

The skill is called /weekly-analytics-report.

By using the skill, you do not need to write a new prompt every week or recreate the same report by hand.

Here is the workflow:

Google Analytics + Search Console reports

    -> scheduled Monday emails

    -> Claude skill

    -> Artifact report + dated data folder

    -> weekly history you can compare

By the end of this post, you will have:

1. A fixed set of Google Analytics and Search Console reports built around the questions you want answered each week.

2. CSV files delivered to your email automatically every Monday.

3. A Claude skill you can run without writing a new weekly prompt.

4. A visual Artifact report that brings the separate reports into one clear weekly update.

5. A dated folder containing the raw CSV files and finished report from every week.

The outcome is simple: your weekly reporting becomes one repeatable step, and each new report adds another week of history you can use to see what is actually growing.

Subscribe now

🚨 Before you start

This workflow only works when the data is already being collected.

Before you follow the reporting setup in this post, make sure you have:

1. Google Analytics set up for your website or Substack.

2. Google Search Console set up and verified for the same site.

3. Your Search Console property linked to your Google Analytics property.

4. An AI setup that can access the Gmail inbox receiving the scheduled report

There are many resources and guides on YouTube that show you how to set up both Google Analytics and Search Console.

Once the connection is in place, you can use Google Analytics as the place where you build and schedule the reports for this workflow. That includes the normal traffic and engagement data from Google Analytics, plus the search-query and organic search data from Search Console.

You do not need to create one set of scheduled reports in Search Console and another in Google Analytics. For this setup, the reports all come from Google Analytics.

Your AI also needs a way to read the CSV attachments after they arrive. The exact setup depends on whether you use Claude Code, Claude Cowork, or ChatGPT Work. Use the Gmail connection available in your setup, then make sure it can search the inbox and read the report attachments.

In my case, Claude Code accesses my Gmail through Google Workspace CLI. If you want to follow the same path, read my Google Workspace CLI setup guide first. Once that connection is working, the weekly report skill can find the scheduled emails by itself.

Why I used scheduled reports instead of MCP

Someone might ask why I did not connect Google Analytics through MCP and ask Claude to pull the data directly.

I have not tested the Google Analytics MCP route yet, so I am not going to pretend I know which option is better.

But I do know the job I am trying to solve here. I am not opening Claude every Monday and asking a new question about my data. I need the same set of reports, with the same dimensions, metrics, filters, and date range, every single week.

Scheduled reports let me define the data once. Every Monday, the same files are already waiting in my email, and the skill already knows what to do with them.

MCP might be useful for a different job, especially when I want to explore something new in the data. But I am building a repeatable Monday routine that turns a fixed set of reports into a visual record of how my Substack is growing over time.

Now, let’s dive in.

Decide what you actually want to learn each week

Before setting up any report, decide what you need the weekly review to help you understand.

Google Analytics can track far more than most of us need to look at every Monday. If you schedule every available report, Claude will have more files to read, but you will still end up with a noisy report that does not help you decide what to do next.

So, instead of asking, “What can Google Analytics show me?” I started with a simpler question: “What would I want to know before I decide what to pay attention to this week?”

For my newsletter, that became five questions:

1. Did traffic change, and did the quality of that traffic change with it?

2. Which source or channel explains the change?

3. What are people searching for, and are any topics gaining or losing momentum?

4. Which pages are bringing in new readers, and are they spending time with those pages?

5. Is there anything worth checking, fixing, or building next?

Here is how those questions map to the reports I use:

These are the questions for my own newsletter. Your version might focus on leads, booked calls, product pages, course sign-ups, or sales instead of content pages and search queries.

The rule is the same: start with the decisions you want to make, then choose only the reports that give you the evidence for those decisions.

Set up the Google Analytics and Search Console reports

I use six reports. Together, they give me a weekly view of traffic volume, traffic quality, acquisition, search demand, and content performance.

You do not need to copy this exact set if your business works differently. A coach might care more about lead pages and booked calls. A SaaS company might care about product pages and trial sign-ups. But these six reports are a good starting point if your site grows through content, search, email, or an audience.

I also have a video walkthrough below that you can watch to set up and run this entire automation.

Read more

I have spent a ridiculous amount of time on X.

Part of it is probably just being chronically online, but the more honest reason is that X has become one of my main research sources for AI.

A lot of the ideas I write about here started there. The AI second brain post came from Andrej Karpathy’s LLM wiki method. The Loop post came from seeing people experiment with small agent workflows. My Codex deep dive also started from things I kept seeing on X before I tested them myself.

Honestly, maybe 80% of my post ideas begin with something I saw there.

That is the good part.

The bad part is that keeping up with X manually is mentally exhausting.

If you work anywhere near AI, there’s this constant feeling that you’re already behind. Someone is always testing a new tool, finding a new workflow, or sharing a weird trick that might be useless—or it might become the thing everyone is using next week.

So I kept opening X “just to check.”

Then thirty minutes disappeared.

Sometimes I found something useful. Sometimes I saved five posts and never came back to them. Sometimes I left with more tabs, more anxiety, and no clearer idea of what I should actually write or test next.

That was the part I wanted to fix.

I didn’t want to stop using X for research, because I learned so much about diverse topics by stumbling on random tweets from other people and experts in their fields. But at least for specific topics I wanted to learn about, I wanted to stop doing all the reading by hand inside the feed, while the feed decided what deserved my attention.

For a while, I kept looking for ways to connect an AI agent to X. There were GitHub workarounds and unofficial setups, but they required saving your browser cookies to access it. You couldn’t just open your computer and ask your agent to do it.

That changed when X added an official MCP route through its API tooling.

Now I can connect X to Claude Code and Codex, ask my agent to pull from accounts I care about, search around a topic, or collect my own bookmarks, then turn that into a research brief I can actually use—all with the new X research skill I recently built.

This post is the working version of that setup.

I am going to show you how I wired X into Claude Code, how the research skill works, and the three reading systems I am using so far: running research on topics, pulling posts from multiple accounts, and exploring ideas from my bookmarks.

X MCP or CLI? Pick Your Path First

To get there, there are two ways to connect X to Claude Code.

1. One path is the MCP.

2. The other path is the CLI, using a tool called `xurl`.

They can both reach the X API, so the difference is not really about whether one can do research and the other cannot.

The difference is how the agent gets there.

With the MCP, X becomes a set of tools Claude Code can call directly. That makes the experience feel more natural. You can ask in normal language, and Claude Code can decide which X tool to use.

That is why I like it.

But there is a tradeoff.

In my experience, MCP tools can use more context because there is a real tool layer involved. Claude Code needs to understand the available tools, choose between them, call them, and handle the returned data inside the session.

The CLI is more manual.

With `xurl`, you are basically accessing the X API directly from the terminal. You call the endpoint, get the response, and let the agent parse the result.

The annoying part is that the CLI does not feel as natural by default. You need to know which API endpoint to call, what parameters to use, and how to avoid pulling too much.

That is where the skill comes in.

If you wrap the CLI path in a skill, the agent can learn which API call to use when you ask for something in normal language. You can say “pull recent posts from these accounts” or “search X for this topic,” and the skill tells the agent which `xurl` call to run.

So I do not see MCP and CLI as completely different research systems. They are two ways to reach the same source.

Here is my rule:

1. Use MCP if you want the smoother Claude Code experience.

2. Use CLI plus a skill if you care more about direct API access and tighter control.

3. Start with MCP if you are unsure, then keep the CLI path available for cases where you want more control.

For this post, I am going to use MCP as the main path because I think that is where most of you should start.

But I am also going to give you the skill structure that makes the CLI path usable, because that is the part that turns API access into a repeatable research process.

If you want a more nuanced take on the differences between CLI and MCP, you might want to check out my latest monthly Q&A to learn more about them.

Subscribe now

What The X API Costs

Before we install anything, I want to talk about cost, because unfortunately, accessing the X API isn’t free.

X API access is not the same as opening the X app. When Claude Code reads posts, searches topics, or pulls bookmarks through the API, those requests can cost money depending on what you pull and how much you pull.

For my use case, this is still worth it because I am using X as a research source for work I already do every week. But I would not want anyone to set this up thinking it is automatically free.

X’s API pricing page says the API uses pay-per-usage credits. You buy credits in the Developer Console, and credits are deducted as you make API requests. You’re charged based on how many resources are returned.

For example, the current X pricing page lists:

1. Posts: Read at $0.005 per resource.

2. User: Read at $0.010 per resource.

3. Counts: Recent at $0.005 per request.

4. Trends at $0.010 per request.

5. Owned Reads at $0.001 per resource when the request is made by your own developer app for your own data.

That means the rough math is not scary if you start small:

1. A topic research run that pulls 50 posts is about $0.25.

2. A digest across 20 accounts pulling 10 posts each is about $1.00.

3. Pulling 300 of your own bookmarks through the Owned Reads lane is about $0.30.

Those numbers are small enough for how I use this, because I typically run my research every week and have a few trusted people whose tweets I check for new ideas. But if you start pulling full archives, huge account lists, or repeated batches without reviewing the output, the cost can climb. Be careful.

So the rule in my setup is simple:

Start small. Inspect the first batch. Only pull more if the first result is useful.

You can start by adding as little as $5 in credits. Then experiment slowly to understand the costs before adding more money to your account.

What We Are Building: An X Research System

Now that the path and cost are clear, here is the actual setup. We are building a read-only X research system inside Claude Code.

It has three jobs:

1. Search around a topic before I write.

2. Pull recent posts from people I already trust.

3. Clean up my bookmarks into something I can actually use.

The MCP gives Claude Code access to X. I’m going to show you how to install it, because it takes some work and it’s not an instant thing to do. You’ll need to create an app using an X Developer account, but I promise it’s not that hard if you just follow my instructions. You can get this done in about 15–20 minutes.

X Research Kit Skill

Then I’m going to share a new skill I built to start running research on X called X Research Kit. This skill will guide you through running research on X that does the three jobs I mentioned earlier.

Without the skill, I still have to keep explaining what to pull, what to ignore, how much to fetch, and what kind of brief I want back.

The skill turns that into a repeatable flow.

For example, I can ask:

“Use the x-research-kit skill. Search X for what people are saying about browser agents this week. Start with a small pull, remove obvious noise, and give me a topic research brief.”

Or:

“Use the x-research-kit skill. Pull recent posts from my trusted account list and tell me which new AI workflows are worth testing.”

Or:

“Use the x-research-kit skill. Pull my latest bookmarks, group them by theme, and tell me which ones could become a draft, a test, or a knowledge-base source.”

These are things that you can do if you follow this post until the end. By the end, you’ll be able to research any topic and any accounts you want across X.

Whenever you are ready, let’s dive in!

Wiring X Into Claude Code

There are five steps you’ll go through in this tutorial, from setting up your X app all the way to troubleshooting.

Let’s get started.

Step 1: Set up your X app

To connect Claude Code to X, you need an app in the X Developer Console.

Go to console.x.com, then sign in.

Read more

“How do I stop jumping between scattered AI tools and build one repeatable setup I can actually use?”

That showed up in a bunch of different forms:

1. Claude Chat vs Claude Cowork vs Claude Code

2. Codex vs Claude Code

3. MCP vs CLI

4. Supabase vs local Markdown files

5. Tavily vs Geonode

6. Paperclip vs Hermes vs n8n

7. How to make AI write in your own voice

8. How to turn RSS feeds and newsletters into article ideas

Different questions, same pressure.

This is something I’ve been noticing with some of my clients, people in Agentic Academy, as well as founding members: most of them want the same thing, which is to build an AI system that connects across their work so they no longer need to jump between multiple AI tools, because it’s just so tiring and ineffective.

This Q&A helped me explain how I think about that right now. The answer I kept coming back to was simple: pick a main work layer, teach it your real files, and only add tools when they solve a workflow you actually have.

If you read through the full Q&A, you will see that idea from a few different angles:

1. Benjamin’s question shows how I think about one main AI work layer.

2. Kurt’s questions show why source material and writing rules matter more than asking for a better prompt.

3. Lee’s question gets into why I am moving some workflows from MCP to CLI and Skills

4. Will’s Supabase question shows when a local folder is enough

5. Mynders’ research question shows how raw information becomes useful only when it connects back to the work.

6. And the Codex’s new Record and Replay feature demo at the end shows how you can build a skill by letting AI record and see your screen.

This whole session is a look at how I decide what belongs in the system, what can stay simple, and what is worth turning into something reusable.

I am still refining this monthly Q&A format, so I would love your feedback at the end: more Q&A, more live demos, tool reviews, workflow teardowns, or member build reviews.

Benjamin: “How do I build clean architecture across Claude Chat, Cowork, Code, Notion Agents, Skills, MCP, and my SOPs?”

Benjamin’s question was the perfect starting point because it named the whole problem.

He was trying to figure out how to create a clean setup across Claude Chat, Claude Cowork, Claude Code, Notion Agents, Skills, MCP, and his own SOPs. My read was that he had projects spread across multiple places and wanted them to talk to each other without constantly jumping around.

I get this because I used to have a similar mess. I had chat projects. I had code projects. I had different AI surfaces for different jobs. It worked, but it created mental overhead every time I had to decide where the work should happen.

My answer now is pretty direct: I use Claude Code and Codex as my main work layers.

I do not use Claude Chat much anymore, except for quick mobile help when I am traveling or need a fast answer away from my computer. For real work, I want the agent inside the folder where the files already live.

Inside my Claude Code setup, I have:

Read more

A few weeks ago, I started seeing the same idea everywhere. As I live and breathe AI news, I can sense that something is happening — more than what would normally be expected.

Peter Steinberger, co-founder of OpenClaw, tweeted: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

Then Boris Cherny, who built Claude Code at Anthropic, said something similar: “I don’t prompt Claude anymore. I have loops running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops.”

As someone who hadn’t used Loop before, I was hooked. It made sense to me technically; it could work and remove humans as the bottleneck between AI and the work AI does. So I understood why these were taking over the internet for the last few weeks.

They make loops sound like the next step after prompting:

1. First we wrote better prompts

2. Then we gave agents better context

3. Now the job is to design the process that prompts the agent for us.

And honestly, that sounds exciting.

It also made me nervous.

Because once you let an agent keep going, you are trusting it to know three things: what to do next, how to check its own work, and when to stop.

If those three things are clear, a loop can be useful.

If they are vague, the loop can keep burning tokens while making changes that feel active but do not actually move the work closer to done.

That is the part I kept getting stuck on.

When I was trying to learn more about Loop, another problem came up. Most of the examples I found were about coding: fix the test, review the PR, improve the score, run until the check passes.

Those make sense because coding has a clearer feedback loop:

• The test passes or fails

• The review score goes up or it does not

• The page renders correctly or it breaks

But I do most of my work in drafts, pages, images, presentations, and research notes, and some of them also involve websites.

So my question was simpler:

“Where does a loop actually help with knowledge work?”

At first, I was searching for big use cases. I read a bunch of articles about Loop and watched YouTube videos, hoping to find something impressive—something that felt like a new way to work. I wanted to see how people were using Loop to build something from scratch.

But the more I looked, the more I realized I was asking the wrong question.

The question is not whether a loop can build something from scratch. It can, especially when the scope is small or you do not care much about the details.

The better question is:

“In which cases in my work can I trust Loop to do its job?”

For my kind of work, the answer comes only after there is already something real to inspect—something like a draft, landing page, research brief, product spec, or messy first version.

That is when a loop has something to compare against. It can read the current artifact, run one improvement pass, check whether the pass helped, and decide whether another pass is needed.

So I would not use a loop to write a newsletter from nothing.

I would use it after the draft already exists.

When the draft is 70 or 80 percent there, but the final stretch still needs multiple passes: remove repeated points, sharpen the argument, check the voice, fix banned patterns, make sure every section has a job, and stop when the checklist passes.

That is where /loop started to make sense to me.

Not as a replacement for judgment.

As a way to handle the repeated improvement passes I was already doing manually—and to brute‑force my work to completion.

Subscribe now

What A Loop Actually Is

Before we go deeper, let’s take a step back and understand what Loop actually is at its core.

A loop is not a magic agent mode. The simplest version is:

1. Give the agent a job

2. Set when it should come back

3. Let it inspect the current state

4. Let it take one useful action

5. Let it log what changed

6. Repeat until a stop condition is met

Essentially, /loop is Claude Code's time-based command. It comes back on an interval, like every 5 minutes, 10 minutes, or 20 minutes, and runs the prompt again.

When I say “loop” in this post, I mostly mean the practical behavior I want: Claude returning to an existing artifact, checking what changed, improving one layer, and stopping when the checklist passes.

So instead of you returning to Claude and saying, “Okay, now check the draft again,” the loop does that for you.

It comes back, reads the current state, decides what pass to run, makes a change if the rules allow it, and checks whether it should stop.

That is a loop.

In coding, this is easier to understand.

But loop mechanics can also happen outside the coding space, even though the checks have to be more carefully designed.

For a newsletter draft, the check might be:

1. No two sections repeat the same point

2. Every section has one job

3. The draft keeps the original argument

4. The draft removes banned phrases

5. The final version includes a change log

For a landing page, the check might be:

1. The page has one clear CTA.

2. All buttons are clickable

3. Every required section exists.

4. The offer is explained in the first screen.

5. The page is readable on mobile.

Without checks like that, the loop is just the agent taking another swing. And this is where I think people need to be careful:

• If the task is vague, the loop scales vagueness.

• If the artifact is too early, the loop makes too many assumptions.

• If the stop condition is weak, the loop can waste time and tokens.

So, the challenge is how to ensure that the agent improves things with each pass and also knows when to stop.

That is the difference between a useful loop and an expensive slot machine.

Goal vs Loop

Now that you already know about Loop, if you are like me and have read my previous post on goals, Loop raises a new set of questions:

And this is where I got confused at first.

Because technically according to Anthropic, /goal is also a loop. It keeps working until a verifiable condition is met.

Then, what is the main difference between /goal and /loop?

After testing both of them multiple times, I think I have a better way to differentiate them. Here’s a better question to think about whenever you want to use /goal vs /loop:

“Do I need Claude to keep working until a condition is true? Or do I need Claude to come back on a rhythm and check the work again?”

The way I currently think about it is this:

A goal-based loop is the finish-line version.

A time-based loop is the check-back version.

For example, if I am working on a newsletter draft, the goal might be:

Make this draft publishable while preserving the main argument and passing the style checklist.

That is useful because it tells Claude what done means.

But the Loop version adds a different layer:

Every 10 minutes, inspect the draft and improve one layer: structure, redundancy, evidence, voice, or final rule cleanup. Log what changed. Stop when the checklist passes.

This works because editing takes time and effort to keep improving, and it won’t be done in a single pass. At least for me, editing is usually a sequence of smaller passes.

A goal can tell Claude where to end.

A loop can tell Claude how to keep returning to the draft without trying to solve every problem at once.

That is the part that made the concept click for me.

The Four Things Every Useful Loop Needs

Now, let’s explore what actually makes Loop work. This is where the loop started to feel less abstract to me.

A useful loop needs four things:

1. A clear artifact

2. A checker

3. A cap

4. A human gate

Let me explain for each one.

1. The artifact is the thing the loop is improving

That could be a draft, a landing page, a brief, a research note, a sales page, or a product spec. The important part is that something already exists. The loop needs a current version to inspect.

2. The checker is how the agent knows whether the pass helped

For a newsletter draft, the checker might be: no repeated sections, every section has one job, the argument still holds, and the draft follows my style rules.

For a landing page, the checker might be: one clear CTA, no placeholders, required sections present, mobile readable, and no unsupported claims.

Without a checker, the loop is just asking Claude to keep trying.

3. The cap is what keeps the loop from running forever.

That might be five passes, seven passes, 30 minutes, or a token limit. I do not want the agent quietly spending more and more just because the task was fuzzy. If the loop cannot improve the thing within the cap, that is information. It means the task probably needs a human decision.

4. The human gate is the final judgment.

This matters most for knowledge work. Claude can remove repetition, find missing sections, flag unsupported claims, and tighten a rough draft. But I still want to decide whether the argument feels right.

So the loop can improve the artifact, but it should not quietly publish, send, or finalize the work without me.

That gives me a cleaner test.

A weak loop task is:

Write my newsletter.

A stronger loop task is:

Take this 80 percent draft and run editing passes until the checklist passes. Improve one layer per pass, log what changed, stop after seven passes, and leave the final decision to me.

That is the version I trust more.

The loop is not useful because it keeps running. It is useful when it repeatedly improves a real artifact against a clear checker, with a cap and a human gate.

What We Are Building From Here

The rest of this post is the practical version of that test.

I do not want to treat /loop like a command trick you try once because it sounds interesting. I want to see if it can become a small working setup for the kinds of things I already improve in passes: drafts, landing pages, briefs, specs, and research.

So from here, we are going to build the loop around four pieces:

1. The artifact Claude is allowed to improve.

2. The checker it uses to decide whether the pass helped.

3. The cap that stops it from wandering.

4. The human gate that keeps the final judgment with you.

That is the part most loop examples skip over. They show the agent running again and again, but the useful work is deciding what counts as progress before the loop starts.

There will be three use cases where we will experiment with Loop here:

1. Newsletter Editing Loop

2. Landing Page Improvement Loop

3. Brief or Spec Hardening Loop

That is the outcome I want by the end of this post: a repeatable way to turn “make this better” into a loop that knows what to inspect, what to change, what to leave alone, and when to come back to you for any type of knowledge work you do on a daily basis.

I also created a video walkthrough that shows you how to run the Loop Framework Generator and the resulting Loop I use for my newsletter editing process.

Let’s dive in.

Use Case 1: Newsletter Editing Loop

The first place I would test this is newsletter editing. Not the blank page part. The messy final stretch.

I would not use /loop when I still do not know what the post is trying to say. That is too early. If the core idea is still unclear, using /loop will probably make you even more confused about the topic you are writing.

But once the draft exists and the argument is mostly there, the remaining work often becomes a series of narrow checks:

1. Does each section have one job?

2. Are two sections making the same point?

3. Does every section move the argument forward?

4. Do the claims need examples, caveats, or softer wording?

5. Does the voice still sound like me?

That is already how I edit. I just usually restart the process manually.

A newsletter editing loop makes those processes automated and explicit.

The basic version has the four pieces from above:

1. Artifact: the existing newsletter draft, plus any outline or style rules Claude should follow.

2. Checker: structure, redundancy, argument, evidence, voice, and final rules.

3. Cap: stop after seven passes, or earlier if the checklist passes.

4. Human gate: Claude can improve the draft, but I still decide whether the argument, examples, and final voice feel right.

🚨 But there is one more thing I would add before trusting this: loop state.

The loop needs to know what it already did.

Otherwise, Claude might come back five minutes later, reread the draft, and run the same kind of pass again. That would look active, but it would not necessarily move the draft closer to done.

So the change log is not just a note at the end. It becomes the control panel for the loop.

Before each new pass, Claude should read the log, see which pass already happened, decide what the next useful pass is, and stop if the same issue keeps coming back.

This is where the Loop Framework Generator becomes useful.

Instead of asking you to design all of this from scratch, the generator starts with your intent. You tell it something like, “I want to use /loop to improve this newsletter draft.” Then it interviews you for the missing pieces: what artifact exists, what better means, what Claude can read, what it can edit, what it must protect, what checks matter, where the loop should stop, and which decisions should come back to you.

From that, it gives you a detailed /loop prompt you can run instantly.

For the newsletter edit, I used this post as the artifact to improve. The generated prompt might look like this:

Read more

Months ago I wrote about moving my whole project management setup out of Notion and into Obsidian, and a fair number of you replied with some version of the same question.

“So you finally quit Notion?”

Not exactly. Here’s the honest version.

I’ve been a Notion user for the better part of seven years. Project management is the one job I moved out of it, for the reasons I wrote about last time. But my CRM still lives in Notion. So does my content calendar. So does the backlog of every post idea I haven’t gotten to yet. The truth is I just stopped using it for the one thing it was bad at for my workflow, and kept it for the things it’s good at: structured databases I want to filter, sort, and look at in a clean table.

What changed isn’t the tool. It’s who operates it.

Because here’s the part I should be upfront about. When I say “I use Notion” now, I mostly don’t mean me. I’m not the one clicking into the database, adding the row, setting the status, typing the dates. The agent does that.

I connected Notion into my Claude Code setup, and now when I move a draft from a local markdown file into Notion, or build out a content calendar, or update the CRM, Claude Code does the actual work. I still do the final editing inside Notion when something needs my judgment.

But the clicking, the data entry, the querying? That’s not me anymore.

This got a lot more real about a month ago, when Notion released a CLI (Command Line Interface) you can wire directly into Claude Code. I’d been using the Notion MCP before that, and it was fine for asking questions. But the CLI let Claude Code actually do things in my Notion that the MCP couldn’t. MCP also consumes a lot of tokens. So finding an alternative to MCP became my priority, and I’ve been leaning on the CLI more and more. At this point, most of what happens in my Notion happens without me touching the app.

That’s the shift I want to walk through in this post. Not Notion versus Obsidian. Not which app wins. The reframe is simpler than that, and it’s the one idea I’d pay for if I were reading this:

“Notion is the interface. Claude Code is the operator.”

What “Operator” Actually Means

For as long as I’ve used Notion, my newsletter backlog has been one of my favorite databases. Dozens of post ideas, paid and free, captured the moment they hit me so I’d never lose them. On paper, that’s exactly what a backlog is for.

In practice, it just sat there.

Here’s how it actually went. I’d sit down to plan a post, or to run some research with AI on a topic, and the first thing I had to do was open Notion and read my own backlog. One idea at a time. Asking myself which one I still cared about, which one had legs, which one was worth handing to AI to dig into. I was the filter. Every single time.

Before I could do the interesting work, I had to do the boring work of scanning my own list and making the call by hand.

What I wanted was simple. I wanted to say: “Look at my paid post backlog, find the angles worth exploring, and let’s go research the strongest ones.” I wanted the backlog to be something I could think with, not a list I had to read first.

That’s the gap the CLI closed.

Once Claude Code could actually reach into Notion and operate it, the backlog stopped being a list I check and became something I hand off. Now I open Claude Code, not Notion, and say exactly the thing I always wanted to say:

“Go through my paid post backlog and pull the ideas worth researching.”

It reads all of them, so I don’t have to. I make the final call on the few it surfaces, which is the only part that actually needed me.

That one change is what made the rest of this post possible.

The same plain-English handoff works for everything else too. It builds the database. It fills it. It updates it. It writes content into it. I’m not clicking through menus or formulas or six settings to spin up a new view. I say what I want, and the agent does the work inside the tool.

You stop operating Notion by hand and start describing what you want.

The rest of this post is how that actually works, starting with the question a lot of you are about to ask:

“Don’t I already have this with the Notion MCP?”

Subscribe now

Notion MCP vs Notion CLI

This is the fair objection, and a lot of you will have it, because plenty of people already connected the Notion MCP and like it. So why bother with a CLI?

If you don’t know what CLI means, you might want to check out this post first:

The short answer: they do different jobs, and the easiest way to keep them straight is this.

The MCP answers questions about your Notion. The CLI builds your Notion.

Let me unpack that.

The MCP is the asking layer. You wire it into your AI, and now you can have a conversation with your Notion:

• “Summarize this doc.”

• “Find my note on that podcast guest.”

• “What did I write about pricing last month?”

Your AI reads, searches, and reasons over what’s already there. It’s good at that, and if reading and reasoning is all you need, the MCP is the right tool and you can stop there.

The CLI is the building layer. It’s what you reach for when you stop asking Notion questions and start making Notion do work:

• Generate CRM databases worth of 100+ rows

• Query your own database without paying for a separate Notion AI tier to do it

• Run the same job again next week without redoing the conversation

That’s a different kind of task, and it’s where the MCP starts hitting walls.

Here’s the full picture, dimension by dimension, so you can see exactly where each one fits:

To put it simply: The MCP gives you a conversation. The CLI gives you a system you own.

Another thing worth highlighting is that MCP is token‑heavy and slow. Once you move toward a CLI direction, you’ll notice the difference when querying, searching, creating, and updating any of your data.

But none of this means you should rip out the MCP. It’s not going anywhere—Notion is actively investing in it—but I’m no longer using it, since the CLI has done a better job in my workflow.

What You’re Actually Going to Build

So here’s where the rest of this post goes, and what you’ll be able to do by the end of it.

The whole back half of this post is me showing you what this looks like in practice, with the exact commands, on real data I run my own work through. I’ll walk through two things, because they’re the two I lean on most. But they come from the same place.

At its core, the agent can operate anything inside your Notion. You already know Notion holds your databases and your docs, and you already manipulate both by hand. The shift is just that Claude Code does the manipulating now:

1. The first job is structured systems, and this is the big one. Because your agent can have full access over your databases: a CRM that tells you who’s gone cold, a habit tracker with a weekly rollup, a content calendar, a reading list, a research log. You describe what you want to track in plain English, and Claude Code designs the schema, creates the database, fills it, queries it, and keeps it updated.

2. The second thing is moving your actual writing in and out. Because Claude Code works in markdown, it can take a finished draft, a note, a LinkedIn post sitting in a local file and push it straight into Notion as real page content, then pull it back out whenever you want. I used this to move a year of scattered Substack notes and LinkedIn posts by using /goal into a single content library, each piece carrying its own metadata and its full text in the page body, without copying and pasting any of it.

And to make sure you don’t have to rebuild any of this from scratch, I’m handing you the thing I actually use to run it.

It’s a Claude Code skill called notion-builder.

notion-builder/
├── README.md          ← start here: what it is + how to set it up
├── SKILL.md           ← the brain Claude Code reads to operate your Notion
└── references/
    ├── system-recipes.md           ← ready-made blueprints for 6 systems (CRM, calendar, habit tracker, etc.)
    ├── build-cookbook.md           ← how it builds databases and adds rows
    ├── filter-cookbook.md          ← how it queries and filters your data
    └── content-writing-cookbook.md ← how it moves your writing in and out of Notion

Think of it as the operating manual Claude Code reads before it touches your Notion.

It carries the whole build loop (design the schema, create the database, populate it, query it, maintain it), the exact command shapes for every field type, ready-made schemas for the common systems (CRM, second brain, project and task tracker, research database, habit tracker), the content-library pattern for moving your writing in, and the safety rules that keep it from touching anything you didn’t ask it to.

You drop the skill in, share one Notion page you want to update, and describe what you want. That’s the setup. The rest of this post is how each piece of it works, starting with the loop that builds any system.

Now, let’s dive in.

How to Setup the Notion CLI

This is the only process where you actually touch a terminal and click around Notion yourself. It took me a few minutes the first time. Once it’s done, you don’t think about it again.

One heads-up before you start: the CLI is macOS and Linux only right now. If you’re on Windows, you’ll need WSL2. And ntn login needs full membership in your Notion account, so if you’re a guest or restricted member you won’t be able to authenticate.

Step 1: Install it

One command. The quickest way is the install script:

curl -fsSL https://ntn.dev | bash

If you’d rather go through npm (you’ll need Node 22+ and npm 10+):

npm install --global ntn

Read more

I get why. That is where most of us started.

You open ChatGPT, Claude, Gemini, or whatever tool you like. You ask a better question, add more background, paste in a few examples, and try to explain what good output looks like.

Sometimes it works really well.

But then the next chat starts from zero again.

You re-explain the project, re-upload the files, paste the same rules, correct the same mistakes, move the output into Google Docs, Notion, email, Substack, Slack, or wherever the real work happens.

At some point, the problem is no longer the prompt.

The problem is that the AI has no real connection with your work.

That was the main idea I tried to show in a past session with the Cozora Community. I walked through how I run AI Maker from inside Claude Code, including my newsletter folder, my project structure, my CLAUDE.md, my skills, my slash commands, my memory rules, and the way I use agents to help with research, writing, planning, and operations.

This was a live tour of the system I actually use, and now I’m sharing it with you.

When people hear “Claude Code,” they often assume this is for programmers. Margaret, one of the people in the session, asked the obvious question right away:

“So is Claude Code like about coding?”

That is the question most normal people have.

And the answer is: it started there, but that is not where it ends.

Claude Code is useful because it lets an AI agent work inside a real project folder. It can read files, follow rules, create outputs, run repeatable workflows, store a large amount of information, use tools, remember corrections through files and instructions, and help you move from “answer this question” to “help me run this part of my work.”

That is a different relationship with AI.

Subscribe now

The Shift I Was Trying To Show

For the last few years, most AI work has looked like chat.

You are the middleman.

You ask a question, get an answer, copy the answer, paste it somewhere else, open another app, bring back more context, ask again. Then you rinse and repeat.

That is still useful. I still use normal chat sometimes, especially on mobile.

But for my day-to-day work, the center of gravity has moved.

My newsletter now lives in a folder Claude Code can read, including the drafts, archive, writing rules, audience notes, paid-versus-free rules, and performance data.

So when I ask for new post ideas, Claude does not have to guess from the prompt alone. It can inspect the actual project, read the files that matter, see what I have already published, and follow the rules I wrote for the newsletter.

That’s the transformation you can expect when you go full AI‑agent mode.

💡 Quick note: This is also the shift and I are teaching in Agentic Academy for Knowledge Work.

AI chat has a ceiling. You re-explain the project, re-upload the files, repeat the same corrections. Agentic Academy is 10 live weeks where you build one AI system that runs your real work. No coding. Starts June 22. Enroll now.

Learn more about Agentic Academy

Watch’s Inside of The Video

This replay is a walkthrough of the system behind my newsletter and project management setup.

I would not watch it like a normal webinar where you try to remember every tool name. I would watch it with one question in mind:

What would my first agent folder need to understand about my work?

That is the useful lens.

Because the specific tools will change. But the underlying pattern is going to matter for a while:

1. Give the agent a folder.

2. Put the right source material inside.

3. Write the rules it should follow.

4. Create repeatable workflows.

5. Add guardrails.

6. Improve the setup every time the agent gets something wrong.

That is the pattern I kept coming back to during the session.

What We Covered

The session started with a question from Julia about managing multiple systems together.

She was already deep in the work, cleaning up a bunch of Claude projects, trying to build a better master project, and thinking through how memory and project status could work across different kinds of work.

That was useful because it surfaced one of the real problems with AI agents:

They can do a lot, but they can also do too much.

Julia mentioned that Claude Code can sometimes “go nuts” and do far more than she asked for. I have felt that too. Sometimes the agent understands the intent and runs with it in a useful way. Sometimes it does a long chain of work and gives you something that is technically impressive but not what you wanted.

That is why the folder matters.

You need a place where the agent can learn:

1. What this project is

2. What counts as good work

3. Which files matter for which tasks

4. What actions are allowed

5. What mistakes it should not repeat

6. When it should ask before moving

That is the job of the system around the agent.

In my setup, the most important file is CLAUDE.md.

I described it in the session as the brain of the project. It is the file Claude reads first. It tells Claude what the project is, what folders exist, what rules matter, what reference files to use, and what standards to follow.

For AI Maker, that means Claude knows things like:

1. Newsletter drafts live in one place.

2. LinkedIn posts have a different style than newsletter posts.

3. Paid posts need implementation detail.

4. Free posts should be complete on their own.

5. My writing should avoid polished corporate language.

6. If a task involves audience data, it should read the audience files first.

The more I use it, the more I think most people should start with the file that teaches the agent how to understand the project. The complicated automation can come later.

The Six Pieces I Walked Through

During the replay, I broke Claude Code into six pieces.

You do not need all of them on day one. I definitely did not build all of this at once.

But once you see the pieces, the whole thing feels less mysterious.

1. CLAUDE.md

This is the main instruction file for the project.

It tells the agent:

Read more

A few weeks ago, I had a business question sitting in my head that I kept circling:

“How do I grow revenue over the next six months without making the business heavier?”

That sounds like a simple question until you actually have to answer it.

The easy AI version is to paste the question into one chat and ask for a plan. I did that too. The answer was reasonable. It gave me a few options, named the upside, mentioned some risks, and made every path sound possible.

That was the problem.

When every option sounds reasonable, I don’t actually feel closer to a decision; I just end up with a cleaner-looking version of something I’m still unsure about.

Around the same time, I asked my paid readers what they wanted me to write next. One reader asked if they could build an AI advisory board for business decisions. Something that could help them understand risk, spot opportunities, and decide what to do next.

I liked the question because I already had a rough version of that.

Whenever I have a business idea I’m not sure about, I run it through my AI board. I still make the final decision, but the board helps because I make better choices when the question gets pulled apart from a few different directions before I choose.

These are some of the questions I often ask:

1. How do I improve my paid subscriber rate by 50% over the next six months with a limited budget?

2. How do I increase revenue without adding a lot of new cost or recurring work?

3. If I want to grow, what should I build from the assets I already have?

The revenue question is the one that stuck with me.

Because one of the board’s recommendations was to build a cohort.

That is basically what I have been building.

💡 A quick note from me…

AI chat has a ceiling. You re-explain the project, re-upload the files, repeat the same corrections. Agentic Academy is 10 live weeks where you build one AI system that runs your real work. No coding. Starts June 22. Enroll now.

Learn more about Agentic Academy

I do not want to overstate this. The board did not magically invent the cohort for me. The idea was already floating around, and there were still a lot of human decisions after that.

But the board helped me see why the cohort fit better than a few other options:

• The CEO lens liked it because it built from the audience and trust I already had.

• The CFO lens liked that it could create meaningful revenue without requiring a large ad budget.

• The operator lens pushed back because live delivery could become heavy if I designed it badly.

• The critic asked whether I was building a real business asset or just creating another weekly obligation for myself.

That last question was important to think about deeply.

Because I work mostly alone, a good revenue idea cannot only look good on paper. It has to fit the way I actually work. It has to build from what I already have: my subscribers, my writing, my paid archive, my agent-building skill, and the problems readers already ask me about.

That is where a normal AI answer often breaks for me.

If I ask a generic chat how to grow revenue, it might suggest ads, more products, sales calls, partnerships, posts, and more everything.

Some of that advice might be useful. But a lot of it ignores the actual shape of my business.

The Problem With One Polished Answer

Most people use AI for business decisions by asking one general chat for advice.

I do this too.

You paste in the question, add a little background, and ask something like, “What should I do?”

The answer usually sounds helpful. It names the upside and the risk, and it gives you a plan. Sometimes it even says, “Here is the balanced recommendation.”

But one chat is trying to be the strategist, finance person, technical person, operator, and skeptical reviewer at the same time.

The roles start blending together.

The finance view drifts into brand strategy. The operator creates a plan before the tradeoff is clear. The critic gives generic warnings. The final answer feels complete, but it may never force the decision through the lens that actually matters.

How To Give Each AI Advisor A Specific Job

The useful shift was giving each advisor a specific job.

For the revenue question, instead of hearing five different voices telling me to chase growth at all costs, I needed each lens to ask a different kind of question:

1. CEO: Which bet compounds from the audience I already have?

2. CFO: What is the upside, and what cash or time does it risk?

3. CTO: What needs to be tracked before this becomes guesswork?

4. Operator: What is the smallest first-week version?

5. Critic: What assumption would make this whole plan wrong?

That is the board model.

If the CEO and CFO both give the same broad strategy advice, the board fails. If the critic only says “be careful,” the board fails. If the operator starts making a 90-day plan before the decision is clear, the board fails.

Each role needs a job.

The CEO helps choose the bet. The CFO makes the cost and risk visible. The CTO checks whether the idea can be built or tracked without becoming fragile. The operator turns the decision into a real sequence. The critic finds the assumption I am most likely to skip.

Then I decide.

The board supports judgment. It does not replace it.

Subscribe now

Why Context Matters More Than The Persona

After running this a few times, my honest take is that the AI advisor can work.

You can make the model act like a CEO, CFO, CTO, operator, or critic. That part is relatively easy.

The harder part is giving those advisors enough real context to judge anything well.

Without that, the board becomes five polished generic answers. The CEO gives business-school strategy. The CFO talks about margins with no actual numbers. The operator proposes work that assumes a team you do not have. The critic warns about risk without knowing which risks actually matter to your business.

This is where context changes everything.

For AI Maker, that means the board knows things like:

1. I mostly work alone.

2. My business runs through the newsletter, paid posts, consulting, and occasional digital products.

3. My strongest asset is the audience I already have.

4. I care about personal brand, content systems, agent builds, and practical AI workflows.

5. I do not want growth that breaks trust with readers.

Those facts give each advisor something to push against.

The advice becomes more conditional and more useful.

It can say: this idea fits because it builds from the audience you already have. Or, this might work financially because it does not require a large upfront ad budget.

That is very different from a generic growth plan.

It helps me make better decisions based on my current business conditions and priorities. That’s the most important part.

When I Would Use This

I would use this for any decision where the answer sounds simple until you have to live with it.

For example:

1. Should I launch this product now or wait?

2. Should I change pricing?

3. Should I spend money on ads?

4. Should I hire help or stay solo?

5. Should I build a new offer from scratch or use the audience and skills I already have?

The board will not make the decision easy. Trust me, you will still need to make hard decisions after the agent analysis. But at least it can make the decision cleaner so you understand the real trade-offs and what you can expect from each decision you make.

That is what I wanted from it.

What This Gives You

If you build this for your own work, you can turn hard decisions easier to process.

You give the agent enough business context to understand your situation. You define the criteria that matter before the advice starts. You ask separate advisors to look at the same decision from different angles. Then you turn the result into a saved decision log, so the reasoning does not disappear three days later.

That is the productivity gain I care about here.

By the end, you should have a board that can help you:

1. Understand the business context behind the decision.

2. Make the decision criteria explicit before the answer arrives.

3. Separate strategy, money, feasibility, execution, and risk.

4. Pressure-test the recommendation against your real constraints.

5. Save the decision record so you can review it later.

6. Turn a messy business question into a cleaner next step.

What We Are Building: AI Advisory Board

The thing we are building is a small decision system. It starts with one messy business question.

Something like:

How do I grow revenue over the next six months without making the business heavier?

Then it turns that question into a process.

First, the board creates a decision intake. This is where the vague question becomes more specific: what decision are we actually making, what options are on the table, what constraints matter, what evidence do we have, and what would make the decision wrong?

Then the board sends that same decision to separate advisors.

The CEO looks at direction and focus. The CFO looks at money, risk, and upside. The CTO looks at feasibility and tracking. The operator looks at sequence and capacity. The critic comes in after the first round and asks what everyone might be missing.

After that, the chair pulls the views together, completes a scorecard, and saves the decision log.

The flow looks like this:

1. Question in

2. Decision intake created

3. CEO, CFO, CTO, and operator review the decision separately

4. Critic reviews the first four memos

5. Chair synthesizes the board

6. Scorecard completed

7. Decision log saved

8. Next actions listed

If you run this often enough, it becomes a useful habit: one place to think through hard decisions, one process for separating the angles, and one saved record you can review instead of rebuilding the same context every time.

Now, let’s dive in.

1. The Project Files

Same as my other agent guides, we are building this in a local computer folder that you can use within your Claude Code setup.

Here is the folder we are going to build.

Do not worry if this looks like a lot at first. We will have an interview process that can help you fill all these files easily.

But the whole structure is doing a simple job:

1. context/ tells the board what your business is.

2. criteria/ tells the board how to judge the decision.

3. templates/ gives the board a consistent shape for intake, review, and logging.

4. .claude/agents/ holds the advisor instructions.

5. .claude/commands/ gives you one command to run the whole process.

6. decisions/ and runs/ save what happened so the decision does not disappear.

Read more

Lately, I’ve been thinking less about which AI model is “best” and more about what the AI is connected to.

I wrote an in-depth post about it yesterday:

That sounds like a small shift, but it changes the whole conversation.

A better model can help you write, summarize, or reason a little better. But a better connection can change what the AI can actually do with your real work.

• Can it read the right notes?

• Can it pull from the tools you already use?

• Can it help with the messy middle of the project instead of only responding to whatever you paste into the chat box?

That is why I was interested when the Cozora team put together their Q2 report, The Connector Edition.

Cozora is an AI creator community I’m part of, and one of the things I like about their approach is that they focus on people showing how they actually use AI in their work. Not just the clean theory version. The real setup. The parts that are useful, weird, opinionated, and sometimes still unfinished.

For this report, they asked seven creators a simple question:

“What is the single connector, MCP, CLI, or API, that quietly changed how you work?”

The answers turned into a 17-page report covering many of the tools these creators use in their main AI stacks.

The useful part, at least to me, is that the report does not pretend there is one perfect setup.

Some people are using simple connectors.

Some are building their own MCPs.

One person pushes back on the MCP hype and explains why a hybrid setup makes more sense for them.

That is the part I like.

Because this is where I think a lot of AI advice gets too clean. It talks about the “future of work” when the real question is much smaller:

“What do you need your AI to be able to reach?”

For most people, the answer probably is not “everything.”

• It might be your notes

• It might be your research

• It might be one database

Or, it might be your newsletter archive, client docs, sales calls, saved examples, or the project files you keep explaining over and over again.

📘 The Connector Edition: Q2 2026

The report is available at the link below👇

Read more

On a recent One Shot Show session with Mark Miller, Mark opened a blank folder, talked Claude Code through what he wanted, and had a working RSS reader running by the end of the livestream.

That part was impressive.

The app pulled in feeds. It showed recent posts from the sources he cared about. It gave him a real place to read the blogs and newsletters that usually get scattered across tabs, email, and apps.

That is already useful, but as I watched it, I kept thinking about the next problem. An RSS feed reader can show you what is new. It does not automatically tell you what is important.

It cannot tell you which update connects to the project you are building, which question your readers are starting to ask, which product change is worth testing, or which headline is just loud for 24 hours and safe to ignore.

That is the gap I want to work on here.

A while ago, I built a Make.com automation to fix the first half of that problem.

I was subscribed to too many newsletters, blogs, and AI update feeds. I wanted to stay informed, but the reality was a mess. Some updates landed in my inbox. Some lived in Substack. Some were buried in bookmarks. Some were product blogs I kept meaning to check and never did.

So I built a system that pulled those sources into one AI-generated digest.

And honestly, it helped.

I stopped opening 30 tabs just to feel caught up. I had one place to check. The system pulled the sources together, summarized them, surfaced patterns, and sent me something I would actually read.

For my setup, that was already a big improvement. I was no longer relying on things I need to remember or a random Sunday catch-up session to know what was happening in the AI space.

But after using it for a while, I noticed the next problem.

The digest helped me stay updated. The harder part was figuring out what each update meant for the work I was already doing.

So the system solved the intake problem.

But it left the judgment problem mostly untouched.

And it started to affect me a lot as someone who writes for a living. I would read the summary, see a few interesting AI updates, maybe save one or two links, and then still have to do the harder part myself. I still had to figure out which updates connected to my current projects, which ones were useful for my readers, which ones were just noise, and which ones could become a real post.

For example, if an AI tool keeps showing up in newsletters I trust, I want to know whether it should change anything about my own setup. This is a very important part of my research process when deciding which posts to write next.

Why I Am Moving This Into Agentic Workflow

The Make.com version was great at moving information around. That was the right first step.

But as you probably know, I’ve been using agentic AI a lot with Claude Code and Codex. My drafts live here, along with my notes, including rules, post archive, and paid vs. free criteria. The agent can see all the source material I already use to make decisions.

This makes a huge difference when I’m trying to build a research process with my agent.

Instead of sending me a digest and making me synthesizing everything manually, I can ask the agent to compare new updates against my own work.

That is the upgrade I am building in this post.

What Changes When The Agent Can See The Work

Here’s my first Make.com version that worked:

1. Pull updates from sources I follow.

2. Summarize them.

3. Send me a digest.

Here’s how the new version works:

1. Pull updates from sources I follow.

2. Find the recurring signals.

3. Compare those signals against my own archive, notes, projects, and criteria.

4. Tell me what might be worth acting on.

This is where the new version becomes more personalized to my work and moves me closer to turning the research into productive output for writing my next posts.

This Works Beyond Newsletter Writing

Before you assume this only applies to newsletter writers, I want you to know it can work far beyond writing newsletter posts.

For example, of course, if you write online, it might mean finding a better angle for your next essay or newsletter. If you run a business, it might mean noticing a shift in your market before it becomes obvious. If you work in a specific field, it might mean turning scattered updates into a short weekly brief you can actually use.

The same system can serve different jobs because the core loop is the same: monitor the field, extract the signal, compare it against your own context, then decide what deserves attention.

For me, the writing use case is the one I feel most directly.

Instead of asking, “What should I write about?”, I can ask: “What is my field already paying attention to, and what have I not said about it yet?”

That question is more useful because it has pressure from both sides. It looks outward at what is happening, then inward at what I have already covered.

This is why the new version offers more value: the output is no longer just “here’s what happened this week,” but a short list of possible decisions:

1. Write about it if you publish in that field.

2. Bring it into a meeting if it affects your team.

3. Add it to a project if it changes what you are building.

4. Turn it into a client brief if people you advise need to understand it.

5. Save it as a research note if the signal is interesting but early.

6. Test it if the claim sounds useful but unproven.

7. Ignore it for now if it is loud but not relevant.

That last one matters more than I expected.

One of the hidden benefits of a system like this is that it gives you permission to ignore more things. When every update arrives in your inbox by itself, everything can feel equally important. When the agent reviews the week as a whole, patterns start to separate from noise.

In the rest of this guide, I will show you how I am building the working version: the source list, the Tavily scan, the optional email path, the archive check, the scoring rules, and the weekly output that turns a pile of updates into something I can actually use.

The System We Are Building

What we are building in this post is a Newsletter-based Industry Radar Agent.

The simplest version is a weekly research agent that monitors the sources you care about, pulls out the useful signals, compares those signals against your own work, and gives you a short list of decisions to make.

And this system also focuses on what happens after the information comes in.

By building this, you will learn how to:

1. Choose sources that are worth monitoring instead of dumping every feed into one list you don’t care about.

2. Use Tavily, RSS feeds, and optional email sources as inputs.

3. Give the agent your own archive, current projects, and decision rules so it has something to compare against.

4. Turn a weekly pile of updates into a ranked set of signals.

5. Decide whether each signal deserves writing, research, testing, discussion, project work, or nothing.

After setting this up, You should be able to open one daily/weekly file and see:

1. What changed in the field you are tracking.

2. Which topics or questions are showing up repeatedly.

3. Which updates connect to your current work.

4. Which ideas you have already covered.

5. Which signals may deserve a post, brief, project, meeting, experiment, or follow-up.

6. Which updates are probably safe to ignore.

For writers, this can become a grounded idea system. For founders, it can become a market radar. For consultants, it can become a client brief generator. For researchers, it can become a weekly field scan. For team leads, it can become a way to bring useful outside signals into planning without asking everyone to read the same pile of links.

The weekly flow looks like this:

1. Pulls recent updates from selected RSS feeds, Substack feeds, public URLs, and optional email newsletters.

2. Uses Tavily to fetch or research sources when RSS is not enough.

3. Extracts titles, topics, claims, reader problems, formats, and recurring themes.

4. Compares those patterns against your archive, current projects, and decision criteria.

5. Returns 5 to 7 ranked signals or ideas.

6. Labels each item as write, build, research, discuss, save, or skip.

7. Optional: For Substack writers, adds a free vs paid post recommendation when relevant.

Now, let’s dive in!

The Agent Folder Setup For The Newsletter-Based Industry Radar Agent

Before we get into the details, here is the folder we are going to use. Download them below:

Read more

I keep running into the same annoying problem with AI agents.

I give the agent a real task. Not a tiny prompt like “rewrite this paragraph” or “summarize this file.” A real task.

Research this topic and turn it into a brief. Build this app and check that it works. Take these newsletter posts and turn them into a batch of social posts.

The agent starts working. It makes progress. Then it stops and waits for me.

So I type something like: “Continue, please.”

Then it works again. Then it stops again.

So I type: “Keep going.”

After a while, I realize I am not really delegating the work. I am sitting there like a tiny project manager for a machine that keeps needing permission to take the next obvious step.

That’s the part that feels weird, because I still can’t see the promise of AI fully offloading my work.

As agentic models, Claude Code and Codex are clearly getting smarter. They can handle more work than they could even a few months ago: research, writing, file edits, debugging, batch processing, and longer project tasks.

But that creates a new problem. The agent can execute more steps now, but it still does not always finish the job end to end. It might move the work forward, then stop. It might complete the obvious part, but skip the check. Or it might say the task is done before it has shown any real proof.

And honestly, I don’t see this as delegation at all. Complete delegation means I’m no longer the bottleneck between AI and my work.

I want to give it the job, walk away for a bit, and come back to one of three things:

1. The finished work.

2. A clear blocker.

3. A short report showing what happened.

That sounds simple, but this is where the real shift happens.

For small tasks, prompting is enough. You ask, it answers, you respond, and the loop works fine.

But long-running work is different. If the job needs several rounds of work, checking, fixing, and retrying, the agent needs more than another instruction.

It needs a finish line.

The question changes from “What should I ask next?” to “What does done look like, and how should the agent prove it?”

The Two Ways AI Quits On You

When you give an agent a bigger task, I think there are two common ways it can fail:

1. Fake done

The agent says the work is finished, but when you check it, the source links are missing, the file count is wrong, the page does not render, or half the batch never got processed.

This is the one that makes you lose trust.

2. Undefined done

The agent can move the work forward, but it does not know what the finished version should look like, how to check its own work, or what boundaries it should respect along the way. So it guesses. Sometimes that means it stops too early. Sometimes that means it keeps trying more things. Either way, you are still the person deciding whether the job is actually finished.

This is the one that keeps you as the bottleneck.

At first, I blamed the agent for both. I thought the model was being lazy when it stopped early.

But the more I used these tools, the more I started to think the real issue was the finish line I gave it.

I was giving instructions without giving evidence.

There is a difference.

The Developer Hack: Ralph Wiggum Loop

Developers saw this problem earlier because code gives agents a clearer finish line.

A bug fix can pass or fail. A test can run. A file can change. A terminal can show an error.

So when coding agents started stopping too early or calling work done too soon, developers had an obvious question:

“How do we keep the agent working until the check actually passes?”

One workaround became known as the Ralph Wiggum loop. The basic idea is pretty simple:

1. Give the agent a task.

2. Let it work.

3. Check whether the work passes.

4. If it does not pass, send it back in.

5. Keep looping until the condition is met or the process hits a stop point.

In fact, Anthropic team shipped it as plugins. The Ralph Loop became really hyped earlier this year. And I like the idea because it points at the right problem: the agent should be able to finish the work according to your instructions and stop when the work reaches a condition you can verify, not halfway through.

But the Ralph Wiggum version still feels very developer-centric for me. Because it involves with scripts, terminal commands, task files, test suites, and some kind of loop wrapper. That makes sense if you are shipping code. It feels much harder if the job is research, writing, inbox cleanup, campaign planning, content repurposing, or a messy project backlog.

Most knowledge work does not have a neat test suite. That does not mean it has no finish line. It just means we have to write the finish line differently.

Why /Goal Mode Matters

This is why I think goal modes in tools like Claude Code and Codex are worth paying attention to.

I think this is the evolution of the Ralph Loop. The pattern is moving from a developer hack into the agent itself.

The way it works is pretty simple.

You type /goal and describe the condition you want to be true when the work is done:

• In Claude Code, that condition starts the work. After each turn, a smaller evaluator checks the conversation and asks: has this condition been met? If yes, the goal clears. If no, the evaluator gives a short reason, and Claude starts another turn with that reason in mind.

• Codex treats the goal in a similar way. The goal text becomes both the starting instruction and the completion criteria. Codex keeps that objective attached while it works, and uses it to decide what to do next, whether the task is finished, or whether it needs more input.

Regardless of which agents you use, the core function of the /goal is the same:

Instead of asking the agent to do one thing and waiting for it to stop, you define an outcome and success criteria. Then the agent keeps working across turns until it has evidence that the goal has been met, or until it needs to stop and report what blocked it.

That changes the job of the human. You are defining the finish line clearly enough that the agent can work toward it instead of micromanaging every next step.

This is a different skill from prompting.

A prompt usually says, “Do this.”

A goal says, “This is what should be true when the work is done, this is how you prove it, and this is when you stop.”

The goal can’t be vague, because if it is, the agent has to guess what it means and you’ll end up with an output you don’t really want.

For example:

• “Organize my files” sounds helpful, but what does organized mean?

• “Research this topic” sounds normal, but how many sources count? Which questions need answers? What should happen if something cannot be verified?

• “Repurpose these posts” sounds clear in your head, but does that mean 5 posts, 50 posts, every post in a folder, or only the ones that match a certain topic?

The agent cannot grade what you never defined. And this is the part I think matters most: The agent can only be judged on evidence it surfaces.

If it says, “I checked everything,” that is a claim. If it shows the list of files it processed, the sources it used, the tests it ran, the pages it rendered, the links it could not verify, and the blockers it hit, that is evidence.

A good finish line is built from evidence, not vibes.

Subscribe now

How I Used Goal To Build A Landing Page

The easiest way to see this is with a real task.

I tested this by asking Claude Code to build a landing page for a free download called the Claude Code Goal Kit.

The job was not just “make me a landing page.”

That would have been too vague.

I wanted a single-page responsive index.html that captured an email in exchange for the kit. I wanted it to follow a direct-response structure. I wanted the claims to stay specific. And I wanted the agent to prove the page met the bar before it called the job done.

The prompt I used didn’t just tell the agent to build a page; it also told the agent what the page was for, what structure to follow, where to deploy, what kinds of claims were allowed, what proof to show, and when to stop.

The result was a landing page that was deployed instantly on Vercel, with no back-and-forth at all: https://goal-kit-landing.vercel.app/

The page contains specific numbers as I put in the prompt, which is important, because this shows that the agent has to follow my specific inputs and verify the numbers before it can say the job is done.

It also followed the seven sections of what makes a landing page good for boosting conversions. It included the problem and proof sections. It gave the CTA a benefit. It built the page as a real artifact instead of only giving me copy in a chat window.

This is exactly what I wanted from an agent: I can ask it to do something, walk away, and by the time I get back, the work is done.

What We Are Building

Here comes the most important part of this post: how to replicate what I’ve learned so you can apply it on your own, regardless of what tasks you want the agent to do.

By the end, you should be able to write a goal that gives the agent six things:

1. A clear outcome.

2. Proof that the work is finished.

3. Guardrails for what should not break.

4. Boundaries for what the agent can touch.

5. Next-Move rule that tells the agent what to do after a check fails.

6. A stop rule for when it should report back instead of guessing.

That is the framework.

Then we are going to apply it to three different jobs:

1. A company research goal, where the finish line is a Google Sheet filled with one brief per company from a source list.

2. A landing page goal, where the finish line is a rendered page with the right sections and checks.

3. A repurposing goal, where the finish line is a completed batch with every source accounted for.

I think those three examples well represent the variety of things you can do with ‎⁠/goal⁠. They show three different kinds of “done”: a verified answer, a working artifact, and an empty queue.

After that, the goal is to make this usable beyond my examples.

So we are also building a small interview skill called /goal-prompt-builder. You tell it what you want the agent to do, what proof should count, what boundaries matter, and when the agent should stop. Then it gives you a ready-to-run goal prompt for your own task.

That means the framework is not locked to research, landing pages, or repurposing. You can reuse the same shape for inbox cleanup, project backlogs, company briefs, draft checks, file organization, or any long-running task where the agent needs to work, check, fix, and report back.

That is what I want from agent work: an agent that knows the finish line, shows its proof, and tells me when it cannot get there.

Now, let’s dive into the six frameworks for building effective goals.

The Six-Part Framework For A Goal That Actually Finishes

The landing-page example worked because the goal had more shape than a normal prompt.

If I want an agent to run for longer without me hovering over it, I need to give it that shape on purpose.

This is the six-part framework I am using to turn a vague task into a goal an agent can actually finish:

1. Outcome.

2. Proof.

3. Guardrails.

4. Boundaries.

5. Next-move rule.

6. Stop clause.

Each part prevents a different kind of agent failure.

1. Outcome

The outcome is the end state in one sentence.

This is where you describe what should be true when the job is finished. Not every step the agent should take. Not every possible detail. Just the result you want to come back to.

Weak outcome:

“Research this topic.”

Better outcome:

“Read the company list from this spreadsheet, research each company, and write one completed row per company into a Google Sheet with columns for what the company is, the problem it solves, the product it sells, who it serves, source links, and anything that could not be verified.”

The better version gives the agent a target. It does not just tell the agent to start moving.

2. Proof

Proof is what the agent has to show before it can call the work done.

This is the part most people skip.

They ask the agent to finish the task, but they do not ask it to surface the evidence. Then the agent says “done,” and now the human has to inspect everything manually.

For company research, proof might mean:

1. Every company from the source sheet has a completed row in the output sheet.

2. Each row includes company overview, problem, product, target customer, and source links.

3. Anything unverifiable is marked clearly instead of guessed.

For a landing page build, proof might mean:

1. The page renders successfully.

2. The expected sections are present.

3. The agent reports anything that still looks rough.

For a batch job, proof might mean:

1. Every input file has a matching output.

2. The final count is shown.

3. Failed items are listed separately.

The point is simple: do not let the agent grade itself with a sentence. Make it show the receipts.

3. Guardrails

Guardrails tell the agent what must not break while it works.

This is important because agents can sometimes technically satisfy the outcome while damaging something else.

If the goal is to clean up a batch of drafts, a guardrail might be:

Read more

The replies were good. Better than I expected. But they created a small problem for me.

I could turn every one of those replies into a paid post. The issue is that not every reply actually deserves one. Some of them are a real implementation system with enough setup, files, and checks to justify a full AI Maker Lab guide. But a lot of them are a single skill, a small workflow, or a tweak that I can show you in ten minutes.

So instead of stretching a simple workflow into a deep post just to fill a slot, I decided to compile the smaller ones into a live session and show them in one sitting.

That is what the monthly teardown is for.

This was the second one.

Last month we ran it more like a Q&A, where people submit questions and I answer them. It was helpful, but I felt like it was missing the more valuable part, which is taking a real case and showing the workflow or the skill behind it. So this time I shifted the format. joined me as co-host, monitored the chat, and pushed back on me a few times, which is exactly why having him there is useful.

We worked through six reader questions, plus two bonus workflows I had found on the internet and wanted to test out. I will share the skills and templates in this post.

Why I Bucket Reader Ideas Before I Build Anything

Before we get into the questions, here is the filter I used, because it shaped the whole session.

When a reader tells me what kind of posts they want me to write next, I sort it into one of two buckets:

• The first bucket is a full paid post. This is something that needs role design, company context, multiple files, decision rules, logs, and a maintenance loop to actually work. From this batch, two ideas passed that test: an AI board of advisors for business owners, and an AEO page generator built around a real website. Both of those are coming as their own posts later.

• The second bucket is the teardown. This is the smaller stuff. A skill, a single workflow, a setup question that is better answered by showing the thing running and where it breaks than by writing five thousand words about it.

This was important because most of the replies I got were not actually asking for a bigger system. When I read them together, the pattern underneath was the same. People were not asking for more AI agents. They were asking how to move work from one place to the next without losing it. Chat to action. Transcript to ideas. Document to slides. The agent part was rarely the problem. The handoff between steps was.

That framing carried through almost every question we covered.

What You Walk Away With

Everything I show in this post is yours to keep, the actual skills and the templates behind them, not just a description of how they work:

1. The handoff skill that carries a conversation into your next session.

2. The transcript to angles board that turns a client call into LinkedIn ideas.

3. The docs to deck skill that moves a strategy document into a clean presentation.

4. The Visual Plan Builder that convert your plan into HTML visual file

5. And Opposite Start Ideation for finding a content angle nobody else is writing.

Each one comes with the template, ready to drop into your own setup and run this week.

So read for the question that matches a problem you have, take the skill attached to it, and use it.

Subscribe now

Question One: The Decision That Disappears Three Days Later

The first question described a problem I think a lot of people have. He has a great conversation with AI, makes some decisions, lines up next steps, and then a few days later all of that is gone. The reasoning vanished. He could not pull a real action out of the conversation later.

My answer is a skill I use called handoff.

The idea is simple. Every time you finish a real working session with AI, you do not save the whole conversation. You run something that summarizes what happened, where you landed, and what the next step is, and it writes that into a new file you can open later. When you start the next session, you point the agent at that file and pick up from there instead of starting cold.

The way I run it, I have a conversation in Codex, trigger the handoff skill, and it drops a summary file into a folder. Then I open Claude Code and ask it to review that output, since it was written by a different model. So one tool does the work, the other checks it.

Dheeraj made a good point here that reframed the question. What I was showing was the execution side, how to do the handoff. But the deeper need was memory: how do you manage the conversations that already happened so the AI can reference them in future decisions. His take was that a log file gets you most of the way there as a starting scaffold, but you have to keep optimizing it, because you cannot let it grow forever without hitting the context limit.

We landed on a two-file shape. A log for what is happening in the session, where you are and what the progress is. And a plan file for the bigger thing you are working toward. The log tells you where you are right now. The plan tells you where that sits in the larger project. Both get referenced in your CLAUDE.md so they do not get dropped every time you close a session.

One thing we both agreed on: this does not work well in a plain chat window. Chat has its own context limit, and once you load too much past history it stops making progress. A project folder or a Code session can auto compact and keep going. Although I will add that I do not love relying on auto compact, because you never really know what it kept and what it threw away. I would rather have my own compacting workflow that I can trust, tuned to how I actually want to resume work.

You can grab the handoff skill below:

Read more

Every morning, I was still the glue.

I would check Calendar to see what was coming up. Then Gmail to see who needed a reply. Then Slack to see what changed. Then Granola to remember what happened in yesterday’s meetings. Then Notion or Obsidian to check the work I said mattered.

After all of that, I would open AI and ask it to help me plan the day.

The weird part was that AI was already useful in each individual step.

It could summarize the meeting. It could draft the reply. It could help me think through the project. It could turn scattered notes into a plan.

But I was still the person connecting everything together.

AI gave me the output.

I moved the output into the rest of my work.

That is the human-middleman problem.

The Old AI Workflow Has A Ceiling

For the last couple of years, this was still useful.

We opened ChatGPT or Claude. We asked for help. We copied the answer into Google Docs, Gmail, Slack, Notion, Asana, ClickUp, Sheets, or wherever the real work needed to happen.

Honestly, that first wave changed how I wrote, researched, planned, learned, and built things. I would not be writing AI Maker the way I do without it.

But the pattern had a ceiling.

AI lived in one place. My work lived everywhere else. So even when the answer was good, the handoff was still mine. That is why this year feels different to me.

I have written before about the shift toward the agentic era. The short version is that AI is moving from “answer my question” to “help execute the work.”

Claude Code, Codex, Cowork, and tools like them are not just better chat boxes. They can read files. They can work with connected apps. They can run tasks. They can move closer to the tools where work actually happens.

Given enough context, an AI agent can help with large parts of knowledge work end to end. It can research, plan, draft, review, organize, and prepare the next step.

I know that still sounds a little too big when I say it that way.

And to be clear, I do not think this means you hand your work to an agent and disappear. That is not the version I am trying to build.

The part that excites me is more specific: removing more of the mechanical middle layer so I can spend more time on the work that still needs my judgment.

Strategic thinking. Creative work. Writing. Research.

That is where this Chief of Staff idea came from.

Access Alone Does Not Fix It

When we talk about building an AI Chief of Staff, we mean an AI that can help me set my priorities and execute on them.

Because my work is scattered across multiple apps, the first instinct is to think the problem will be solved once AI connects to enough of them: Gmail, Calendar, Slack, Drive, Notion, Granola, and many more.

But access alone creates a new problem.

Now the AI can see more things, but it still may not know what matters.

It can see your calendar, but it does not automatically know which meeting needs preparation. It can read a transcript, but it does not automatically know which promise should carry into next week. It can find an email, but it does not automatically know whether the person is a customer, a collaborator, a friend, a cold lead, or someone you should ignore.

That is where the context layer matters.

The agent needs to know who you are, what you do, what you are building, who you work with, what happened recently, what you promised, and what matters this week.

Without that, it might summarize everything correctly and still miss the point.

But context alone does not remove the morning loop.

If I still have to wake up, open the tool, paste the prompt, point it at the right files, ask it to check the calendar, ask it to review the meeting notes, ask it to create the brief, and copy the result somewhere useful, I am still doing the mechanical work.

The answer was access plus context plus repeatable jobs that can run at the right time.

That combination is what made the Chief of Staff idea feel more useful than just an AI that can do stuff.

What I Actually Wanted From A Chief Of Staff

I did not want a giant AI employee that runs my life.

I wanted something that could look across the places where my work already lives and tell me what matters today.

That was the first job: daily priorities.

Because that is where the scattered-context problem shows up every morning.

If I have three meetings, fifteen unread emails, two open promises from yesterday, one transcript I have not processed, and a paid post I said I would finish, I do not need another generic productivity plan.

I need a system that can say:

1. Here is what is actually on your plate today.

2. Here are the meetings that need preparation.

3. Here are the open loops you should not forget.

4. Here are the emails or messages that might matter.

5. Here are the drafts waiting for your approval.

That is the kind of Chief of Staff I wanted to build first.

What We Are Building: The Chief of Staff

The version I have working now is built around four layers:

1. Source layer: the apps and files the system can read.

2. Context layer: the folder that tells it what matters.

3. Skill layer: the repeatable jobs it can run.

4. Automation layer: the scheduled runs that make useful work show up.

By the end of this build, you should have a small, working version of the system by copying from the folder I’m sharing, which includes:

1. A source setup that shows the AI where to look: Calendar, Gmail, Drive, Notion, Granola, etc.

2. A folder that explains what matters in your work.

3. A few reusable skills for daily briefs, meeting prep, follow-ups, and reviews.

4. A simple automation pattern so the useful parts can show up without you remembering to ask.

5. Approval rules so the system can help without quietly taking over.

If it works, your morning should feel different.

Instead of opening six apps before you know what matters, the first pass is already waiting for you. Instead of digging through yesterday’s transcript, the open loops are surfaced. Instead of rewriting the same prompt every morning, the recurring jobs have a place to live.

I still review the output, make the decisions, and approve anything sensitive. But I am no longer the person initiating every mechanical step.

The Chief of Staff is the type of AI agent I want in my life that can read the right sources, prepare my day, track open loops, and draft the next useful step while keeping anything sensitive behind approval.

You can build it in Claude Code, Codex, or Cowork. Regardless of the model or the app, it works across them. The Claude ecosystem will read ‎⁠CLAUDE.md⁠, while Codex will read ‎⁠AGENTS.md⁠ as the brain of the system.

In this walkthrough, however, we are going to use Claude Desktop or Cowork instead.

Let’s dive into the first layer: Source.

Subscribe now

1. Connect The Source Layer

The source layer is where the Chief of Staff gets the raw material it needs before it can prepare anything useful.

For my setup, the possible sources are Gmail, Calendar, Slack, Google Drive, Notion, Granola.

Yours may be different. The first thing you need to do is map out which apps you’ve been using in your work. This could include tools like Microsoft 365, Atlassian, ClickUp, Monday, Otter, Fireflies, Zoom, or Asana.

What we want to focus on in this layer is where AI can access your work, including projects, commitments, and people you interact with on a daily basis. Don’t overcomplicate it—start small.

How To Connect Sources In Claude

Fortunately, Anthropic has already most knowledge work apps integrated through their MCPs connectors. The integration process should be easier as you just need to authenticate your Claude into the apps account.

If an app requires a custom connector, you may need to add a remote MCP connector URL before authenticating.

To add MCP connection, go to Customize menu on the left side bar in Claude Desktop app and click “+” to add connectors.

All those apps under Anthropic Partners don’t require custom MCP connectors, so I’m sure you can integrate them instantly.

Just find the apps you are looking for and start integrating them.

After connecting, test them in a simple chat before building the whole system.

For example (Google Calendar):

“Look at my calendar for today and summarize my schedule.”

Then (Gmail):

“Look at recent Gmail messages that may need my attention today. Do not draft replies yet. Just summarize possible action items.”

You can also check your meeting transcript (Granola):

“Get my meeting transcript yesterday on Granola and summarize them for me.”

The goal is to know whether Claude can actually see the sources before you build system around them.

What To Connect First

Here is the order I would use:

1. Google Calendar.

2. Gmail.

3. Google Drive or local folder.

4. Granola or another meeting transcript source.

5. Notion or Asana or Clickup/Monday.com as project management tools.

6. Slack or team chat.

7. Task tools, CRM, or extra databases.

This is a good enough list as the starting point.

However, I would be very cautious with Slack specifically and treat it as optional.

Slack is useful because a lot of real work happens there, but it is also noisy. If you connect it too early, your morning brief can turn into a pile of messages instead of a useful plan.

My recommendation:

Do not connect Slack until the Calendar, Gmail, and folder version is already useful.

When you do connect Slack, start narrow:

1. Direct messages.

2. Mentions.

3. One or two important channels.

Do not start with the entire team history. That is how the system becomes overwhelming too quickly.

What To Avoid On Day One

I would not connect:

1. Every Slack channel.

2. Every Notion page.

3. Every client folder.

4. Every transcript archive.

5. Every task database.

That sounds like a stronger system, but it usually makes the first version worse. You want the Chief of Staff to answer a narrow question first:

“What matters today?”

Once it can answer that reliably, you can widen the sources.

The First Source Test

Before building the folder templates, I would run one simple test.

Ask the AI:

“Using my connected Calendar and Gmail, tell me what may need my attention today. Do not draft anything. Do not send anything. Just identify possible priorities, meetings that need prep, and open loops.”

The output will probably be useful, but incomplete.

That is the point.

It should show you what app access can do by itself, and what is still missing.

Most likely, it will know what is on the calendar. It may find a few email threads. It may identify obvious action items.

But it will not fully know which projects matter, who matters, what you promised last week, how you prefer to work, or which things should stay behind approval.

That is why the next step is the folder.

The source layer lets the AI see the work.

The folder tells it how to understand the work.

2. Build The Context Layer

The context layer is the folder that makes the Chief of Staff useful, but this is where I think a lot of AI systems quietly fail.

People connect the apps first. Calendar, Gmail, Slack, Drive, Notion, all of it. Then they expect the AI to know what matters.

The issue is a calendar event does not explain why the meeting matters. An email does not explain whether the sender is a close collaborator, a paid subscriber, a consulting client, a friend, or someone I should ignore. A transcript does not explain which promise should carry into next week.

The folder fills that gap.

For this build, the context layer is just a set of plain files:

chief-of-staff/
├── AGENTS.md
├── CLAUDE.md
├── about-me.md
├── my-work.md
├── tomorrow.md
├── commitments.md
├── people/
├── meetings/
└── briefs/

Nothing about this has to be fancy. You can put this in Google Drive, a local folder, or whatever place your AI tool can read.

The goal is practical: give the AI enough stable context that it stops treating every morning like a blank conversation.

The Minimum File

If you want the smallest useful version, start with five files:

1. AGENTS.md for Codex or CLAUDE.md for Claude

2. about-me.md

3. my-work.md

4. tomorrow.md

5. commitments.md

That is enough to make the first morning brief much better. You can add people/, meetings/, and briefs/ once the first version works. The mistake I would avoid is filling every file perfectly before running the system.

Instead, you should fill each file just enough, run the Morning Brief, and then improve the files when the output reveals what’s missing.

Now, let’s explore what each file’s main function is and how to customize it for your case.

CLAUDE.md / AGENTS.md: The Operating Manual

The operating manual is the file the Chief of Staff reads first.

In the folder I’m sharing here, I include a CLAUDE.md version because Claude Code or Cowork already knows to read that file. If you are building this in Codex, use the same structure in AGENTS.md.

This file tells the AI:

1. What is the job of this Chief of Staff?

2. Which files should it read first?

3. What can it do without asking?

4. What needs approval?

5. What should it do when it is uncertain?

6. What output format should it use?

7. Which skills are available?

8. How it should handle source conflicts.

The template has eleven sections:

1. Role.

2. Reading order.

3. Approval rules.

4. Uncertainty rules.

5. Output format defaults.

6. Source priority.

7. File map.

8. Available skills.

9. Voice.

10. When to push back.

11. Maintenance.

That sounds like a lot, but the file is doing one simple thing: It tells the AI how to behave before it touches the rest of the folder.

Here is the template I would use myself that you can customize it yourself:

Read more

I used to think SEO was a separate thing from writing.

I would finish a post, feel good about the argument, then remember there was still another layer I had ignored: the SEO title, subtitle, slug, internal links, tags, and image alt text.

And honestly, I kept avoiding it because most SEO advice made the writing worse.

• The title became flatter.

• The headings became too obvious.

• The intro started sounding like it was answering a search query instead of talking to a real person.

This explains what I’ve been seeing here on Substack, especially with so many great writers who have strong storytelling skills—but when I look at the posts themselves, it’s clear they don’t really care about SEO.

No clear search title. No keyword direction. Weak internal links. Images without useful alt text. Slug URLs that are partially cut off, like they didn’t even bother to look at them.

And I get why this happens.

Most writers do not want to write for SEO. I do not either. I want the post to sound like me first. I want the argument to work for the reader already in front of me.

But once you publish something on the internet, discoverability becomes part of the job whether you care about SEO or not.

That doesn’t mean every writer needs to become an SEO expert. I also don’t think SEO should take over the writing process.

The goal is smaller than that.

I want great writing to be easier to find without losing its soul to keyword-stuffed optimization.

Imagine you have a Substack post that sounds like you. The story is there. The argument works. You are almost ready to publish. But you still want the post to be easier to find, easier to understand from search, and better connected to the rest of your archive.

If that’s you, this post is for you.

Does SEO Still Matter When AI Search Is Growing?

Now, the obvious question is whether SEO still matters now that AI search is growing.

I understand why people question it. If you’ve been in the AI rabbit hole like me, you already know that AI search is growing. Google is adding AI answers. More people are asking Claude, ChatGPT, Perplexity, and Gemini the questions they used to type into Google.

But I don’t think SEO becomes irrelevant. What I understand from this shift is the way people discover writing is getting more complicated.

Graphite looked at search traffic across 40,000 large US sites and found that "SEO traffic is down slightly (-2.5%), not dramatically." Semrush makes a similar point from the AI-search side: "Traditional rankings still matter," but AI visibility is becoming another layer to pay attention to.

So no, SEO is not the whole game anymore, but it’s still part of the game. You still need to help readers, search engines, and AI systems understand what your post is about.

We can talk about GEO (Generative Engine Optimization) separately in a later post. For now, I want to focus on SEO because good SEO is still a useful foundation for everything else.

And in my own newsletter, it is not theoretical.

In April, Google accounted for around 60% of my Substack traffic (over 86,000 visits in total) and roughly 30% of my subscription revenue. That was enough data for me to stop treating Google as a tiny side channel and start treating it as a new priority.

People are still searching. I still search. And for my newsletter, search is still bringing in real paying readers. Ever since I started optimizing my posts for SEO, Google traffic has been increasing.

So the question became:

How do I improve the SEO layer around a finished draft without turning the post into generic search content?

That is why I built an SEO review agent.

Its job is not to write the post for me. It is not allowed to rewrite the essay by default. It only reviews the finished draft and gives me the parts I usually forget or rush: better metadata, image alt text, slug URLs, internal link suggestions, search intent notes, competitive research analysis, and a list of what not to touch.

That last part matters more than I expected.

Because good SEO should help the right reader find the post. It should not sand down the voice that made the post worth finding.

The Mistake I Kept Making With SEO

My mistake was not that I ignored SEO. I knew SEO was important.

The mistake was that I tried to do the important parts manually, usually after I had already spent most of my energy writing the post.

I would finish a draft, then try to think about keywords, titles, slug, headings, internal links, and image alt text in the last mile before publishing.

And honestly, I did not always do enough research.

I might have a rough sense of the topic, but I would not always check what people were actually searching for. I would not always look at the search results to see what kinds of posts already ranked. I would not always compare my angle against the articles I was competing with.

That matters because SEO is not only about adding a keyword somewhere.

It asks questions like:

1. What would someone search before this post becomes useful to them?

2. Which keywords have enough intent to matter?

3. What does the search result page already reward?

4. Are competitors writing tutorials, comparisons, list posts, or opinion pieces?

5. Does my heading structure make the post easy to understand?

Those are valuable questions.

They are also the exact questions I do not want to spend most of my writing time thinking about.

I would rather spend the deep work on the idea, the story, and the argument. But if I leave the research layer until the end, I either rush it or skip parts of it.

That was the real gap.

Instead of asking AI to write the post for me, I’m asking it to handle the research-heavy SEO review I was doing manually.

The Review I Wanted Before Publishing

What I wanted was simple.

After I finished a draft, I wanted one review that could tell me:

1. What search angle actually fits this post.

2. Which keywords are worth caring about.

3. What the current search results seem to reward.

4. Whether my title, subtitle, slug, and headings make the post easier to find.

5. Which internal links and image alt text I should add.

That would give me the part I kept skipping manually.

I would still write the post myself. I would still decide what to apply. But I would not have to do the whole research process from scratch every time.

That’s the agent’s job: handle the research‑heavy review, then give me one ranked report I can apply manually inside Substack

That is the review I wanted.

Now I will show you how I built it.

Subscribe now

What We Are Building: SEO Review Agent

The SEO review process starts from a command, but the command is just the trigger.

The folder is the system.

The folder looks like this:

seo-review-system/
  README.md
  .claude/
    commands/
      seo-review.md
    agents/
      seo-draft-extractor.md
      seo-search-intent-researcher.md
      seo-competitive-researcher.md
      seo-voice-guard.md
      seo-onpage-writer.md
      seo-internal-link-finder.md
      seo-final-synthesizer.md
  seo-reviews/
      writer-context/
        voice-guide.md
        reader-profile.md
        seo-rules.md
      archive-index.csv

From the outside, the workflow still looks simple.

You run one command:

/seo-review [Substack draft link or local draft file]

Behind that command, the folder gives the agent everything it needs:

1. The finished draft.

2. The writer’s voice and reader context.

3. The writer’s SEO rules.

4. The archive for internal links.

5. The seven sub-agents that run review process.

6. The report destination.

This is the process I’ve been optimizing for months. Before I publish a new post, I run this to ensure it follows the right SEO framework without affecting my rhythm and voice. I’ve also been fixing my past posts that didn’t follow the right SEO framework.

If you follow this process, once you finish the SEO agent review, you’ll receive a 15–20 page SEO report that you can use to improve both your existing posts and your drafts.

What You Need Before This Works

This whole process is meant to run inside Claude Code, where the AI agent can read files, use local instructions, deploy sub-agents, call research tools, and save a final report.

I will share the starter folder, the command file, and 7 sub-agents reviewer files separately.

Before continuing, here’s what you need to prepare in advance:

1. Claude Code. The system needs a coding-agent environment that can work inside a folder and read local files.

2. Tavily or another research tool. This handles search intent, competitive research, and current results. Without it, the workflow can still review structure and voice, but the research layer becomes weaker.

3. A finished draft. The workflow starts after the post is written. It can use a Substack share draft link, a published URL, a local markdown file, or pasted draft text. Make sure your draft already includes images so you’ll receive image‑alt‑text suggestions in the report.

4. Writer context files. You need to fill in their voice-guide.md, reader-profile.md, and seo-rules.md so the system knows what to preserve. But if you follow my context-folder guide, you only need seo-rules.md here.

5. An archive index. Readers need a simple map of their existing posts so the internal link finder can recommend useful links.

6. Full post files when possible. The index helps with quick matching, but full posts help the system understand related ideas, voice patterns, and duplicate framing risks.

7. The command and sub-agents. These do not live inside the source-material folder. They live in the coding-agent setup and call into the folder. Read my post on how to structure your Claude Code agent.

8. A reports folder. The system needs a clear place to save the final SEO review before you can apply changes manually.

The command and sub-agents are the reusable parts. The writer context and archive are the personalization layer. We need all of them to make this works.

Let’s dive in so I can explain how to prepare each one to you.

What Each Folder Does

The secret recipe comes from this folder; it’s not from the command, skill, or even sub-agents.

Because the folder holds all of the context together.

When I first started thinking about this, I was tempted to make the command or skill do everything. Give it a draft link, let it search around, let it inspect the post, let it make suggestions, and hope the final report made sense.

That works for one review.

It does not work as well as a repeatable system.

The problem is that SEO review depends on source material the agent cannot guess. It needs to know how you sound, who you write for, what you have already published, what links are real, and what SEO moves you actually want to allow.

If that context only lives in your head, the agent won’t be able to do its job.

So I separated the system into folders. Each folder answers a different question before the agent starts giving advice.

drafts/

This folder answers one simple question:

What post are we reviewing?

If you’re working in a local markdown file, save the finished draft in your writing-drafts folder (or whichever folder you prefer).

Do not put raw notes, half-written ideas, research dumps, or alternate versions in here unless you want the agent to get confused about which thing is the actual post.

In my current setup, the main input is usually a Substack share draft link instead of a local file. Why? Because I want to include all the images for my post so the review system can suggest how to properly improve my image alt text.

That means the drafts/ folder can stay empty for that run.

But I still keep the folder because it gives me a fallback.

The important rule is simple: The draft should already be written.

This system starts after the writing is mostly done. It is reviewing the publishing layer around the post, not helping me think through the blank page.

writer-context/

This is the folder that makes the review feel like it belongs to you.

It answers two questions:

1. What should the agent preserve?

2. Who is the post really for?

This is the most important folder for writers.

Most SEO tools are good at telling you how to become more searchable. They are not as good at knowing which parts of your writing should stay weird, specific, personal, or imperfect.

That is what writer-context/ is for.

In the starter version, I would include three files:

seo-reviews/
  writer-context/
    voice-guide.md
    reader-profile.md
    seo-rules.md

The first two files should be personal to your publication.

The third file can be mostly the same for everyone.

Let me show you what I mean.

1. voice-guide.md

This file tells the agent how your writing should sound and what it should protect.

This does not need to be fancy. In fact, I think it works better when it is plain.

Here is a version I would use for this newsletter:

Read more

A few months ago, I opened a new Claude Code conversation to think through a product decision.

The answer was reasonable. Useful enough. But disconnected.

It did not know which products I already had. It did not know which audience pain point I had heard from members the week before. It did not know what I was trying to avoid. So it gave me the kind of advice that sounded fine and still missed the actual situation.

That same gap showed up during the first AI Maker monthly Q&A for paid members. Eight people asked eight different questions. One person asked about master prompts for Substack growth. Another asked where the money actually is in AI right now. Someone else asked about prompt libraries versus Claude Skills. Then we got into CLAUDE.md, project setup, my current stack, and what I would set up before starting something new.

If there’s one thing I can conclude across these questions, it’s that they all come from the same problem underneath: Maker Lab members are asking how to give AI enough of their world that the answers stop feeling generic.

I recognized it because I had been doing the same thing.

As some of you might already know, I run my newsletter inside Claude Code. In the beginning, my setup was thin, and that was fine: a few rules, a couple of draft examples, some folder structure. Claude could generate good output because the work was still simple enough.

That stopped being true sometime this year. The newsletter expanded into free posts, paid posts, LinkedIn, Substack Notes, live recaps for One Shot Show, infographics, product decisions, member sessions, survey analysis, and a growing list of business calls I wanted to think through with AI. My work got more specific, and my setup did not catch up fast enough.

The prompt was not the real problem

My first instinct was to fix it inside the prompt. I would paste in the existing products. Then the audience. Then recent member feedback. Then whatever constraint I was thinking about that day. The prompt kept getting longer. The output got better, sure. But I was rebuilding my world from scratch every time I started a new chat.

And honestly, that was my mistake because I kept treating the prompt like the place where everything needed to live.

The real problem was one layer below the prompt. If the agent already knew the important parts of my world before I started typing, I would not need to paste them in every time. The prompt could stay small because the source material was already there.

Andrej Karpathy has been calling this “context engineering,” which I think is the right frame. His point is that serious AI work is less about writing a clever prompt and more about filling the model’s context window with the right information for the next step.

That clicked for me because it named the thing I kept running into. I was trying to fix generic answers at the prompt layer, but the missing piece was the material underneath the prompt.

That is the shift this post is about.

If you have followed my Claude Code work, this sits underneath the last two pieces I wrote. The blank folder setup guide was about giving your project enough material for the agent to read. The agent harness post was about the system around the model: the rules, checks, corrections, and review loops that help the agent improve over time.

This post is about the material those systems read.

The truth about your work. Your audience. Your taste. Your decision rules. Your current products. The things you keep repeating in prompts because the agent does not know them yet.

I have been running my own version for a few months. Some of it is working. Some of it I am still rewriting. You are going to see both.

Subscribe now

The context folder I built

The setup is one folder. Inside your project, next to the instruction file your tool already reads, you add a folder called /foundational.

If you use Claude Code, that instruction file is usually CLAUDE.md. If you use Codex, it is usually AGENTS.md.

/your-project
  CLAUDE.md or AGENTS.md
  /foundational
    operator-profile.md
    audience-profile.md
    creator-style.md
    pov-and-principles.md
    decision-rules.md
    project-context.md
    performance-patterns.md

The instruction file is the router. It tells the agent how to work, which files matter, and when to read each one.

The /foundational folder is the source material. Instead of telling the agent what to do, it tells the agent what is true. That distinction took me longer to understand than I want to admit.

At first, I tried to put everything into CLAUDE.md: audience notes, voice rules, tier decisions, product details, current priorities, and anything else I wanted Claude to remember. It felt convenient until the file started getting heavy.

If I asked Claude to fix a typo in a Substack Note, it still had to carry my LinkedIn rules, my paid post boundaries, my product strategy, and a bunch of other material that had nothing to do with the task.

The file was full of useful information. That was the problem. Useful information in the wrong moment still makes the agent worse.

So I split the truth into separate files: one for audience, one for voice, one for decision rules, one for current project context, one for principles, one for performance patterns, and one for how I like to work.

If I ask for a LinkedIn hook, it reads the audience file and the voice file. If I ask whether a topic should be free or paid, it reads the decision rules. If I ask for product ideas, it reads the audience file, project context, and principles.

That is the whole idea: small files, clear purpose, loaded only when useful.

What this changes

The goal here is more modest than perfect AI: a better starting point.

After this is set up, your agent should know the basic truth before you ask the question. It should know who the work is for, what you are building, how you like to make decisions, what your voice sounds like, and which constraints matter for the task in front of it.

That does not mean the first answer becomes final. It still needs your judgment. But it should start closer to the real situation.

You spend less time rebuilding the same background in every prompt, and more time doing the part only you can do: noticing what feels wrong, sharpening the decision, and updating the source material so the next answer starts stronger.

That matters because most AI work is a loop. You ask, review, correct, sharpen, and ask again.

If the first version starts generic, the whole loop gets heavier. If the first version starts closer to your actual work, the loop gets easier to steer.

What you will build for AI context management

The rest of this post walks through the version I am using right now.

By the end, you will have:

1. The routing block: The exact instructions you can paste into CLAUDE.md or AGENTS.md so your agent knows which foundational file to read for each kind of task.

2. The seven files: What each file is for, what to put inside it, what to keep out, and when the agent should use it.

3. The 60-minute setup process: The order I would build this in if I were starting again, including the question I use to pull beliefs and rules from my existing posts.

4. The maintenance loop: How to update the folder from real friction instead of pretending you will do a perfect monthly review.

If you want a context folder that tells the agent enough truth about your work that it can stop guessing, this post is for you.

This context folder works whether you use Claude Code, Cowork, Codex, Cursor, or any other AI agents.

Let’s build it.

The routing instructions

The first thing I would add is the routing instruction.

This goes in the file your agent already reads before doing work. Here is the version I would start with:

Read more

I’ve written about Claude Code a few times now, and each post came from a different stage of my own learning curve.

The first big one was my complete Claude Code guide. That post was mostly about showing what Claude Code can actually do: read files, run commands, work with MCPs, use Skills, create agents, manage projects, and turn one folder into something closer to a personal AI operating system.

That post did well because it answered the first question most people had: why should I care about Claude Code at all?

Once people saw what was possible, the next question showed up almost immediately.

How do I actually set this up for myself?

That was the blank folder problem. You open Claude Code, point it at a project, and suddenly you have to decide what goes inside the folder:

• What goes in CLAUDE.md?

• Which files should Claude read first?

• What should become a command?

• What should become an agent?

• How do you build enough structure without creating some overcomplicated setup you never use?

So I wrote the blank folder setup guide. That post moved from “here is what Claude Code can do” to “here is how to give it a useful project to work inside.”

But after using this kind of setup every day, I ran into the next problem: the setup worked, then it plateaued.

The next ceiling after running your first Claude Code setup

At first, the improvement was obvious. Claude knew where my newsletter drafts lived. It knew my LinkedIn posts had a different style than my long-form essays. It knew I had free versus paid rules. It knew I cared about voice, not just clean writing.

That alone made the output much better. But after a few weeks, the same little problems kept coming back:

1. Drafts got close, but still sounded a little too polished.

2. I kept correcting the same voice issues in different sessions.

3. Repurposing sessions blurred together, so LinkedIn, Notes, and Twitter started sounding like versions of the same essay.

4. Research and drafting sessions carried too much of the wrong context into each other.

5. Claude could create a draft, but I was still the quality gate every time.

That was frustrating because I had already done the setup work. I had CLAUDE.md. I had rules. I had commands. I had agents.

So I did what I usually do when something feels almost right: I tried to make the instruction files better. I added more rules, made the wording stricter, and explained the voice more clearly.

That helped a little, but it did not fix the deeper issue. The starter setup gave Claude instructions. What I needed next was a system around those instructions.

That system is what I mean by agent harness.

What agent harness means in plain English

Agent harness sounds more technical than it needs to. The simple version: it is everything around the model that decides what it remembers, what it checks, which task gets which context, and who reviews the output.

For my newsletter work, that means:

1. Repeated corrections should stick across sessions.

2. Mechanical style checks should run even when Claude forgets.

3. Different writing jobs should not bleed into each other.

4. A draft should get reviewed before I spend my attention on it.

That last part is the big shift. Most people stop once Claude can create the first version. But the first version is only the first layer.

If you care about quality, voice, and repeatability, the better question is: what happens after Claude writes the first version?

Does the system remember what went wrong last time? Does it check for obvious violations? Does it keep each task in its own lane? Does another agent review the output before you do?

That is the level I wish I had built earlier.

What this makes possible

My newsletter repo is the clearest example because this is where the harness has to do more than generate text.

1. Drafting paid posts without losing the voice

When I draft a paid post, Claude does not just read one generic instruction file and start writing. It needs to know the newsletter voice, the free versus paid boundary, the topic history, the reader survey, and the repeated corrections I have made over time. If the draft starts sounding too polished, I want that caught. If I mention metrics without caveats, I want that flagged. If a paid post has strategy but not enough implementation, I want the system to notice before I do.

That is where memory and hooks matter. Memory keeps the repeated corrections from disappearing between sessions. Hooks catch the obvious violations that Claude might forget when the task gets complex.

2. Repurposing one newsletter without blending every platform

When I repurpose a finished newsletter, the problem is different. One command can run three agents in parallel: one turns the newsletter into LinkedIn, one turns it into a Twitter thread, and one extracts Substack Notes. But those agents cannot all think the same way. LinkedIn needs a rawer, sharper cadence. Notes need short, but inspiring thinking. Twitter needs one tight thread arc instead of a compressed version of the whole essay.

That is where agent is important. Each platform gets its own context instead of one long conversation where every format starts sounding the same.

Then there is the review layer. A draft agent can create the first version, but another agent should check whether it sounds like me. Another can check whether the paid boundary is clear. Another can flag weak claims, missing caveats, or sections that feel too abstract.

That is the evaluation loop. Claude is not only generating the work. It is helping inspect the work before I spend my own attention on it.

3. Turning scattered notes into a weekly review I can trust

The same pattern shows up in project management. My /weekly-review command does not just ask Claude to summarize my Obsidian notes. It pulls decisions from the week, checks annual goals, compares quarterly priorities against the current sprint, drafts next week’s plan, then runs a review pass before I use it.

The harness matters because each part has a different job. Memory keeps my planning rules alive: do not create too many priorities, separate decisions from ideas, and flag anything with clear action and deadline. Hooks can catch missing dates, empty next steps, or tasks with no project. The command coordinates the inputs. A reviewer pass asks whether the plan actually matches the goals or whether Claude ranked something confidently for the wrong reason.

That review used to take around an hour on Sunday. Now it takes a few minutes, with the caveat that I still sanity check the priorities myself. But the starting point is much better because Claude is not only summarizing notes. It is checking the plan against the rules that matter.

None of this came from one magical prompt. It came from four layers I skipped at the beginning.

Subscribe now

What you will be able to build

By the end of this post, you should be able to take a normal Claude Code project and turn it into a more reliable working system.

Not perfect. Not fully autonomous. But meaningfully better than a folder with instructions.

You will have a way to:

1. Turn repeated corrections into memory, so Claude stops making the same mistakes across sessions.

2. Add mechanical checks with hooks, so predictable issues get caught while the work is happening.

3. Connect agents with one command, so multi-step workflows stop depending on you as the operator.

4. Add evaluation loops, so outputs get reviewed, repaired, and checked again before they reach your final judgment.

The examples are built around my newsletter workflow because that is where I have the clearest scar tissue. But the pattern applies beyond writing.

If you use Claude Code for research, product work, project management, coding, or content operations, the same problem shows up eventually: Claude knows enough to help, but not enough to reliably manage the process around the work.

That is where the harness begins.

Layer 1: Memory that turns corrections into system rules

Here is what made memory click for me: not every instruction I put in CLAUDE.md changed Claude’s behavior reliably.

I had rules in there like no em dashes, no contrived rhetorical patterns, and no generic AI endings. Claude would follow them sometimes. Then the same mistake would come back in another draft.

At first I thought the rule just needed stronger wording. So I made the instruction clearer. Then stricter. Then more detailed.

That helped a little, but it did not fully solve the problem.

The bigger shift happened when I started turning repeated corrections into memory. When a mistake kept showing up during real work, I saved the correction there instead of only rewriting the project rules.

That changed the feel of the system. Claude did not stop making every mistake forever, but it repeated fewer of the same ones. The correction started carrying across sessions in a way that felt more durable.

That is when I realized CLAUDE.md and memory are not the same tool.

CLAUDE.md is for stable project rules:

1. What the project is.

2. Where files live.

3. What voice rules apply everywhere.

4. What the main workflows are.

Memory is for the corrections you only discover after Claude has worked with you for a while:

1. “When a LinkedIn post ends by restating the thesis, replace the recap with a sharper final punch or a direct question.”

2. “When reviewing voice, compare against recent daily LinkedIn posts before suggesting rewrites. Do not judge from the generic brand rules alone.”

3. “If a newsletter draft sounds too polished, look for the missing messy part: what failed, what I changed, or what I am still unsure about.”

4. “When a paid post explains the strategy but skips the setup details, flag the missing blueprint pieces: steps, templates, failure modes, and checks.”

Those are not abstract principles. They are bruises. They come from moments where the setup almost worked, but missed something important.

That is why memory is powerful.

There are two ways I create memories

The manual way is simple. Whenever I notice friction during the work, I ask Claude to save the correction into memory.

The second way is auto memory. Claude Code can notice corrections during the conversation and save them automatically.

That does not mean I blindly trust whatever gets saved.

Every so often, I open /memory, look at what Claude stored, and clean it up. Some memories need sharper wording. Some are temporary and should be deleted. Some are useful, but belong in a different file.

That’s why this review process is important. You need to be detailed here and make sure every memory serves its purpose, does not contradict the others, and is supported by really specific instructions.

Where Claude Code stores memory

One thing that confused me at first: this memory folder does not live inside your project by default.

Claude Code stores project memory in its own project-specific folder. For this newsletter, mine lives here:

/Users/wyndomb/.claude/projects/-Users-wyndomb-Downloads-AI-Maker-Newsletter/memory/

The long folder name comes from the project path. If your project is somewhere else, your folder name will be different. The easiest way to find it is to open:

~/.claude/projects/

Then look for the folder that matches your project path. In my case, /Users/wyndomb/Downloads/AI Maker Newsletter becomes:

-Users-wyndomb-Downloads-AI-Maker-Newsletter

Inside that memory/ folder, Claude keeps the memory index and the individual memory files.

The four memory types

I would not treat memory as one big bucket. There are four types of memory. They matters because it tells Claude how stable the information is and how to apply it:

Read more

There will be more of these, but I want to be honest about this first one because I am still figuring out the format.

One of the things I want to offer paid members this year is more access to how I think through real questions in real time. The polished tutorials and finished frameworks in my regular newsletter posts are still useful, but I also want to share more of the messy middle where someone asks a question, I share what I am currently seeing, and we use that as a way to uncover what is actually useful.

This first session was mostly Q&A. I answered submitted questions, shared my screen, walked through parts of my AI stack, and talked through decisions that usually stay behind the scenes.

Future sessions might look different. They could become live demos, tool reviews, workflow teardowns, or sessions where I review what members are building.

I am treating this first session as a starting point and a way to gather feedback on what actually helps you learn and apply AI.

And to be honest, I already like this Q&A session.

The questions pushed me into places I do not always cover in a normal newsletter post. How I think about making money in AI. What is inside my current AI stack. How I maintain my own CLAUDE.md file when using Claude Code. Why I think prompt libraries are useful, but limited. What I would tell someone trying to grow on Substack without depending on one giant master prompt.

But if I had to boil it down to a single most important thing for this month’s session, it would be the idea of building your own context management with an AI agent. AI is already so good at understanding intent; what it doesn’t have is everything related to your work, how you think, and the constraints you operate under.

That realization came from the questions paid members asked:

1. Hema’s question about Substack growth pointed to the need for better audience and positioning files.

2. Tom’s question about Claude Skills pointed to the workflows Claude should remember.

3. James’s question about CLAUDE.md pointed to the instruction file that keeps evolving as your work changes.

4. Raj’s question about starting a new project pointed to the folders and source material you need before AI can help well.

5. Simon brought the business side into the same conversation.

6. And Ben asked about my current AI stack, where I showed all the AI tools I’m currently subscribed to.

So the direction is less about finding the perfect prompt and more about building the context files around your work.

That might mean a small folder of past work. It might mean a file that explains your audience. It might mean a simple instruction file that tells Claude how you make decisions. It might mean turning one repeatable process into a Skill so you do not have to remember the steps every time.

I hope you can learn even more from the questions other members are asking and adapt those insights to your own situation.

At the end, I also included a short survey because I want your feedback on what this monthly member format should become.

Now, let’s dive into each of the questions here

Subscribe now

Hema: What should a master prompt for Substack growth include?

This month’s session started with Hema’s question about a master prompt for Substack growth.

The context matters here.

Hema is a coach building across Instagram, LinkedIn, and Substack. She wants to understand what kind of content lands with her audience, and eventually she wants to add a paywall.

So the surface-level question was about a master prompt.

But the deeper question was really about how to help AI understand her business well enough to give useful content advice.

My first instinct was to show the prompt side of it. I have a paid post on turning Claude into your brain’s most valuable co-worker, and that post includes a master prompt people can adapt.

But as I talked through the answer live, I kept coming back to the part that matters more now:

The prompt is only the steering wheel. The files are the engine. But this doesn’t mean that prompt is no longer important. I still use prompts. I still think a clear prompt matters.

But if your entire AI setup depends on one giant prompt, the model has to relearn your world every time you ask for help.

That becomes fragile fast.

So for Hema, I would not start by trying to perfect one master prompt for Substack growth. I would start by building a small folder of source material that tells Claude what is true about her work.

For a coach building across multiple platforms, I would create a few simple files:

Read more

A few months ago, I built a Claude skill that turns newsletter posts into LinkedIn carousels. I wrote about the whole process here, and the honest truth is that it worked. For the first time, I could make carousels without opening Canva or spending an hour fixing tiny alignment issues.

That mattered because I had avoided carousels for months. They always felt like one of those content formats I knew I should use, but never wanted to touch because the effort-to-output ratio felt broken. The old skill changed that. Claude could:

1. Read my newsletter or raw idea.

2. Break the content into a hook, body slides, and CTA.

3. Generate HTML and CSS using my brand config.

4. Run a script that embedded my profile photo and exported slide images.

This was a good architecture for version one. HTML is predictable, Claude is good at writing it, and the output is reproducible. If I used the same brand config, I could generate slides that felt consistent every time.

But every time I uploaded one, I had this small, uncomfortable feeling: this is useful, but it still does not look as good as I want.

The old workflow helped me stay more consistent, but it capped the design. The slides all started to share the same rhythm: big headline, body text, footer, dots. The exports were technically 1080x1350, but they looked softer after LinkedIn compressed them. And if one slide felt slightly off, I couldn’t open it like a normal design file and fix it. I had to prompt Claude again and hope it got closer to what I wanted the next time, and this is definitely not a reliable way to work.

That was the part that bothered me most.

A lot of design quality comes from tiny human edits: moving a headline two pixels left, giving one word more weight, tightening the spacing, or adding more breathing room. These are not always prompt problems. Sometimes they are taste problems.

And taste is much easier to apply when you can touch the design directly.

So I built a new Claude skill that does the job really well, and it ended up performing strongly on my LinkedIn account, especially considering I have 6,000 followers.

One of the biggest improvements in my new LinkedIn carousel skill is that it takes me from idea to an editable output, with design that is 10x better. You really notice the difference when you actually feel it.

The reframe that changed the workflow

I realized I was giving Claude the wrong final job. I was asking it to write the carousel, design the carousel, and produce the final pixels. That worked, but it trapped the result inside a flat image.

The better process is:

1. Let Claude handle the content structure.

2. Let Claude apply the brand rules.

3. Let Claude build the first version of the design.

4. Let a real design canvas render the final output.

5. Let me manually polish anything that still feels off.

That is where Paper Design comes in. Paper is a design tool that feels closer to Figma than Canva, but its MCP (Model Context Protocol) changes the workflow. Paper Desktop runs a local MCP server, and tools like Claude Code or Codex can read and write to the open design file.

To put it simply, Claude Code can create and edit designs directly inside Paper. Instead of asking Claude to generate a finished HTML file and export flat images, I can ask Claude Code to create 1080x1350 artboards inside Paper. Each slide still uses my saved brand details and carousel structure, but the visual style comes from the template I choose. The output lives on a canvas with editable layers.

The first time I ran it, I watched the slides appear one by one inside Paper, then clicked into a slide and moved a headline myself. That was the moment the workflow clicked for me. With the old skill, every small imperfection became another prompt. With Paper, every small imperfection became a small edit.

Why Paper Design instead of Figma

This is the comparison I had to take seriously because Figma is the obvious default answer. If you ask any designer where an editable carousel should live, most of them will probably say Figma. I understand why. Figma is mature, collaborative, and excellent for product design systems.

Figma’s MCP is also much stronger than I first assumed. Its use_figma tool can create and edit native Figma objects like frames, components, variants, variables, styles, text, and auto layout. If I were building product screens from an existing design system, Figma would probably be the better tool because the agent can reuse components, variables, and libraries that already exist.

But a LinkedIn carousel is a different job. I do not need Claude to search a component library and instantiate the right button variant. I need it to create strong editorial layouts, preserve my profile photo, use my brand font, keep footer alignment stable across slides, and let me polish the final design myself.

That is where Paper fits better. Paper describes itself as a real HTML and CSS canvas, and its MCP exposes tools that map almost directly to carousel production: create_artboard, write_html, duplicate_nodes, set_text_content, update_styles, get_screenshot, get_font_family_info, and get_fill_image.

That matters because Claude is already good at HTML and CSS. Paper keeps that same strength, but changes the destination. Instead of HTML becoming a flat image, HTML becomes the way Claude writes editable design objects onto the canvas.

So the workflow is simple: create a 1080x1350 artboard, write the slide into Paper, duplicate the artboard, swap the text, update styles, screenshot the result, and export at 2x. That feels close to how I would build a carousel manually, just faster.

Figma can write to canvas too, but it has more friction for this specific use case right now. Figma’s own docs currently list no asset image support yet, no custom font support yet, a 20kb output response limit per call, and Full seat requirements for agent write access. For a carousel that depends on my profile photo, custom typography, and quick visual iteration, those details matter.

That is my actual reason for choosing Paper. Figma is probably the more powerful tool overall. Paper is better aligned with the job I need done: turn my writing into editable, polished carousel slides without making me manage a full product design system.

And yes, this might change fast. Figma is moving quickly, Paper is moving quickly, and agent-to-canvas design is still early. But I do not write these Lab posts for some imaginary perfect future. I write them around what I can build and use right now.

Subscribe now

What to know before building

This workflow is better, but it is not an instant process. You need to install Paper Desktop, connect the MCP server to Claude Code, and run the skill from a folder where Claude can access your saved brand setup and profile photo.

There is also a cost to consider. As I am writing this, Paper’s free plan includes 100 MCP tool calls per week. That is enough to test the workflow, but probably not enough if you want to make this part of your regular content process.

Paper Pro is currently listed at $20 per user/month, or $16 per user/month with yearly billing. For me, that price makes sense because Paper is not only useful for LinkedIn carousels. You can use the same agent-to-canvas setup for landing pages, lead magnets, Instagram carousels, visual explainers, and other design assets that need both speed and editability.

I do not think everyone needs another monthly tool. But if Paper helps you create several reusable assets each month, the cost starts to feel reasonable compared with the time you would spend fighting design tools, prompting around tiny layout issues, or rebuilding the same visuals from scratch.

One more thing to keep in mind, sometimes Claude creates a slide that is visually close but not quite right. The heading might be too large, the accent shape might feel random, or a body slide might need tighter spacing. The difference is that these problems no longer kill the workflow. They become normal design edits.

That is the trade I am making. The old skill was faster. The new skill has a higher ceiling. For me, that is worth it.

What you get in the Lab

The goal is simple: take one strong idea from your newsletter, turn it into a carousel that looks good enough to publish, then still have full control to polish it like a real design file.

That is the outcome I wanted from the beginning. Not another AI image generator. Not another rigid template. A system where Claude gets me to a strong first draft, Paper keeps everything editable, and I can use my own taste to finish the last few details.

The other thing I added to the shareable skill is templates. The current version comes with 9 carousel templates, so you are not locked into one visual rhythm. You can use brutalist-mono for a manifesto, data-card for a stat-forward post, terminal-readme for a technical workflow, or sticky-notes for a warmer essay-style carousel.

I also included the publishing layer in the walkthrough. After the carousel is exported, I show how I use Typefully’s agent skill so Claude Code can generate the LinkedIn caption, attach the carousel file, and schedule the post.

That part requires a Typefully account, either a paid plan or their 14-day trial. But I wanted to include it because it changes the shape of the system. The workflow does not stop at “here are some nice slides.” It can go all the way from idea to editable carousel to scheduled LinkedIn post.

Inside the Lab, you get:

1. The /paper-linkedin-carousel skill I built for this workflow.

2. 9 ready-to-use carousel templates, each with its own palette and layout style.

3. Video walkthroughs showing the setup, first run, manual edits, and export flow.

4. The Paper MCP setup process for Claude Code.

5. A one-time brand setup for name, publication, positioning, profile photo, and default template.

6. Editable 1080x1350 Paper artboards instead of flat HTML exports.

7. A 2x export process for sharper LinkedIn and Instagram uploads.

8. A manual polish loop so you can fix the final details yourself.

9. A Typefully scheduling flow for turning the finished carousel into a drafted or scheduled LinkedIn post

This is not for someone who posts one carousel every few months. The old HTML skill might be enough for that. This is for you who want their ideas to travel farther on LinkedIn and Instagram without spending every post fighting layout, compression, and tiny design fixes.

Step 1: Install Paper Desktop

Download Paper Desktop from Paper’s site:

https://paper.design/downloads

Quick note: Paper MCP can work across multiple AI agents, including Claude Code CLI, Claude Code Desktop, Codex, and Cursor. In this walkthrough, I am using Claude Code CLI so the setup stays focused. If you use another agent, the Paper MCP idea is the same, but the connection screen will look different.

Open the app and create a new file. Paper’s MCP server runs locally through the desktop app, so the app needs to be open while Claude Code is working with the design.

If Claude Code cannot see Paper later, restart both Paper Desktop and Claude Code before debugging anything else.

Step 2: Connect Paper MCP to Claude Code

Follow these two steps to install Paper MCP.

First, you need to add custom marketplace:

/plugin marketplace add paper-design/agent-plugins

Then install the plugin:

/plugin install paper-desktop@paper

Just ask Claude Code to do this and you’ll be done in no time.

After installing, run:

/mcp

You should see the Paper MCP server in the available MCP list.

But later on, you’ll likely run into a problem where Claude can’t access the Paper app, even though you have it open. In these cases, open /MCP again and reconnect it to Paper Design. That’s it.

To test the connection, ask Claude Code:

“Create a red rectangle in Paper.”

If everything is connected, Paper should ask for permission and then create the shape on the canvas.

Do this tiny test before trying the carousel skill.

It saves you from debugging the wrong layer.

Step 3: Install the Paper carousel skill

Read more

I’ll be honest with you. My LinkedIn carousels don’t match my website.

Different accent color. Slightly off fonts. Spacing that’s close but not quite right. If you lined up my Substack, my LinkedIn, and my pitch deck side by side, you’d see three things that look related but aren’t the same.

It’s not that I didn’t notice. I noticed every time. The problem is that aligning everything takes real effort, and that effort kept losing to the next AI Maker post deadline.

Then Claude Design launched with one feature that caught my attention: upload your brand assets once and every project after that inherits them automatically. One folder and Claude knows your colors, your fonts, your components — forever.

The catch is that you still have to build that folder.

Claude Design does give you a few shortcuts. You can import directly from GitHub or Figma if you already have your design system living there. But most of us don’t have either. No Figma file. No organized codebase. That means you’re back to scaffolding everything yourself — pulling colors, exporting fonts, documenting components, putting it all into the structure Claude expects. Which is a lot of work.

And here’s what I realized: most of us do have the brand. We just don’t have it in a folder.

It’s already on your website. Your colors are there. Your fonts are loaded. Your components are in the navbar and the cards and the pricing section. You already made every brand decision when you built those pages.

So I built a Claude skill that extracts it. You run it inside Claude Cowork or Claude Code: point it at your URL, it reads what’s already there and generates the output folder. Then you take that folder and upload it into Claude Design during onboarding. From that point forward, every project you generate in Claude Design — LinkedIn carousels, pitch decks, Instagram carousels — comes back consistent with your website.

But I know some of you might be thinking after reading this: “I don’t have a website yet. Does that mean I can’t use this?”

No. The skill handles that too.

Here’s an example from when I ran the skill, and it asked me whether I have a website.

If you have a website, the skill extracts your brand from it. If you don’t, it runs an expanded interview instead. You tell it your colors (or name a few brands you admire and it pulls their palettes so you have something to react to), share some of your writing, and describe your visual preferences. Same output either way: a complete brand folder that Claude can use forever.

This skill will run for 10–20 minutes, but you only need to run it once, and it will apply to your future sessions indefinitely.

I called the skill Design System Builder. That’s what this post walks through.

What Claude Design actually does

If you haven’t tried it yet, here’s the quick version:

Claude Design is a feature inside Claude that generates visual assets from prompts. Landing pages, websites, app designs, carousels, pitch decks, slide decks, infographics. You describe what you want, Claude builds it. No Figma, no starting from scratch.

The way I think about it, Claude Design has four core features, and each one matters for a different part of the workflow:

1. A brand design system

This is the piece we’re talking about in this post. You give Claude your brand once and everything it generates inherits it.

2. Clean export to PDF, PPTX, and Canva

Claude is already strong at coding, so you can have it build anything in HTML first and then convert into whatever format you need. A PDF for a client, a PPTX for a sponsor deck, or a Canva file you want to tweak by hand. The format stops being a constraint.

And you can also hand off to Claude Code to start building and make it live.

3. A built-in questionnaire

Before Claude generates anything, whether it’s a pitch deck, a LinkedIn carousel, or a website layout, it asks you a batch of questions first. Who’s the audience, what’s the goal, what tone, what length. You answer once and the output comes back way more aligned than if you just typed a one-line prompt.

4. Tweak Mode

Once Claude generates a design, you can ask it to enter Tweak Mode. From there you can experiment with different color palettes, gradients, or visual styles without starting over. Select the element you want to adjust and see the change right away. It turns the output into something you can iterate on visually, not just through prompts.

That third one is easy to miss, but it’s the feature that made me stop fighting with prompts. Instead of rewriting the same brief five times, I answer six questions and let Claude drive.

It’s still in research preview, so the output quality isn’t always perfect. But the direction is clear, and it’s already useful for a lot of what I ship. I’ve hit the weekly usage limit already :)

Here’s where it falls short, though. Claude Design does have a basic brand extraction. You point it at your URL and it pulls some colors, copy, and font names. But it misses the stuff that actually matters for consistency. How your gradients work. What your spacing rhythm looks like. Your voice. Your logo variants. The hard rules that keep everything tight.

You get something close. Not something accurate.

That’s the gap the skill closes.

Subscribe now

What the skill actually builds

Before getting into how it works, it helps to know what you’re getting out of it.

The output is a folder. Not a PDF brand guide. A folder of files that Claude can read and act on directly.

At the center is one file called brand.json. Think of it as the single source of truth for your entire brand. Your exact hex colors, your fonts, your spacing, your gradient rules, your voice patterns. Everything in one place. Every other file in the folder pulls from it. If you want to change your accent color six months from now, you update one line in brand.json and it updates everywhere else automatically.

Around that file, the skill generates templates for LinkedIn carousels, Instagram carousels, slide decks, reports, and email. It also generates hard rules that Claude follows as constraints, not suggestions. Not “the site uses dark colors.” Instead: “Background is always #0D0D0D.” Not “usually use Inter.” Instead: “Always use Inter, never any other font.” That specificity is what makes the output actually consistent.

And it’s not just visual rules. The folder also carries your voice. Headline length. Tone. Phrases you actually use. Phrases to avoid. A design system without copy rules produces work that looks right but sounds wrong. This one carries both.

When this folder is in Claude’s context, every design it generates respects all of it. Same colors. Same fonts. Same voice. Without you mentioning any of it.

Here’s the part I like most. The folder also installs as its own Claude Skill. So the next time you want a LinkedIn carousel, you just invoke /{your-brand}-design, describe what you need, and it comes back on-brand.

Here’s a recent LinkedIn carousel I created by extracting my brand from my consulting website:

That’s the meta-skill part. The design-system-builder skill runs once on your website and produces a brand-specific skill that lives in your skills folder permanently. One extraction. Every future session knows who you are.

How it builds your brand (two paths)

The skill starts with one question: “Do you have a live website that represents your brand?”

Your answer determines which path it takes. Both paths produce the same output folder.

Path A: You have a website

The skill extracts your brand in two separate ways, because visual tokens and copy require completely different tools.

Track 1: Visuals via Claude for Chrome

This track captures everything you can see: hex colors as actually rendered on the page, font families and weights, gradients, border radii, shadows, spacing rhythm, logo at real resolution. For this to work accurately, the page needs to be rendered in a real browser. Claude for Chrome handles this. You run the skill in Claude CoWork, it invokes Claude for Chrome, and runs the visual extraction prompt. The skill provides that prompt verbatim; all you need to do is paste it in and run it.

Make sure you’ve installed Claude for Chrome in your browser and that you’re logged in to your Claude account.

Track 2: Copy via Tavily or WebFetch

This track captures your written brand: homepage headlines, body paragraphs, tagline, positioning, named concepts, proof numerals. Plain text that doesn’t need a browser to extract accurately. The skill runs this track in-session automatically using Tavily. You don’t need to do anything for Track 2.

Both tracks run in parallel and merge into one brand.json. While you’re opening Chrome for Track 1, the skill is already pulling your copy in the background. By the time you paste the visual results back, Track 2 is done and everything gets combined into a single source of truth.

After extraction, the skill asks 6-8 short questions about things your site can’t reveal on its own: phrases to avoid, emoji policy, gradient rules, which format you ship most often. You answer once, and the manifest is complete.

Path B: You don’t have a website

I have a feeling that many of my readers don’t have a website yet. Maybe they’re just starting out. Maybe their brand lives in their head and in their social posts, but not on a domain yet.

Instead of extracting, the skill interviews you. It runs in three stages:

Stage 1: Identity

Your brand name, positioning, who you’re for, what makes you different.

Stage 2: Visual identity

This is where it gets interesting. Instead of asking you for hex codes (most people don’t think in hex codes), the skill asks you to name 2-3 brands you admire visually. It pulls those brands’ palettes using Tavily and presents them side by side. “Here’s what I found. What resonates? What doesn’t?” Your reactions build the palette. “I like that one’s darkness but the other one’s accent color” gives the skill a concrete starting point that’s way better than guessing.

You also describe your preferences: dark or light canvas, sharp corners or rounded, serif or sans-serif, gradient or no gradient.

Stage 3: Voice and rules

You share 3 headlines from your own writing (newsletter, social posts, emails, anything) and a paragraph or two. The skill analyzes your patterns and builds voice rules from them. Then the standard questions: banned phrases, emoji policy, proof numeral style, priority format.

The whole interview takes about 15 minutes. After that, the skill has enough to fill the same brand.json manifest and scaffold the same folder. The output is identical. A brand built from interview is not a lesser brand. If anything, it forces you to be more intentional about choices that website creators sometimes make by accident.

The principles that make this work

To be honest, I didn’t get all of these right the first time. Most of them got added after the skill produced something that looked correct but then fell apart in the next session. These are the rules that stuck after testing:

1. Be specific, not vague. This is the biggest one. If you tell Claude “usually use Inter for headings,” it forgets within a few sessions. If you tell Claude “always use Inter for headings, never use any other font,” it sticks. The skill builds these kinds of hard rules into every brand folder it generates. No “usually.” No “try to.” Just clear yes-or-no instructions that Claude can follow every time.

2. Voice matters as much as visuals. I had an early version that nailed the colors and fonts but completely ignored how I write. The carousels looked like my brand but sounded like someone else. A brand system has to carry both. How your headlines sound, what phrases you avoid, your tone. Otherwise you get visually correct work in the wrong voice.

3. Fill everything with real content. No “[INSERT HEADLINE HERE]” placeholders anywhere. Every slot in every template gets filled with your actual words during setup. I learned this one the hard way: if you leave placeholder text in the templates, Claude keeps producing placeholder-style output in future sessions. It picks up the pattern.

4. Keep fonts local. The skill downloads your font files and stores them inside the folder instead of loading them from the internet every time. External font sources can fail without warning, and then your whole design breaks silently. Local copies just work.

5. One file controls everything. All your brand decisions live in a single file called brand.json. Every template in the folder pulls from that one file. If you want to change your accent color six months from now, you change it in one place and it updates everywhere. Without this, you’d be hunting through dozens of files to find every place a color was hardcoded.

6. Each format gets its own layout. A LinkedIn carousel is 1080x1350 portrait. An Instagram carousel is 1080x1080 square. A pitch deck is 1920x1080 landscape. These are completely different shapes, and they need completely different layouts. The skill builds each one from scratch instead of shrinking a landscape slide to fit a portrait frame. That shortcut is what produces those awkward carousels with too much empty space in the middle.

These six rules are what separate a brand folder that works once from one that holds up over months of use. I learned most of them by watching the output break and figuring out why.

That said, there are real limitations here. I’d rather you know them going in than discover them halfway through.

Honest limitations

• Claude for Chrome is the one step you can’t skip. I listed it in the prerequisites for a reason. Without it, the skill falls back to text-based guessing and you lose the whole point of accurate extraction.

• You’ll probably need to provide some assets yourself. The skill pulls what it can from your website, but if your logo isn’t on the page, or you have a wordmark or icon variant that only lives on your hard drive, Claude can’t find it. You’ll need to drop those files into the assets folder manually after the skill runs. Same goes for any brand elements that aren’t publicly visible on your site.

• This isn’t a one-shot process. I want to be transparent about that. The skill does a lot of the heavy lifting, but expect to go back and forth with Claude a few times. Maybe the colors are right but the voice rules need adjusting. Maybe the carousel layout needs another pass. You’re having a conversation with Claude until the output matches what you want. Think of it more like a working session than a magic button.

• Sites with inconsistent design produce inconsistent extractions. If your brand has drifted over time and your homepage doesn’t match your about page, the skill will pick up on that inconsistency. Review brand.json after extraction and clean up anything that looks off before you upload.

• Claude Design is still in research preview, as I mentioned. Output quality varies by complexity. Simple carousels and decks come out well. More complex layouts can be hit or miss.

• The brand kit is a snapshot. If you redesign your site later, you’ll want to re-run the skill to pick up the changes.

• I’m still refining this. I’ve re-run the skill on my own site twice already to improve what the portrait carousel layout produces. It keeps getting better, but I’m not going to pretend it’s perfect yet.

None of these are dealbreakers. They’re just the honest reality of where the skill is right now. I’d rather ship something that works with known rough edges than wait for perfect.

How the skill runs (four phases)

Read more