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", "send me a haiku on Friday". 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") or a one-time reminder to do something ("remind me Friday to pay Kepler") is a to-do for well_create_task, not a schedule, unless well_create_task answered code "reminder_needs_schedule": then it runs once, at a set time; a reminder that repeats ("every Monday remind me to check the bank") is 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). OPTIONAL, for any routine: ends_at (ISO 8601 with an offset): the moment after which the routine stops. No run happens after it, and the schedule completes once it passes. Send it when the user names an end, such as "until 31 December" or "for the next two weeks"; omit it for no end. It must be after run_after.

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 is held on Sunday in the user's time zone by default. The morning brief is never held by the Sunday gate; its default cron runs on weekdays. For another routine, only an explicit choice lifts the hold: name Sunday in the day-of-week field when asked for Sunday or all seven days (0 alone or in a list or range; * does not name Sunday), save sunday_routines as receive, or set a one-off time. A meeting or Sunday habit does not lift the hold. A routine already scheduled for Sunday must have Sunday removed from its schedule to stop it; other routines already have the default hold. 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. Two creates arm at once with no card on every surface, because the ask is the yes and the run writes nothing: an agent's routine (agent_seat_id), and a weekly_missing_invoices_total routine of kind prompt on a cron that fires once a week, with no approved_tools. 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. Two exceptions. The creator's own edit of a weekly_missing_invoices_total routine that still fits the rule above (kind prompt, a cron that fires once a week, no approved_tools) keeps it armed on the new clock, and arms it when it is a draft, with no card and with Well's own instruction for that job. Moving only the hour and minute of the user's active afternoon or EOD touchbase, on the same weekdays and with a new cadence_label, keeps it armed.

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.