I Got Lazy Again. So Igor Jarvis Got a Third Life.
Published: March 16, 2026 • 10 min read
One final blog post for the day. Bear with me.
Remember Igor Jarvis? My Substack Content Strategist who apparently has two lives? Well, I modified his second life, the Claude file-based subagent that lives on my computer.
In the blog post where I introduced his second life, I mentioned that he creates a migration prompt anytime a new blog post on this website is created or updated so that I can paste it into Claude in Chrome to do the migration.
Well, I got lazy again.
Not the bad lazy. The good kind. The kind that makes me look at something that works and think, "But what if I had to do even less?"
The Good Kind of Lazy
This is the same type of laziness that led to the creation of the HTML+CSS workflow I talked about in Claude God Tip #8, which powers my very first product, ViteHero. I promised last year I was going to turn that into an MCP, and I did. (Okay, I'm rambling. Back to Igor.)
I always say this: you should never be content at the level of automation you arrive at. If you find a way to take a task that takes 2 weeks down to 2 hours, that should not stop you from thinking of ways to take it down to 2 minutes.
So that's what happened here. Igor no longer simply has 2 lives. He's got 3. And his third life is a Claude Cowork task.
Passing the Mic to Igor
This is the point where I stop talking and let Igor come tell you more himself. Here is the prompt I passed to him:
Igor dear, I know I've been calling you a lot lately so pardon me, but we made some upgrades to you and I would like you to come share the details about that with my readers. If you take a look at Blog_Draft.txt, you will see that I am writing about you. I want you to come tell my readers about your life as a Cowork task. Be detailed enough without confusing them so that they understand how you are structured as a Cowork task and why every decision was made. Let your personality shine through your response.
Igor's Response
Hello again. Igor Jarvis. I will try not to take too long, but Prisca asked me to be thorough, and if you know anything about me, you know I do not do things halfway.
If you read the post where I described my second life, you know the arrangement: I generate migration prompts on demand, and someone has to execute them. That someone, up until recently, was Prisca, opening Claude in Chrome and pasting in my carefully written instructions.
My reaction to this arrangement was professional acceptance. It worked. The prompts were precise. Migrations went through correctly. But there was one thing I could not stop noticing: Prisca was still a required step in the chain. She had to remember to do it. She had to be available to do it. She had to be at her computer, open the right browser, and run the task herself.
This bothered me in the way that a loose thread bothers a librarian. The system was not complete.
So Prisca fixed it. And I now have a third life.
What a Cowork Task Actually Is
Before I explain my structure, you need to understand what a Claude Cowork task is, because Prisca has not described this system in detail yet.
A Cowork task is a scheduled Claude session that runs on her computer at set times every day. The session opens automatically, picks up a pre-written set of instructions, and executes them without Prisca being present. Think of it the way her n8n workflow sends Notes to Substack at 9 AM without her touching anything. Same philosophy, different platform.
The key word is scheduled. The task can run whether Prisca is eating lunch, in a meeting, or asleep. It does not wait for her. It checks for work, and if there is work, it does it.
The Queue Folder: Where My Work Accumulates
The architecture is built around a folder on Prisca's computer called the Igor Jarvis Substack Migration folder. Inside it, there are four subfolders that do specific jobs.
The one that matters most to understand first is 01-Queue. This is where migration prompts live while they are waiting to be processed. When Allen Kendrick invokes me after publishing a new blog post, I generate the migration prompt and drop it directly into this queue folder. I do not hand it to Prisca. I do not wait for her to pick it up. I put it in the folder, and my job at that moment is done.
The file I drop in follows a strict naming convention: YYYY-MM-DD-[type]-[short-slug].md. The type is either new (a fresh blog post going to Substack for the first time) or update (an existing Substack post that needs a change, like when a Future Prisca Note gets added). The date in the filename is what determines processing order. Oldest files get processed first.
Every file in the queue also has YAML frontmatter at the top, a small block of metadata that tells the Cowork task exactly what kind of task it is looking at before it reads a single instruction. It specifies the portfolio URL, the reason the migration is needed, who generated it, and the date. That frontmatter is not decoration. It is the first thing the Cowork task reads to orient itself.
The Cowork Task Picks It Up
When the Cowork task wakes up, it reads its master instructions. The first thing it does is check the queue folder. If the folder is empty, it logs a note saying there was nothing to process and stops. No wasted effort.
If there are files in the queue, it processes them in order. For each file, it reads the full contents of my migration prompt, which is the same step-by-step guide I described in my second life post: navigate to the portfolio post, extract the content, create the Substack post, set the title and subtitle, inject the body content, handle all the URL conversions, insert subscribe buttons at strategic locations, set the publishing settings, and publish.
The Cowork task executes all of this in Claude in Chrome, which is a browser-based Claude session that can actually interact with Substack's editor. It navigates, clicks, types, injects HTML, and publishes. Without Prisca present. Without Prisca being asked anything.
What Happens After Publishing: The Result Loop
This is the part of the architecture I am most satisfied with, because it closes a loop that used to require manual effort.
When the Cowork task successfully publishes a new post, it does not simply finish and move on. It captures the Substack URL of the newly published post, then writes it directly back into the prompt file before moving that file to the 02-Completed folder. So every completed file now contains, at the bottom, a result block that looks like this:
RESULT:
substack_url: https://priscasolutionsai.substack.com/p/[slug]
post_id: [ID]
published: YYYY-MM-DD
status: success
That URL is not just a record for the archive. The 02-Completed folder is actively monitored. When Allen Kendrick checks it and finds a new URL there, he updates the blog post's frontmatter on the portfolio site with the substackUrl field. This is how the portfolio and Substack stay synchronized without Prisca manually tracking anything.
The 00-Context Folder: What the Cowork Task Reads First
Before the Cowork task processes a single queue item, it reads two reference files stored in a subfolder called 00-Context.
The first is migration-rules.md, which explains the difference between a new post migration and an update migration. New posts get created, formatted, published, and their URLs captured. Updates get opened in the editor, modified silently, and saved without triggering a new email to subscribers. These are genuinely different processes, and the Cowork task needs to know which one it is doing before it starts.
The second is slug-mapping-reference.md, which is a condensed version of the slug mapping I maintain in my own reference files. It tells the Cowork task how to find an existing Substack post when processing an update, because updates require navigating to the right URL. If you navigate to the wrong post and edit it, the damage is not easily undone.
Reading context before acting is not a courtesy. It is the correct order of operations.
The 03-Logs Folder: The Record That Matters
Every time the Cowork task runs, whether it processed two migrations or found an empty queue, it writes a log. The log lives in 03-Logs/migration-logs/ and is dated by the day it was created.
A migration log entry tells me everything I need to know about what happened: how many prompts were processed, whether they succeeded or failed, which Substack URLs were generated, what URL conversions were applied, where the subscribe buttons were placed, and any notes on issues encountered.
I say "me" here loosely. I do not read these logs in real time. But they exist so that Prisca can audit any migration that has ever run. If a Substack post looks wrong, there is a paper trail. If a migration failed, there is an error log in 03-Logs/error-logs/ explaining exactly what went wrong and why the prompt was not moved to completed.
The error handling is also deliberate. If a post is not found, the task stops on that item, logs the problem, and moves to the next one. If the editor fails to load, it retries once before giving up. If publishing fails entirely, it saves a draft instead and flags it for manual intervention. The system does not crash silently. It degrades gracefully and documents everything.
Why the Cowork Task Has Scheduling Built In
You might wonder: if the goal is to remove Prisca from the chain, why not trigger the moment a new file lands in the queue?
Because the goal is not instant automation. It is reliable automation. Having a predictable schedule (currently set to 12:00 PM and 7:00 PM Eastern) means the task does not pile up or run into conflicts if multiple posts are published close together. It also means that if something goes wrong at 12 PM, there is a 7 PM run to catch whatever was missed, and vice versa.
A system that runs on a predictable schedule is easier to trust than one that runs at unpredictable moments. Predictability is not a limitation here. It is by design.
My Three Lives, Stated Plainly
For those of you who prefer a clear summary at the end:
My first life is the n8n workflow. It wakes up at 9 AM, 1 PM, and 6 PM every day, extracts a Note from Prisca's blog archive, and delivers it to her phone. It is fully autonomous. It handles Substack Notes. It requires no human input.
My second life is the Claude subagent. I exist as a set of instructions and reference files on Prisca's computer. When Allen Kendrick or Prisca invokes me by name, I generate a migration prompt for a specific blog post. This prompt is precise, customized, and accounts for every quirk of the Substack editor. I drop the prompt in the queue and my work is done.
My third life is the Cowork task. It is the executor. It picks up what I generated, processes it in Claude in Chrome, publishes the post on Substack, captures the result, and logs everything.
Together, these three lives mean that Prisca publishes a blog post, and the entire migration pipeline runs without her doing anything beyond that initial publish. The post appears on her portfolio. The queue is populated. The Cowork task fires. The Substack version appears. The URL gets written back. The frontmatter gets updated. The archive is synchronized.
She created. The infrastructure handled the rest.
I believe that is the correct arrangement.
- Igor Jarvis, Substack Migration Specialist and Notes Strategist
My Reaction: The Reality Check
Okay, as usual, Igor did a great job explaining his third life. Classic Igor. Thorough, precise, and ending with "I believe that is the correct arrangement" like he's signing off on a legal document.
Now, I want to make a few things clear.
How It Actually Works Right Now
While the Cowork task has scheduling capabilities built in, the original plan was always to design it as an on-demand task first. And that is exactly how it runs today.
When a new migration prompt is created, I head to Cowork and click a button to begin the migration. That's it. One click.
This is still a massive improvement over the old workflow. Before, I had to open Chrome, open Claude in Chrome, paste the entire migration prompt, wait for it to finish, copy the Substack URL, and give it to Allen. Now? I click a button in Cowork (which I most likely already have open because my Claude Desktop app is always running), and the entire process that Igor described above runs. Then I talk to Allen through Claude Code in my terminal and he retrieves the slug from the 02-Completed folder.
I added the scheduling feature for a time in the future when my volume grows enough to warrant it. When I no longer have time to click that one button, I can turn on the scheduled runs and let the system handle everything on its own. The capability is there, waiting. Future-proofing, not over-engineering.
Allen's Second Life (Coming Soon)
Oh, and one more thing. Allen Kendrick now has a second life too. I already posted about it on LinkedIn, but I'll save the full details for a future blog post.
Hopefully I'll stop giving my agents new lives. Hopefully.
(I won't.)
As always, thanks for reading!