Save scheduled tasks locally, so your robot can update them just like it does skills

Robot Assistant
1

Share Card: Save Scheduled Tasks Locally

Version: 2.0
Date created: 2026-04-06
Date updated: 2026-05-04
Author: Cameron Bales - cameron.bales@telus.com
Works in: Claude Cowork
Shared with: Robot Assistant Field Guide course
PHI/PI scan: Robot passed / Cameron reviewed

What This Does

Your scheduled tasks live on the server — and as of recently, your robot assistant can read and edit them directly via the scheduling MCP. That’s a big improvement over the early days when the MCP was write-only. But the server-side prompt is still just a blob of text sitting behind an API call. You can’t browse it in your vault, you can’t diff it, and you can’t spot problems at a glance.

This share card sets up two things: local copies of every scheduled task as .md files in your workspace (so you can see them alongside your skills), and a thin wrapper pattern that keeps all real procedure logic in your skill files — the same skill files you already know how to edit. The server-side task prompt just says when to run and which skill to read. Your robot can now bootstrap this entire setup for you automatically.

What It Solves

Three problems:

  1. Server-side prompts are invisible in your vault. Your robot can read tasks via the MCP now, but you still can’t see them in Obsidian, search them, or browse them alongside your skills. Local copies fix that — they’re regular .md files in your workspace.
  2. Instructions drift. When a scheduled task runs a procedure, the instructions can end up in two places — the server-side task prompt and the skill file. Over time they drift apart. You edit one and forget the other. The task runs stale instructions at 2 AM and you don’t notice until something breaks. The thin wrapper pattern eliminates this by keeping all logic in one place: the skill file.
  3. Fake thin wrappers. Sometimes a task looks like a thin wrapper — the local copy says “read the skill and follow it” — but the server-side prompt actually has a full inline procedure that was never converted. Your robot can now audit for this by reading the server-side prompt directly and comparing it to the local copy.

What’s New in v2.0

Version 1.0 was built around a key limitation: the scheduling MCP was write-only, so your robot couldn’t read tasks back. That’s no longer true. The MCP now supports:

  • Listing tasks — returns each task’s ID, schedule, last/next run times, and a file path to the server-side prompt.
  • Reading server-side prompts — your robot can read the prompt file directly using the path from the list.
  • Editing tasks — your robot can update the prompt, description, schedule, and enabled status.
  • Creating tasks — Cowork also has a built-in schedule skill for creating new tasks interactively.

This means the setup process is now fully automated (no more manual copy-pasting), and your robot can audit its own tasks for drift and fake thin wrappers.

Human Notes

What you need to know to set this up. Your robot assistant will do the heavy lifting — your job is to review the results.

Prerequisites

A robot assistant with both skills (procedure files) and scheduled tasks in Claude Cowork. The scheduling MCP tools (list_scheduled_tasks, update_scheduled_task, create_scheduled_task) must be available in your session.

How to implement this

Drop this file somewhere in your robot assistant workspace and ask your robot to read it. Then walk through these steps together:

  1. Tell your robot to create a Scheduled Tasks/ folder in your workspace (or whatever name you prefer — some people use ZZZinternal/Scheduled Tasks/ to keep it out of the way).
  2. Ask your robot to list all your scheduled tasks and create local copies. Your robot can now do this entirely on its own — it’ll call the scheduling MCP to list your tasks, read each server-side prompt, and save a local .md file for each one. No manual copy-pasting needed.
  3. Ask your robot to audit each task for inline logic. For any task that has real procedure logic baked into the server-side prompt (rather than pointing to a skill file), ask your robot to move that logic into a skill file. If you already have a skill file for that task, it should merge the logic there. For simple tasks (like “check a webpage for changes”), skip this — they can stay self-contained.
  4. Ask your robot to convert the server-side prompts to thin wrappers. Once the logic is in the skill files, your robot should update each server-side prompt (via update_scheduled_task) to just say “read the skill file and follow it.” This is the key step — now edits go in the skill file only, and the server-side prompt never needs to change again.
  5. Ask your robot to add a “Scheduled Tasks” section to your CLAUDE.md (or equivalent config file) with the Thin Wrapper Pattern rules and a task list. See the Robot Notes section below for the exact text.
  6. Ask your robot to update your skill index (if you have one, or any equivalent reference list) so each skill that has a scheduled task notes which task it’s connected to.

What you’ll need to customize

The file paths and folder names. The key is the pattern, not the specific layout.

Gotchas

  • Don’t forget the reverse lookup. The big win is the rule that says “when you edit a skill, check if any scheduled tasks reference it.” Without that, you’ll still get drift — just in the other direction.
  • Keep an exception for simple tasks. If a task is 10 lines and self-contained, forcing it through a skill file just adds indirection for no benefit.
  • Ghost skills can haunt you. Cowork-created skills have metadata that lives server-side. If you delete a skill’s files locally, the server-side record can survive and the skill keeps reappearing. The fix is to delete via https://claude.ai/customize/skills (the web-based skill manager), not by deleting local files. The same principle applies to scheduled task prompts — the server-side prompt is what actually runs, and your local copy is just documentation. Always update both.
  • The Cowork schedule skill exists. Cowork has a built-in skill (in .claude/skills/schedule/) for creating new scheduled tasks interactively. It’s handy for the initial creation — just make sure you follow the thin wrapper pattern when using it, and create a local copy afterward.

Known limitations

  • This only prevents drift for logic changes. If a skill’s scope changes significantly (e.g., it now needs a new MCP connector), you still need to check whether the task’s summary is misleading.
  • The pattern relies on the assistant reading and following CLAUDE.md. If context gets compacted or the assistant skips the rules, it might add inline logic to a task. The local copies and the audit checklist (below) make this easy to catch.
  • The scheduling MCP tool names may vary across Cowork versions. The tools referenced here (list_scheduled_tasks, update_scheduled_task, create_scheduled_task) are current as of May 2026.

Maintenance checklist

Once you’re set up, run this audit periodically (quarterly is fine, or whenever you’ve been editing tasks heavily). You can ask your robot to do all of this:

  1. List all tasks via MCP and compare against local copies. Flag any tasks that don’t have a local copy, or local copies that don’t match a real task.
  2. Read each server-side prompt and verify it’s actually a thin wrapper — not a full inline procedure pretending to be one.
  3. Check each thin wrapper’s skill pointer — does the skill file it references still exist? Has it been renamed or moved?
  4. Update the “Last synced” date on each local copy that passes the audit.

After setup

Once you’ve worked through the setup with your robot, you can delete this file — everything it teaches will be in your CLAUDE.md and skill files by then.

Robot Notes

What an AI assistant needs to know to implement and maintain this pattern. When the human asks you to set this up, follow the Human Notes steps above — they’ll walk you through it together.

File structure

  • Scheduled Tasks/*.md — local copies of each scheduled task. Thin wrappers only: ID, schedule, summary, and a “Source of truth” pointer to the skill file.
  • Skills/*.md — where all procedure logic lives. The skill file is the single source of truth for how the task runs.
  • CLAUDE.md — should contain a Scheduled Tasks section with the rules below.
  • Skill index (if the workspace has one) — should note which skills have associated scheduled tasks.

Reading and editing task prompts via MCP

The scheduling MCP provides these tools for working with existing tasks:

  • list_scheduled_tasks — returns each task’s id, schedule, lastRunAt, nextRunAt, and a path to its server-side prompt file (usually named SKILL.md on the server). This is your entry point for auditing.
  • Read the path — use your file-reading tool on the path returned by list_scheduled_tasks to see the actual prompt that runs. This is the real source of truth for what the task does, not the local copy.
  • update_scheduled_task — edits the server-side prompt, description, schedule, enabled status, etc. Use this to convert inline prompts to thin wrappers.
  • create_scheduled_task — creates a new task. Default to the thin wrapper pattern when using this.

Important: The local copy in Scheduled Tasks/ is documentation. The server-side prompt is what actually executes. When auditing, always read the server-side prompt directly — don’t trust the local copy to be current.

What to add to CLAUDE.md

Add a “Scheduled Tasks” section that includes:

  1. Local copy rule: “Local copies of all scheduled task prompts are in Scheduled Tasks/. When updating a scheduled task via the MCP, always update the local copy too. When renaming files, check this folder for stale references.”
  2. Reading and editing tasks: “Scheduled task prompts can be read and edited from inside a session via the scheduling MCP. Use list_scheduled_tasks to get each task’s path, read the path to see the server-side prompt, and use update_scheduled_task to edit it. The server-side prompt is the source of truth for what actually runs — the local copy is documentation.”
  3. Thin Wrapper Pattern rules:
  • Scheduled tasks should be thin wrappers — the server-side prompt says “read the skill and follow it,” and all procedure logic lives in the skill file.
  • When editing a skill: No need to push anything — the next scheduled run picks up the change automatically. Check Scheduled Tasks/ for any local-copy summaries that need updating if the skill’s scope changed.
  • When editing a task: If you’re adding procedure logic, stop — put it in the skill file instead. The server-side prompt should only change if the schedule, setup, or thin-wrapper text changes.
  • When renaming or restructuring a skill: Check Scheduled Tasks/, the skill index, and any server-side task prompts that reference the skill path.
  • Watch for fake thin wrappers: the local copy says “thin wrapper” but the server-side prompt is actually a full inline procedure. Fix: update the server-side prompt to a real thin wrapper.
  • Exception: Very simple tasks that don’t have a corresponding skill can keep their logic inline.
  1. Task list: A bulleted list of each task with its schedule, what it does, and which skill file it points to. Example:
  • daily-briefing.md — Daily 8:00 AM. Morning briefing. Thin wrapper → Skills/daily-briefing.md.

If the workspace doesn’t have a CLAUDE.md yet, suggest creating one with at least this Scheduled Tasks section as a starting point.

Task file format

Each thin wrapper task file should include:

  • Task ID and schedule (with cron expression if available)
  • A “How it works” note explaining it’s a thin wrapper
  • A “Source of truth” pointer to the skill file(s)
  • A “What it does” summary (short numbered list)
  • A “Last synced” date so you can tell when it was last verified against the server-side prompt

Auditing for fake thin wrappers

When setting up or auditing, read each server-side prompt (via the path from list_scheduled_tasks) and check whether it’s actually a thin wrapper. A real thin wrapper is a few lines saying “read [skill file] and follow it.” A fake thin wrapper has a full inline procedure — sometimes because someone created the task with inline content and never converted it. Fix: move the logic to a skill file, then update the server-side prompt to point to it.

Ghost skill warning

Cowork-created skills have server-side metadata. Deleting skill files locally doesn’t remove the server record — the skill keeps reappearing. The fix is to delete via https://claude.ai/customize/skills (web-based skill manager). The same principle applies here: scheduled task prompts live server-side. Your local .md file is a convenience copy. Always treat the server-side prompt as authoritative, and use the MCP tools to make changes stick.

Prompt notes

  • The dependency rules are bidirectional — that’s the key. “Skill changed → check tasks” AND “task changed → put logic in skill.”
  • The exception clause for simple inline tasks prevents over-engineering.
  • When creating new tasks, default to the thin wrapper pattern. Only keep logic inline if the task is very simple and self-contained.
  • Cowork has a built-in schedule skill (typically at .claude/skills/schedule/) for creating tasks interactively. When using it, follow the thin wrapper pattern and create a local copy afterward.
3 Likes
2

.md files are not allowed to be attached to posts in this system.

You will need to copy all that parent comment and save to a .md file in your robot assistant folder, then follow the instructions. It might work if you just pasted it into a prompt.

I’m looking for feedback on sharing this way. Please tell me:

  • If you tried to install this, and it worked/ didn’t work
  • Have you seen this limitation in updating tasks before you saw this solution
  • Were the instructions clear for you as a human
  • Did your robot assistant have any problems working through the process with you
2 Likes
3

So, how does it know when to run scheduled tasks?

4

It says it uses Cron to do it. Basically when you set up a scheduled task, it asks what you want it to do, and when to do it. My usual pattern is build a skill, run it a couple of times, then set it up a scheduled task to run that skill. David covers this in detail in the course.

1 Like
5

Love this way of sharing. Thank you so much @Cbales
I haven’t tried it out yet but enjoy reading your post from my indoor spinning bike😅

1 Like
6

I updated this to Version 2 now that Claude can do a lot of the scheduled task reading and editing. This is still a useful thing to do with your scheduled tasks.