Tools
Plans, goals and schedules
Showing where the work stands, asking you only real choices, and keeping goals, board cards, long tasks, schedules and workflows going over days.
What this family is for
One turn is often not the whole job. These tools hold the work that outlives a turn: a plan you can watch, goals with a definition of done, cards on the board, long tasks over days, schedules that run on their own, and workflows you can run again.
The plan and the one question
update_plan shows where the work stands as a short living outline: she starts the first stage, looks at what came out, then decides the next, marking stages done as she goes. A whole plan up front comes only when you ask for one or every step is known, and a one step request gets none.
ask_user is for a real decision that is yours: a direction, a look, a trade off she cannot settle from your words. It shows at least two options with her pick first and a box for your own answer. It is never a quiz before starting; with nothing concrete to choose, she decides and says what she assumed.
Goals and the board
- A goal is an objective that spans sessions, with success criteria that say how she will know it is done. Progress is scored after each turn, and complete needs evidence. See Goals.
- A board card is a unit of work to track or queue. Mori can file cards into Triage, Planned or Waiting · You; only you can move a card into Ready, the lane a worker runs. See The board.
One goal broken into several linked cards is the usual shape.
Long tasks
Work that cannot fit one sitting becomes a long task with milestones you can check, each with how you will know it is done. The card shows a time range with its basis, the budget and when it reports, and nothing runs until you press Start or say go. Each milestone then runs as its own goal. update_long_task pauses, resumes, stops or replans it, and changes the budget only to an amount you named. See Long tasks.
Schedules
schedule_task runs a job every day at a clock time. schedule_cron covers everything else: a cron expression, a one off at a moment, or every few minutes. The clock keeps time with the window closed, but the app must be running; a job due while it was closed fires once when it opens again. A run that cannot reach the model tries again after 5, 15 and 30 minutes. Pausing keeps a job; cancelling deletes it.
A scheduled run is unattended, so it gathers, summarises, drafts and reports. It never sends messages, buys anything, drives your screen or does anything that cannot be undone. See Automations.
Workflows
run_workflow runs a named multi step routine end to end. workflow_manage saves, forks, lists and deletes your own; a saved one with the same id as a built in replaces it for you. workflow_script writes small programs whose shape depends on what they find, such as a loop that runs until nothing new turns up. Saving a script runs nothing. With asking on, a script waits for your yes before it runs, and asks again whenever its text changed, because the yes is for that exact script. See Workflows.
Permissions
The plan, the question card and listing goals, tasks and schedules always run. Creating and changing goals, cards, schedules and workflows follows the File Writing switch in Settings > Permissions, and none of them run at the Safe level. Goals stay on this computer, inside the current workspace.
Each description below is the exact text her model reads when it decides which tool to call.
Show the user where the work stands, as a short living outline. Build, then think: start the first stage, and after each one look at what came out and decide the next. Mark finished stages "done" and the one you are on "active"; add the next when you reach it. A whole plan up front (3-8 steps) only when the user asked ("plan it first") or every step is known. Never for a single-step request.
Ask the user to choose, only when a real decision is theirs: a direction, a look, a trade-off you cannot settle from the request, the files or sensible defaults ("portfolio or shop?"). Shows a card with your options, the one you recommend first, and a box for their own answer. Never for what you can find out or decide yourself, never a quiz before starting: with nothing concrete to choose between, decide and say what you assumed. Needs at least 2 real options.
Create a DURABLE GOAL: a long-lived objective that spans many tasks and sessions (e.g. 'finish the product launch', 'keep the docs accurate'). Goals persist across restarts on this computer (they do not sync to other devices). Use for multi-session objectives, NOT for one-off tasks; for one big job worked over days in milestones, use plan_long_task.
Update a goal after meaningful work: progress %, status (active|paused|complete|blocked|failed), blocker, next action, or completion evidence. Always record evidence when marking complete.
List all durable goals with status, progress, blockers and next actions.
Add a task card to Mori's task board (the durable Kanban: survives restarts, visible on every device). Use when work should be tracked or queued rather than done now, or to break a goal into pieces.
Move/update a board task: change lane, record the latest action, set a blocker or result. Use lane=completed with a result when done; lane=waiting_user when you need the user.
List Mori's task board (optionally one lane) with ids, lanes, priorities, blockers.
Plan work that cannot be finished in one sitting (a big build over hours or days, up to 30 days) as a LONG TASK in this thread. Give milestones the person can check, each with how they will know it is done and a size (S, M or L); say how it will work and what to expect. The card lands in the thread with an ETA range and its basis, the budget and the bulletin schedule; NOTHING RUNS until the person presses Start (or says go: then call update_long_task with action "start"). Then each milestone runs as its own goal, with a bulletin at each one. Do not use it for anything you can finish now; never pretend a long job fits one prompt.
Change this thread's long task: action "status" (where it stands, from the record), "start" (only when the person said go), "pause", "resume" (when they say carry on), "stop", "budget" (with budget_usd: only an amount the person named), "replan" (new milestones still to do), "add" (one milestone), "drop" (one still to do).
Schedule a RECURRING task that you will run on your own and report back, daily at a clock time only, e.g. 'every morning at 8am brief me on my calendar'. For one-shots ('in 2 minutes', 'at 3pm today') or cron expressions ('30 8 * * 1-5') use schedule_cron instead. These run UNATTENDED, so use them for prep and reporting (briefs, summaries, drafts, reminders), they will NOT send messages, make purchases, or do irreversible actions without you present. Give a clear prompt of what to do each run. The result returns the job id and next-fire time, quote the id back to the user (list_schedules and cancel_schedule use it).
Schedule an unattended run with REAL cron precision, a 5-field cron expression ('30 8 * * 1-5' = weekdays 8:30am), 'at:<epoch-ms>' one-shot, or 'every:<minutes>'. This is THE tool for one-shots and cron expressions, 'in 2 minutes' or 'at 3pm today' means compute the epoch-ms and pass schedule 'at:<epoch-ms>' (e.g. at:1753048800000); schedule_task is only for recurring daily-at-a-clock-time jobs. The clock lives in the main process, so it keeps time while the window is unfocused or hidden, but Mori must stay RUNNING: closing the app quits it, and jobs due while it was closed fire once on next launch rather than at their scheduled time. Say that plainly if the user is relying on something firing overnight. Call with action 'list' to see every cron job with its id, schedule, lastRun, nextRun, and enabled state, action 'cancel' with an id to stop one for good, or 'disable'/'enable' to pause and resume one without losing it. A run that cannot reach the model tries again after 5, 15 and 30 minutes (or at its own next run, if that comes sooner), then says it gave up. Same unattended safety rules as schedule_task (no sends/purchases/irreversible actions).
List the tasks you have scheduled to run on their own, each row carries the job id, next run, last run, and enabled state. Cron jobs live separately: schedule_cron with action "list".
Pause a scheduled task WITHOUT deleting it (or resume a paused one) by its label or id. Use this when the user says pause, stop for now, or turn off; cancel_schedule deletes for good. Cron jobs: schedule_cron with action "disable"/"enable".
Cancel a scheduled task by its label or id.
Run a defined multi-step WORKFLOW end to end. Use this when the user names a workflow, or when a job clearly matches one; the "workflow" parameter lists the built-in ids. It also runs SAVED SCRIPTS by name (write one with the workflow_script tool): a script takes "args" instead of a subject, asks the user to approve it before anything runs, and by default runs in the background with its result delivered back here.
Save, fork, list or delete the user's OWN workflows, the multi-step routines run_workflow runs. Fork a built-in when they like its shape but want it different; save a fresh one when they describe a repeatable procedure and ask to keep it. A saved workflow with the same id as a built-in REPLACES it for this user, which is what makes forking useful. Do not save one the user did not ask to keep.
Write, read and manage WORKFLOW SCRIPTS: small JavaScript programs that orchestrate agents, model calls and research, for work whose SHAPE depends on what it finds, judge panels, loops that run until nothing new turns up, pipelines sized by an earlier answer. A spec workflow (workflow_manage) declares every step up front; a script decides as it goes. Start with action=guide, which is the full language reference: eleven primitives, the caps, and a worked template. Saving does NOT run anything, run it with run_workflow workflow=<name>.
Keep a note in a bot's own memory (what it learned, what to watch next run). A bot's notes are read back by list_bots with that bot named.
The price of an asset right now on a bot's exchange (its public price; no key, no order).
Save one research note to a buying automation's research feed, after reading the web: for a coin, the price and volume, the news and the reasons behind a move, on-chain basics from public pages; for a product, its price across stores and how it moved. Information only, never advice: no "you should buy". Give the sources you actually read.
Propose a small coin buy (BTC, ETH) for one of the person's buying automations. It never buys by itself: in practice it is simulated inside the limits; with sandbox or real money it waits for the person, and real money also needs their yes in Mori's own window. Only a coin the automation's rules or job name. The answer says: refused (and why), waiting, or simulated. Never retry a refused buy in smaller pieces; tell the person. Not for shopping or food.
The person's buying automations: each one's name, mode (practice, sandbox, real money), whether it is on or stopped, its limits and what it has spent today, buys waiting for a yes, and its last check. Name one (bot) to also get its rules, its notes and its last buys.
Make a buying automation from the person's own words: it runs on a schedule with its own memory and buys small things for them. Purchases: watch a product or listings page for a target price, a restock or a new listing matching words, then tell them, or fill the cart in their own Chrome and stop at the buy button for their yes. Small regular buys on their own exchange account (Coinbase or Binance): "put $10 a week into BTC", "buy $20 of ETH if it drops below 3000". Buying only: it never sells. Every new one starts in PRACTICE, asks before every buy, and has small default limits; the person reviews it in Automations, under Buying, and only they can change limits or switch on real money. Refuses fraud, scalping limited items in bulk, getting past CAPTCHAs or queues, other people's accounts, and anything illegal. Give rules as JSON when the words are not one of the simple shapes.
Stop a buying automation now (or every one, with bot "all"): it stops running, its waiting buys are dropped, and its own open orders on the exchange are cancelled. Only the person can turn it back on, from Automations.