ROBIONDocs

Board, Inbox, automations and the Steward

The four things that let Robion act between your sessions: the BOARD of your intents, the INBOX of what waits for your decision, AUTOMATIONS (rules with no model in the path) and the Steward, a planning session. All arrived in 0.16; expiry, the Steward’s schedule and STEWARD.md in 0.18–0.19.

The BOARD

  • Where: BOARD in the rail above the projects; on the phone the board tab of the bottom bar (#/board, phone.md has the phone’s version).
  • Three columns, todo / doing / done. Drag a card between columns to change its state (the only way a state changes). The order inside a column is its priority: the Steward plans from the todo column, top first. Done cards older than 7 days fold into + N older.
  • New card: the new card… field under todo (add to doing…, add to done… in the other columns). A card has a title, a note (optional) and a project (project of the new card; no project is allowed). It carries its project’s colour.
  • Click a card: the whole card opens in a dialog — title, note, where it comes from (from the Steward, from an agent), created N ago — with edit, delete (asks “Delete this card?”) and close.
  • start a task in the dialog starts Claude Code in the card’s project with the card as its first prompt; the card follows the task to doing and shows its state (task running, task waits for you, task finished — review, task idle, task closed); open the task jumps to it. A card without a project says a task needs a project — edit the card.
  • Agents add cards: tell an agent “remember to…” and it adds a todo card (board_add), marked from an agent. The Steward adds a todo card when something needs your own decision.

The INBOX

  • Where: INBOX in the rail above the projects (“what the automations left for you to decide”; the rail counts items that need you); on the phone at #/inbox. Empty: “nothing waiting — proposed rules, proposals and blocked runs land here”.
  • Groups: an agent proposes a rule (a rule an agent wrote, stored switched off — enable turns it on; since 0.20.9 an agent that re-sends a rule you already have leaves its switch alone — only a rule whose trigger, conditions or actions changed comes back here switched off, and since 0.20.36 conditions merely added to a rule keep it on too, because they can only make it fire less); proposed — waiting for your go (from a rule’s propose action or the Steward — accept runs the prepared actions and brings a started task up at once); blocked by your limits and failed (run anyway); started by the Steward (autonomy 2 started it: “marked safe, so it started at once — open it to look”, open); finished — the agent’s last message (a task an automation started finished a turn; with supervision on, the item reads “ready for you: ” with the Steward’s note; a task the plan finds waiting for you reads “needs you: ” with what to do — open brings the task up).
  • Two halves (since 0.20.9): the groups that wait for your word (proposed rules, proposals) are always open at the top; the rest — blocked, failed, started, finished — sits folded under one heading for information · N (“finished, started, blocked and failed runs — nothing here waits for a decision”); a click unfolds it and the choice is remembered on this device. With nothing on top the screen says nothing needs you above the fold. The phone folds the same way.
  • Project chips (since 0.20.9): with items from two or more projects a row under the header lists all projects · N and one chip per project with its count; a chip shows that project’s items only, the pick survives closing the screen, and a project whose items are all gone falls back to all projects. The phone has the same chips (all · N).
  • One item per task (since 0.20.4): a later finished turn refreshes the same item (“updated 5 min ago”) instead of adding another, and once you answered it nothing more comes for that task — you are on it now. Every item shows its age (“5 min ago”, “2 h ago”).
  • Prepared actions show in plain words: “start a task: …”, “push to the phone: …”, “send to the agent: …”, “press button """. Blocked items say why: “quiet hours — accept to run it now”, “daily limit of N tasks reached”, “throttled: at most N runs per M min”, “N tasks are waiting for review (limit L)”.
  • edit the brief (since 0.20.4) on an item that starts a task opens its brief in a text field (“the task starts with your edited text”); accept then starts the task with what you wrote. back drops the edit.
  • snooze (since 0.20.4) on proposals, proposed rules and blocked items: “hide until ; it comes back by itself” — the next working day 08:00 (a Friday or Saturday snooze wakes on Monday). The item stays open, leaves the list and the badge, and does not expire meanwhile; the Steward’s briefing marks it as put off on purpose.
  • dismiss asks why on everything but finished and started items: one-tap chips already done, not now, not needed, wrong premise, or a line in the field why? (optional — the Steward reads it tomorrow); ↩ or dismiss confirms, Esc or back cancels. The chip’s words are what the Steward reads. A group of two or more finished, failed or blocked items offers dismiss all in its header (“Dismiss all N items under “”?”). A rule that is removed or rewritten takes its open items with it.
  • Expiry (since 0.19): ⚙ → Automations → Inbox proposals expire after (7 days by default, 0 = never). A proposal left unanswered that long is dismissed as “expired”; the Steward reads that as unanswered, not as a veto. Blocked and failed runs never expire.
  • The Steward’s line at the top: plan now (“the Steward reads your projects, tickets and notes and proposes today’s tasks here”), the Steward is planning…, Steward: last plan or Steward: no plan yet, next for the next scheduled plan (since 0.19), the Steward failed: when a run broke. Since 0.20.4 also last plan: 7 min · 46 turns · $1.23 (what the last plan took and cost, from the session’s own report), cancel while a plan or a supervision runs, and the plan itself under the header, folded to six lines with whole plan / less; past plans lists the earlier ones (date and first line, “no earlier plan”), a click shows one, today’s plan returns.
  • The phone is told (since 0.20.4) about a blocked or failed run and about the Steward’s hand-overs (“ready for you”, “needs you”) as a push; a plan that fails pushes too.
  • Getting there: INBOX in the rail, ⌘I (Window → Inbox; ⌘I again closes it), or ⌘K → inbox; ⌘K also has automations and board. The dock badge counts the items that need you (proposed rules and proposals) together with the waiting agents.

AUTOMATIONS

  • What: a rule is a trigger plus fixed actions, with no model in the path — “when a ticket is assigned to me, start a task”, “every weekday at 6:30 propose a summary”. Rules belong to a project. ⚙ → Automations intro: “Rules that react to the outside world without a model in the path … Agents write them, you enable them on the Automations screen; blocked runs wait in the Inbox.”
  • Rules run in the server, which since 0.20.16 keeps running when the window is closed (workspace.md, “Closing the window vs. quitting”); they stop with Robion → Quit and while the Mac sleeps (a missed cron minute is not caught up).
  • Triggers: issue.created / issue.updated — a ticket newly matching the rule’s query, or a matching ticket that changed, from Jira (JQL), GitLab (issues query) or GitHub (search qualifiers, issues and pull requests alike); the default query is “assigned to me and not done”; filters on status, priority, labels, type or “assigned to me”. Since 0.20.16 a GitHub PR query can say checks:failure (Robion’s own word, GitHub’s status: sees commit statuses only): is:pr author:@me is:open checks:failure with an issue.updated trigger fires when an Actions check run fails on one of your open pull requests — once per failed run, so a PR that goes green → red fires, a PR that stays red does not, and a PR that was red before the rule existed never does. The task’s brief can name the check (${issue_check}, ${issue_check_conclusion}, ${issue_check_url}). The token needs Checks read (a fine-grained token; classic repo has it), see settings.md; Robion asks GitHub twice per pull request per poll, for the 20 most recently updated PRs at most. Trackers are polled (⚙ → Automations → Ticket poll interval, seconds, min 30); the first poll only takes note of what exists, so an old backlog never floods you. cron.tick — five cron fields minute hour day month weekday, local time (30 6 * * 1-5 = weekdays 06:30). Since 0.20.12 two triggers about you rather than the outside world (the Rhythm in settings.md): desk.waiting — every agent of every project has been running for N minutes and none needs you (no permission, no question, no unread result); fires once per such stretch and only while you are at the Mac. desk.sitting — N minutes at the desk without a break (an idle gap of ⚙ → Automations → Rhythm → A break is minutes ends a stretch), again at every multiple. Their events carry running_tasks and waiting_minutes / sitting_minutes for templates. Meant for pushes about you (a walk, water, a stretch), never for work. Slack (since 0.20.25, ⚙ → Automations → Slack, see settings.md): slack.message — a person’s message in a channel the Robion bot is a member of; slack.mention — the bot mentioned; slack.reaction — an emoji added to a message; slack.dm — a direct message to the bot or a group DM it is part of (other people’s DMs are never visible to a bot; for a 1:1 DM channel_name is the sender). Slack pushes them the moment they happen (Socket Mode, an outbound connection, no polling and no public address), so a rule “new thread in #devops → start a task” costs nothing while nothing happens. The rule picks its channels in when (channel_name, in for several) and thread_reply: false for new threads only; edits, deletions and bot posts never arrive. Events carry channel, channel_name, channel_type (channel, group, im, mpim), user, user_name, text (mentions and links readable), ts, thread_ts, thread_reply, since 0.20.36 thread (the thread’s root timestamp, the message’s own for a top-level one), permalink and reaction. The Slack section of the settings shows which channels the bot listens in; a rule for a channel the bot is not in never fires. A condition can also say what must not match (since 0.20.36, not / not_in): “everyone except me” is "user": {"not": "me"}, where “me” is Your Slack member ID in ⚙ → Automations → Slack (settings.md) — while it is empty such a condition never holds, so the rule cannot fire on your own messages by accident.
  • Actions, run in order, stopping at the first failure: task.create (a prompt for Claude Code; the review-queue limit still applies; since 0.20.36 with a dedupeKey — for Slack typically the channel and the thread — one open task per key: while a task started with that key is open, a later event types its prompt into that task as a follow-up instead of starting another, so a whole Slack thread stays one conversation, and a closed task lets the next event start a fresh one; a continued task does not count toward Tasks per day); push to the phone; pane.send (text typed into a running agent task — the one this rule started or continued, or the project’s newest; fails while the pane waits for a permission or when no such task is open — the failed run waits in the Inbox, where run anyway fails the same way; a rule that should start a task when none is open uses task.create with a dedupeKey instead); run (press a run button of the project’s controls panel — since 0.20.16 the action waits for the command and takes its exit code as its own result: a non-zero exit is a failed run in the Inbox and on the phone, with the last lines of the command’s terminal as the reason; a command still running after 15 minutes counts as done); inbox.propose (nothing runs until you accept it in the Inbox); steward (an extra plan tied to this event; needs the Steward enabled).
  • Who writes rules: an agent, in any project. Say “when X happens, do Y” and it writes the rule (set_automation, or /robion:automate). It can test the rule against a recent real event first — no side effects, listed as dry run in the history; since 0.20.36 the test also says whether the rule’s conditions would let that event through and which condition turns it away. It can list (since 0.20.36 also read one rule’s full definition), rewrite (same id) and remove rules, and since 0.20.36 do so for another project of the same server when you name it — before, a rule for another project meant a task in that project. The Automations screen only views and toggles them.
  • A new rule is stored switched off. It appears in the INBOX as an agent proposes a rule and on the AUTOMATIONS screen marked agent proposes; enable it in either place. An agent never claims a rule is active.
  • The AUTOMATIONS screen (rail, above the projects): every rule of every project — rule, trigger, actions, project, last run, 24 h; header “N rules, M on”; a switch on / off per row; run now (an issue rule runs on the newest ticket its query returns right now; the result reads ”: — ”). Outcomes: ran, blocked, failed, dry run. Each tracker shows connected / not connected. “automations are switched off in settings” / “automations paused: ” explain a silent screen.
  • Above the table (since 0.20.4) the Steward row: its cron schedule, a state dot, its last plan with what it took and cost, a switch (= Let the Steward plan on schedule) and run now (= plan now); a click shows its plans in the drawer as runs.
  • Switching a rule off (since 0.20.4) first asks why off? (optional, shown next to the rule) → switch off / back; the row then reads off: under the name until the rule is on again.
  • A click on a row opens the drawer: the rule as JSON; edit via agent (a task in the rule’s project whose first prompt hands the rule to /robion:automate — say what to change); delete (“Delete the rule “”? Its history stays.”); history — since 0.20.4 the rule’s own newest 200 runs from the server, each with its outcome, reason, minutes and cost when known, → task for the task it started and in the Inbox when it ran from an accepted item; and for an issue rule skipped events (“tickets this rule saw and its conditions turned away”, none): the ticket and the first condition that failed, e.g. issue_assignee_id: "acc-2" ≠ me — the answer to “why did my rule not fire”.
  • finished turns land in the Inbox (since 0.20.9, a checkbox in the drawer, on by default): off = a task this rule started finishing a turn shows only in the task panel and the Inbox keeps to what needs a decision — for routine rules whose tasks you read anyway. It flips in place: the rule stays on and its open Inbox items stay. An agent sets the same thing with inboxOnDone: false in the rule.
  • Model (since 0.20.14, in the drawer of a rule that starts tasks — directly or through a proposal): the model for the tasks this rule starts. default = your Claude Code model, Fable 5.1, Opus 5, Sonnet 5.5, Sonnet 5, Haiku 4.5, or custom… with a model id typed into the field next to it (⏎ or leaving the field saves; an emptied field = default). A cheaper model for routine work. It changes in place like the checkbox above (the rule stays on, its Inbox items stay); the task launches with --settings {"model": …} and keeps it across a restart of the session. An agent sets the same with model on the rule (null = default); a rule an agent re-sends without model falls back to the default, so ask it to keep the field.
  • starter rules… (since 0.20.4; in the header, since 0.20.12 always, not only with a tracker connected): a panel starter rules with a project choice and ready-made rules to tick — New ticket for me → proposal in the Inbox (a ticket newly assigned to you becomes a proposal; accept it and an agent starts on it in its own worktree), Urgent ticket for me → task at once (a new ticket of the highest priority assigned to you starts a task in its own worktree right away, with a push to the phone), and since 0.20.12 two rhythm rules that need no tracker: Waiting on agents → go for a walk (every agent has been running for five minutes and none needs you: a push says so, so you can leave the desk) and An hour at the desk → stretch (sixty minutes at the desk without a break: a push to stand up, again every hour until you take one); add N stores them as yours and switched on (“N rules added”; the first poll only takes note of what exists), cancel closes the panel. The rhythm rules only fire while the desktop app runs (it reports the Mac’s idle time); the ticket ones need a tracker connected.
  • Limits, ⚙ → Automations: Run automations (off = nothing fires; rules and the inbox stay); Tasks per day (the agent tasks rules start with task.create, all rules together; 0 = no limit; more land in the Inbox; a run button press is neither counted nor held back — up to 0.20.33 presses used up the limit, so a few cron rules could block every task from the afternoon on); Quiet hours (HH:MM–HH:MM, may span midnight; blocked runs wait in the Inbox); Keep history for (since 0.20.4; 7–365 days, 90 by default: older runs, skipped events, answered Inbox items and the Steward’s daily files are deleted; open Inbox items stay). A rule may carry its own throttle. Every event runs a rule at most once.
  • Trackers, ⚙ → Automations → Issue trackers: one connection per tracker, shared by every project; Jira site URL, Jira account e-mail, Jira API token; GitLab URL and a GitLab personal access token (scope read_api); GitHub API URL (empty = github.com) and a GitHub personal access token. Tokens live in the keychain, never in config.json; Robion never writes to a tracker. The JIRA panel reads from the same connection.
  • A task an automation starts carries the note “started by automation """ and, by default, runs in its own worktree: ⚙ → project → Tasks of the Steward and automations: own worktree (“unattended work never touches the checkout you are editing”). A project added since 0.20.36 from a folder that is no git repository starts with this off — worktrees need git, and every automated task there used to fail until the switch was flipped.

The Steward

  • What: a planning session — a headless Claude Code run the server starts with a briefing it composed. It proposes tasks into the Inbox with a brief for each and never does the work; at autonomy 1 nothing starts until you accept. Off by default. Settings: ⚙ → Automations → Steward. It runs above all projects; when it finishes, the phone gets “Steward: N proposals, M need you”.
  • Runs: plan now in the INBOX, its own schedule, or a rule’s steward action. Schedule (since 0.19): Let the Steward plan on schedule (“off = scheduled runs are skipped; plan now still works”) and Schedule — five cron fields, local time, weekdays 6:30 by default; an invalid cron keeps the last valid one; the Inbox shows the next plan. Every plan lands in the automations history as “plan (plan now | on schedule): N proposals” — since 0.20.4 with what it cost and took (the session’s own figures: minutes, turns, dollars), also shown in the Inbox’s Steward line and as the last line of plan-<date>.md (“Run: 7 min, 46 turns, $1.23”). A rule’s steward action now reads failed when the plan failed or the Steward is off. cancel (Inbox, desktop and phone) stops a running plan or supervision: no red state, the history says “the plan was cancelled”. A plan that fails pushes “Steward: the plan failed” to the phone.
  • The briefing it reads: your standing instructions; every project with its open tasks (state, how long idle or waiting, what it waits for — the agent’s question, a permission, the last prompt or timeline line) and the commits since the last plan; tickets assigned to you; the open inbox (a snoozed item is marked as put off on purpose); the automation runs since the last plan; the board (todo top first, it outranks any ticket — since 0.20.4 the bodies of unchanged cards below the top eight of a column are left out, the previous briefing has them); the feedback since the last plan; the previous plan; its own memory.md. A task that asks you something is yours to answer, not a proposal. The window starts at the previous plan or a day ago, whichever is earlier, so a Monday plan still sees Friday and the weekend.
  • Standing instructions: ⚙ → Automations → Steward → Standing instructions (STEWARD.md) — “no proposals at weekends”, “robion comes first”, “never propose a release”. Read before every plan; outranks the board, the tickets and the Steward’s memory. The file STEWARD.md in the Steward’s folder (~/Library/Application Support/Robion/steward/, next to briefing-<date>.md, plan-<date>.md and memory.md) can be edited by hand too.
  • Learning (since 0.18): dismissing a proposal asks why; the next briefing lists what you did since the last plan — accepted with the task’s state, dismissed with your reason. Since 0.20.4 that feedback covers everything of the Steward’s (proposals, tasks it started at autonomy 2, its hand-overs “ready for you” / “needs you”) and the rules agents proposed, and the reason chips on desktop and phone make a reason a one-tap affair. A dismissed item is not proposed or raised again; a reason that still holds goes into memory.md. An expired one may come back only when something new speaks for it, marked as a repeat. Older open proposals are counted once (“2 older proposals still wait”), never re-proposed. memory.md can be read and edited in ⚙ → Automations → Steward (emptying it makes the Steward forget).
  • Proposals: at most Proposals per run (“fewer good items beat many”), one project each; a proposal made from a board card moves the card to doing when accepted. A title ends with needs you when accepting would publish, spend money, message people or change something you did not ask for. A fixed risk floor adds “needs you ()” whatever the model decided: release / publish, push to a shared branch, destructive command, money, people, secrets.
  • Autonomy: 1 · proposes (you accept in the Inbox) or 2 · starts safe ones — it also starts at once the proposals it marked safe; never one under the floor. The Inbox then shows started by the Steward; a proposal it could not start stays for you.
  • Scope: projects with no open task, no commit today and no card fold into one “quiet” line but remain valid targets. ⚙ → project → let the Steward ignore this project takes a project out entirely (its cards are skipped, nothing is proposed for it).
  • Supervision: Supervise finished tasks — when a task an automation or the Steward started finishes a turn nobody has seen, the Steward reads a brief (the agent’s brief, its last message, changed files, timeline) and either types one follow-up into the agent’s pane (“From the Steward (reviewing your result): …”, timeline note “Steward follow-up n/max”) or hands the task over: Inbox item “ready for you: ” with a short done / look at / left note, pushed to the phone. After Follow-ups per task rounds the task goes to you regardless.
  • Attention (since 0.20.4): tasks the plan finds waiting for you — a question, a permission, uncommitted work, a dead or stale session — become Inbox items “needs you: ” with one line of what to do; open brings the task up. One per task; a dismissed one is feedback.
  • The plan itself: the summary the Steward writes is stored as plan-<date>.md with Robion’s own frame (heading, “Proposals: n, need you: m”, the run line); the Steward is told not to copy that frame, so the plan no longer shows its heading twice.
  • It can read a ticket (since 0.19): description, newest comments, links and fields from Jira, GitLab or GitHub — only for the tickets it is about to propose.
  • Tools: only its own Robion tools (propose, finish, add a card, read a ticket, reply, ready) plus reading and writing files in its own folder. No shell, no git, no other MCP servers — in a headless run nobody answers a permission dialog, so anything else is refused. Model picks the model for the planning session (default = your Claude Code default; Fable 5.1, Opus 5, Sonnet 5.5, Sonnet 5, Haiku 4.5, or custom… for any model id) — the Inbox line shows what the last plan cost, so the choice can be judged. Its tasks start in their own worktree by default (⚙ → project). Its daily files (briefings, plans, supervision briefs) are deleted after ⚙ → Automations → Keep history for days; STEWARD.md and memory.md stay.