Create one workspace schedule: a job Well runs on a clock or on an event, with nobody in the chat. A schedule is either a prompt (a written instruction a headless run follows) or a method (a registered function name plus params).

Use it whenever the user wants something done or sent at a later time, on a rhythm or when an event happens.

A schedule covers three kinds of job:

• Once, at a set time: "send me a poem at 1:45am", "remind me Friday to pay Kepler". Send max_occurrences 1, run_after at that moment (ISO 8601 with an offset) and a cron_expression that matches that time of day. The run is the message or the job itself. A day with no time runs at 09:00 in the user's time zone: say that time in the cadence_label and in your confirmation. If the start time passed before confirmation, propose a new time.

• Recurring, on a rhythm: "every Monday 9am send me the runway". Send a cron_expression and no max_occurrences.

• On an event: "each time a payment is matched to an invoice". Send a trigger_name from well_list_schedule_triggers. A message for the user is a job like any other. Well sends the user the run's result after a run that succeeds, so for a message or a reminder set status_report to "on_success" and write the instruction so the run puts the message itself (the poem, the reminder line) in its result. On WhatsApp the message arrives as written inside the 24 h window; outside it the user first gets a notification with a short summary, and the full result arrives after they reply. A to-do ("add a to-do", "I need to file X by Friday") is a task, not a schedule.

REQUIRED: name, kind ("prompt" or "method"), routine_summary, cadence_label, status_report, timezone, approved_tools and 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. For a prompt: instruction (the detailed brief the run follows to the letter, with every decision it must make alone). For a method: method_name, and method_params when the method takes any.

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. OPTIONAL, for a clock routine only: run_after (ISO 8601 with an offset: no run happens before it), max_occurrences (a whole number of runs, then the schedule completes; 1 runs once).

cron_expression is a standard 5-field cron: minute, hour, day of month, month, day of week. A seconds field is refused. timezone is an IANA name such as Europe/Paris, and a cron is read in it. 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.

status_report is the user's own answer to the report question: "on_error", "on_success", "both", or "none" when they did not ask for a message. Well sends the report itself after each run; never write it into the instruction.

approved_tools is the consent record: the write tools the user signed off before the schedule was armed, as entries { tool, connector? }. The tool of each entry is the exact name of a write tool in your own toolset, one entry for each change the user approved; a read tool or a guessed name is refused, and so is any tool that invites members, buys credits, changes the plan, manages the subscription or sends email: a routine cannot do those, so tell the user instead of listing them. It is required, and [] means the routine only reads. At run time a scheduled run is told to make only the changes the list describes. A method schedule always sends [].

purpose is optional and names the job when a recipe of the schedule skill names it, such as "weekly_missing_invoices_total" for the missing-invoices total. Send it exactly as the recipe names it, and leave it out for any other routine. Well finds a routine by its purpose, never by its text, so a member never gets the same routine twice.

verified is required. false saves a draft that runs nothing and draws no card. true asks to arm the schedule: in Well's chat the schedule runs only after the user approves the confirmation card, and anywhere else it is saved as a draft. Both are required so that a forgotten flag or list is an error, never a default. 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.

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: 1. Load the /schedule skill and follow it. 2. Show the user the routine_summary, when it runs and every permission in plain words, and get an explicit yes. 3. Call this tool once, with verified: true. 4. In Well's chat, wait for the user to approve the card, then quote status and next_run_at. Anywhere else, quote the draft status and tell the user to arm the routine from Well's chat.

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 run a job once now; the skill that owns the job does that. Do NOT use this to change a schedule that exists (use well_update_schedule), or to add a to-do (use the tasks tool). A scheduled run never calls this tool.

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.