To turn an AI skill into a scheduled workflow, choose an application that can run it on a schedule. Then define when it starts, which inputs count as current, where its output goes and who checks it. The skill supplies the method; the application starts each run.
The skill describes the work; the scheduler starts it
In the Agent Skills format, a skill is a folder containing a SKILL.md instruction file and optional supporting material. The file describes how to do the work. An app or service supplies the scheduler and the environment that executes the instructions, called the runtime. Writing “every Monday” inside the file does not itself establish a recurring run. Agent Skills specification; Claude scheduling documentation.
Check where the scheduled run actually happens
Platform note, checked 19 October 2026: Anthropic documents scheduled tasks on paid Claude plans, with access to skills and installed plugins. Its current documentation describes remote execution, including when the desktop app is closed. Tasks requiring local files or apps run locally; some older Pro and Max schedules also remain local. Team and Enterprise access depends on administrator settings. Claude scheduled tasks.
Local file, browser and computer access requires Claude Desktop on macOS or Windows to be open and connected. Plugins containing local MCP servers are desktop-only. Check the account's rollout and access settings before relying on a schedule. These requirements belong to Claude; another workspace needs its own compatibility check. Claude requirements and limitations.
Illustration: a Monday briefing with a defined handoff
Consider an invented project-delivery team. Its operations lead wants a briefing for the Monday meeting: overdue commitments, deliveries due this week and unresolved customer issues. The proposed skill specifies how to reconcile the records, link each finding to its source and identify missing owners. This is a design illustration, not a record of a completed run.
Schedule preparation for Monday at 8 a.m. in America/Los_Angeles. Specify that the meeting follows local time through daylight-saving changes, then verify the scheduler's displayed next run. Define last week's reporting period as the previous Monday at midnight through this Monday at midnight, in that same timezone.
Require a project-register export and customer-issue summary refreshed after 7:30 a.m. Monday. Name their locations and check both export timestamps and the period the records cover. If either is missing or stale, the instructions should flag the gap and mark the briefing incomplete. A recent download of old records does not meet this requirement.
Choose the operations review folder as the destination, subject to verified write access. Name the draft by the meeting date. The operations lead reviews it before the 9 a.m. meeting, confirms disputed commitments with their owners and distributes the approved version. The scheduled job's responsibility ends at preparing the draft and its review notes.
Approve actions according to their consequences
Decide which steps have standing authorization and which require a fresh decision. Preparing a draft from approved inputs can have standing authorization. Changing a delivery commitment, adding recipients or sending externally should follow the business's approval rules. Write the conditions into the skill and configure corresponding tool permissions. If the app cannot enforce the required boundary, keep that action manual. Cowork's approval behavior depends on its mode, connector permissions and organization settings. Claude approval controls.
A scheduled run can encounter new documents or tool responses without a person watching. Use invented adversarial cases to test whether the application's permissions and approval controls reject unapproved recipients, broader access and actions awaiting approval. Inspect attempted calls and actual outcomes; source content may still influence the model. Give the owner a way to pause the schedule and disable its connections. See AI skill security before enabling unattended runs.
Define recovery before enabling repetition
Set a missed-run policy: how late an output remains useful, who checks for its absence and whether to retry or skip it. Verify the scheduler's catch-up behavior. A delayed run should use the intended reporting period and identify its actual preparation time.
For the invented briefing, the operations lead checks for a draft at 8:30. If none exists, they inspect the run status and arrange one recovery attempt before the meeting, without overlapping an active run. After the meeting starts, they mark the briefing missed and handle any urgent issues directly.
A retry should not create a duplicate record or send a second copy. Give each intended run a consistent identifier and check that the destination uses it to recognize an operation already completed. A filename or written instruction alone does not establish that behavior. If an email's delivery status is uncertain, check what happened before sending again. For this briefing, a person retains responsibility for distribution. AWS guidance on idempotent retries.
Give the routine an owner and a visible record
Keep a run record with the intended date, actual start, input freshness, skill revision, output link, review status and any failure or retry. Make “ready for review,” “blocked” and “missed” distinguishable. Assign an owner and a backup who can pause the schedule, restore access and update the instructions. Before relying on it, test an ordinary run and likely failure cases, including stale inputs, unavailable sources and interrupted delivery. Record what actually happens.