Change, arm, pause or resume one workspace schedule.

Use it to move, rename, pause or re-arm any schedule: a one-off at a set time ("make the poem 2am"), a recurring job ("move the Monday runway to Tuesday") or an event job. To move a one-off, send the new run_after and a cron_expression that matches its time of day, together.

REQUIRED: schedule_id (from well_list_schedules or the result of well_create_schedule). OPTIONAL: name, routine_summary, cadence_label, status_report, instruction, method_name, method_params, cron_expression, trigger_name, timezone, run_after, max_occurrences, approved_tools, status, verified.

Send exactly one: cron_expression for a clock, trigger_name (from well_list_schedule_triggers) for an event. An event routine takes no run_after or max_occurrences.

status takes "paused" (stop admitting runs, keep the approval) or "active" (resume a paused schedule). "active" never arms a draft. Send status on its own, without the other fields. To end a schedule for good use well_cancel_schedule. To skip a few days and let it carry on by itself, use well_snooze_schedule: a pause lasts until the user resumes it.

status_report ("on_error", "on_success", "both" or "none") is the message the user wants after a run. Changing only status_report needs no new yes and draws no card: send it on its own, without verified.

verified: true arms the schedule with any fields sent in the same call. In Well's chat it asks the user for approval: the schedule is armed, and a changed version runs, only after the user approves the confirmation card, and until then the stored schedule is unchanged. Anywhere else the fields are saved as a draft edit and nothing is armed. Only a call that arms a schedule (verified: true) asks the user for approval, through a confirmation card in Well's chat, and the schedule is armed only when the user approves it. Outside Well's chat no card can be drawn, so verified: true arms nothing there: the call saves the schedule as a draft, and the user arms it from Well's chat. Saving or editing a draft, pausing, resuming and cancelling draw no card. Editing the routine_summary, the cadence_label, the instruction, the method, the rhythm, the time zone, the start, the end limit or approved_tools returns the schedule to a draft, which runs nothing until it is armed again.

A cron whose day-of-month and day-of-week fields are both restricted fires when either one matches. To tie a weekday to its nth occurrence in the month, leave day-of-month as * and write the weekday, then #, then n, in the day-of-week field. A clock routine does not run on Sunday in the user's time zone unless the user asked for Sunday, has a business meeting that Sunday, or often writes to Well on Sundays. When the user asks for a routine on Sunday, or on all seven days of the week, name Sunday in the day-of-week field, as 0 alone or inside a list or range that holds each day asked for: a * there does not ask for Sunday. A one-off at a set time always runs. A request never to run anything on Sunday changes no routine: Sundays are already held back by default. For a cron, two runs of a schedule must be at least 30 minutes apart, and the rhythm must fire at least once a year. A rhythm outside that range is refused, never adjusted: explain the rule to the user and let them choose a rhythm that keeps it.

The user never reads the instruction, the cron or a trigger name: the instruction is the detailed brief for the run, and a person does not read a contract. Show the user only the routine_summary, when it runs (with the status report choice) and the permissions, in plain words, and never paste the instruction, a cron expression or a trigger name into the chat. The confirmation card shows the same three things, built by Well from the stored schedule.

routine_summary and cadence_label are written for the user, in the language of the conversation, as plain text with no markdown. routine_summary says what will happen, and who or what outside Well each change reaches. cadence_label says when it runs. For a clock it says the rhythm in words and says the same thing as cron_expression: write both in the same call. Well computes the next run dates from cron_expression and shows them beside cadence_label, so a label that disagrees with the cron is visible to the user. For an event it says the event in plain words, such as "Each time a Qonto payment is matched to an invoice", and never the trigger_name. A call that changes cron_expression, trigger_name or timezone must also send a new cadence_label, and a call that changes the instruction or the method must also send a new routine_summary: a call without them is refused. Changing the timezone of a routine Well set up makes it stop following the person's profile time zone for good, so send timezone only when the person asks for another zone.

The result states status and next_run_at. Quote them to the user, and say the stored approved_tools in plain words, never as tool names.

WORKFLOW: for a change to the job, the rhythm, the end limit or the permissions, run the /schedule conversation again on the changed parts, show the user the routine_summary, when it runs and the permission list as they will stand, get an explicit yes, then call this tool once with the changed fields and verified: true. A pause or a resume needs no approval.

The conversation that produces a good schedule (what the run needs, which jobs cannot run alone, the rhythm advice and the permission list the user signs off) belongs to the /schedule skill. Load it before proposing a schedule.

Do NOT use this to create a schedule (use well_create_schedule), to cancel one (use well_cancel_schedule) or to snooze one (use well_snooze_schedule). A scheduled run never changes a schedule, its own included.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.