Share Card: Save Scheduled Tasks Locally
Date created: 2026-04-06
Shared with: Robot Assistant Field Guide course
PHI/PI scan: Robot passed / Cameron reviewed
What This Does
Right now, your scheduled tasks live on the MCP — your robot assistant can create and update them, but it can’t read them back. That means every time you want to tweak a task, you’re working blind.
This share card fixes that by saving a local copy of every scheduled task as a .md file in your workspace. Even better, it keeps the task files dead simple (“thin wrappers”) by putting all the real procedure logic in your skill files — the same skill files you already know how to edit from the course. The task just says when to run and which skill to use.
This makes scheduled tasks work the same way as everything else in your robot assistant: you edit a local file, your robot reads it, and you stay in control.
Human Notes
What you need to know to set this up. Your robot assistant will do the heavy lifting — your job is to give it the right inputs and review the results.
What it solves
Two problems:
-
Your robot can’t read your tasks, only you can. The scheduling MCP is write-only from your robot’s perspective — it can create and update tasks but can’t read them back. Without local copies, the robot has no way to review or edit what your tasks actually do.
-
Instructions drift. When a scheduled task runs a procedure, the instructions for that procedure can end up in two places — the task and the skill file. Over time they drift apart. You edit one and forget the other. The scheduled task runs stale instructions at 2 AM and you don’t notice until something breaks. By keeping all the logic in your skill files (which you’re already comfortable editing), there’s only one place to update.
Prerequisites
A robot assistant with both skills (procedure files) and scheduled tasks. Works with any scheduling MCP — the pattern is about file organization, not a specific tool.
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:
-
Tell your robot to create a
Scheduled Tasks/folder in your workspace (or whatever name you prefer). -
Copy each scheduled task’s prompt manually. This is the one part your robot can’t do for you — it can’t read tasks from the MCP. Go into each scheduled task’s settings, copy the full prompt text, and paste it somewhere your robot can access it (a file, a Drafts note, or just paste it into the chat). Your robot will take it from there.
-
Ask your robot to create a matching skill file for each task that has real procedure logic in it. If you already have a skill file for that task, ask your robot to move any logic from the task prompt into the skill file. For simple tasks (like “check a webpage for changes”), skip this — they can stay self-contained.
-
Ask your robot to slim down each task file to just: task ID, schedule, a short summary, and a pointer to the skill file (e.g., “Source of truth:
Skills/your-skill.md”). -
Ask your robot to add a “Thin Wrapper Pattern” section to your CLAUDE.md with these rules:
- When editing a skill, check
Scheduled Tasks/for any tasks that reference it. - When editing a task, don’t add procedure logic — put it in the skill file instead.
- When renaming a skill, check both
Scheduled Tasks/and your skill index for stale references.
- When editing a skill, check
-
Ask your robot to update your skill index 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.
- The MCP task still needs one update. Your local
.mdfile is your readable copy, but the actual prompt lives on the MCP. You may need to update the MCP prompt once so it tells the assistant to read the skill file — then you’re done. Future edits go in the skill file only.
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 make this easy to catch on review.
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 you have one) — should note which skills have associated scheduled tasks.
What to add to CLAUDE.md
Add a “Scheduled Tasks” section that includes:
-
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.” -
Thin Wrapper Pattern rules:
- When editing a skill: Check
Scheduled Tasks/for any tasks that reference that skill. The task summary may 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 task should only change if the schedule, setup, or summary changes.
- When renaming or restructuring a skill: Check both
Scheduled Tasks/and the skill index for stale references. - Exception: Very simple tasks that don’t have a corresponding skill can keep their logic inline.
- When editing a skill: Check
-
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.
Task file format
Each thin wrapper task file should include:
- Task ID and schedule (with cron expression)
- 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 skill
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.