How to Set Up a Recurring Task in Claude Cowork
Every Saturday, Monday, and Wednesday at 8 in the morning, a session wakes up on its own, reads through this blog’s back catalog so it doesn’t repeat itself, brainstorms five new post ideas, writes them into a log file, and drops a reminder in a Gmail draft that a post is due the next day. Nobody opens a chat window to ask for any of it. That’s the post you’re reading the reminder for right now, and it’s also the cleanest example I’ve got of what a scheduled task actually does once you stop thinking of Cowork as something you have to show up and talk to.
The difference between a skill and a schedule
A skill, the kind covered in the last tutorial, runs when you ask for it. You type a name, or your request matches its description, and it fires. That’s still you initiating things, just with less typing.
A scheduled task skips the asking part entirely. You set a time and a recurrence, hand over a self-contained set of instructions, and Cowork runs the whole thing on a timer without you in the loop at all. The output shows up whether or not you remembered the task existed that day. That’s a meaningfully different kind of delegation: not “do this when I say so” but “do this on your own, and I’ll check the result later.”
When it’s worth doing
The signal here is regularity plus a task you’d rather see finished than be asked to start. If something happens on a predictable cadence, daily standup notes, a weekly numbers pull, a reminder that recurs on specific days, and the value is in having it already done rather than in you personally kicking it off, that’s a scheduled task. If it’s a one-off or the timing is unpredictable, just ask normally.
The blog reminder fits both conditions. Posts go up Sunday, Tuesday, and Thursday, so the ideas need to exist by Saturday, Monday, and Wednesday morning. Nobody’s watching a calendar to remember that pattern. Cowork is.
Building one
Start from a real session, not a blank request. The way this task came to exist was by doing the work manually first, in chat, a few times, then noticing it was the same job every time: check the folder, read what’s already there, come up with five ideas, log them. Once that pattern was clear, it got turned into a standing task instead of getting retyped every few days.
Write the prompt like nobody’s in the room. This is the part that trips people up. A scheduled run has no memory of the conversation where you set it up. It can’t see “the folder we were just talking about.” Every instruction has to be self-contained: exact file paths, what to read before writing anything, what counts as done. The blog task’s instructions spell out the full path to the ideas log, name the voice file to read before drafting anything Lansing will actually see, and say explicitly not to send the email, only draft it, because there’s no undo on a sent message.
Give it a name you’d recognize later. This one’s called blog-ideas-and-reminder, kebab-case, descriptive enough that six weeks from now the name alone tells you what it does without opening the file.
Set the schedule. This is where the cron expression comes in, and it looks more intimidating than it is. Five fields, in order: minute, hour, day of month, month, day of week. The blog task’s expression is:
0 8 * * 6,1,3
Minute 0, hour 8, so 8:00 AM. The two asterisks mean any day of the month, any month, no restriction there. The last field, 6,1,3, is the day of week, and cron counts Sunday as 0, so 6 is Saturday, 1 is Monday, 3 is Wednesday. Read the whole thing left to right and it says exactly what it’s supposed to: 8:00 AM, Saturday, Monday, and Wednesday. Cowork also adds a small random jitter, a few extra minutes on top of the set time, so a fleet of tasks scheduled for the same moment doesn’t all fire in the same second.
Confirm before it goes live. If the schedule wasn’t stated plainly up front, Cowork should propose one and get it confirmed rather than guessing and hoping the guess was right. A wrong cron expression is an easy mistake to make and an annoying one to catch after the fact, so it’s worth a second look before the task starts running unattended.
What changes once it’s running
Because nobody’s present for an autonomous run, the instructions have to account for that. The blog task is explicit: execute without asking clarifying questions, make reasonable calls, note them in the output. Only take a “write” action, like the Gmail draft, if the instructions specifically call for it. Everything else, updating records, sending anything final, stays out of scope unless it’s spelled out in advance. That’s the same boundary the trust ladder post covers for any autonomous action: reversible steps get the green light on their own, the ones you can’t take back wait for a human.
Changing a task after it’s already running
The Gmail draft step wasn’t part of the original task. It got added later, as a specific experiment, with a note in the instructions that it should come back out if it turns out not to be useful. That’s the normal way these evolve: you don’t rebuild a scheduled task from scratch to change one step, you update the existing one. The tell for when to update instead of starting over is right there in the setup: if a task with this name already exists, you’re editing it, not making a second one that does almost the same thing.
Why this is worth setting up at all
The whole point of a scheduled task is that the version of you who’d remember to ask for this on the right morning doesn’t have to exist. The task remembers instead. That’s a small thing for a blog reminder and a much bigger thing once you start noticing how many parts of a week run on the same kind of pattern: not “ask when you think of it,” but “show up already done.”
