Watches, inbox and reminders

nima has two separate features for telling you things later. Watches notice an event on a signal, beacon, spec or pull request and tell you. Reminders (scheduled messages) send text you wrote to your own Slack DM at a time you pick. They have different gates and different limits, so this page keeps them apart.

Neither feature sends webhooks or CloudEvents to outside systems. Delivery is a Slack DM, your nima inbox and a daily digest.

Turning watches on for a workspace

triggersEnabled defaults to false. Until it is true:

• Creating a watch (POST /v1/watches or the create_subscription tool) returns 409 with "Subscriptions are not enabled for this workspace".
• nima still records events, but nothing fires and no DM is sent.
• The Slack reactions and the stop command below do nothing. A stop message reaches nima's assistant as ordinary text.

If a workspace turns triggersEnabled off later, existing watches stop firing without an error to their owners.

See Workspace settings for the settings route and Availability for what else is off by default.

What a watch is

A watch pins one existing signal, beacon, spec or pull request, and tells you when something happens to it or to anything downstream of it.

• Subject. Each personal watch pins one subjectKind and subjectId, normally a signal, beacon, spec or pr. The subject cannot change; create a new watch instead.
• Downstream events. A watch hears the subject's own events and events on the items it flowed into. The order is signal, then beacon, then spec, then pull request. A watch on a signal hears its beacon, spec and PR. A watch on a spec cannot subscribe to beacon.ready; the API answers 400.
• Saved instructions. You give each watch instructions (1 to 4,000 characters): what nima's AI should look at and say when the event fires. nima runs them and messages you the answer. You can add context (up to 8,000 characters) with preferences from the conversation.
• Daily AI budget. Your conversational watches share 20 AI runs per rolling 24 hours, retries included. Fires past that are skipped, not queued.
• Future events only. A watch you ask for fires only on events created after it existed. Resuming a paused watch resets that start point to now, so it does not replay what happened while paused.
• Conditions. payloadEquals is an object of exact-equality checks on the event payload, for example {"verdict": "drifted"} on pr.drift_checked. There are no ranges, not or or. Every field must exist on every event type the watch selects, so conditions work best with one event type.
• Expiry. expiresAt is optional and must be in the future. An expired watch stops firing.
• Idempotent create. Repeating an identical active request returns the existing watch.

Watches do not support topics ("tell me about any future item matching X"), timers, after or unless conditions, recurring schedules or webhooks. A watch delivers only to its owner, and nima checks at every fire that the owner is still a member with the right permissions.

Watch event types

nima has a fixed catalog of 16 event types. list_event_types (GET /v1/triggers/event-types) returns it with each type's JSON payload schema. A material event interrupts you again even if you were already told about the subject. A non-material event folds into the digest when you were told about that subject in the last 24 hours.

Ticket events belong to workspace rules (see Workspace ticket rules); personal watches normally pin signals, beacons, specs and pull requests. Ticket events carry ids, the issue key, title and URL, and flags. They never carry the ticket body or comment text.

Automatic watches

nima creates some watches for you so the people closest to an item hear about it. They appear in list_watches with createdVia set to reaction or implicit, and you cannot edit them (you can pause them).

The :bell: reaction is silent: nima does not confirm it. It is ignored when your Slack user is not linked to a nima account, when the channel is not an active monitored channel, when the channel is shared with another organization (Slack Connect), or when the message has no signal. An automatic promotion by the system creates no watch.

How watch notifications are delivered

nima delivers each watch notification as a Slack DM to the person it is for (the watch owner, or for a workspace rule the recipient the rule names) and records it in that person's nima inbox. It never posts a watch notification to a channel.

• Slack DM. Text only, from the nima bot to your own DM. Every DM ends with "Reply stop to pause all your watches."
• Interrupt cap. At most 3 interrupting DMs per person per local day. After that, everything folds into the digest.
• Fold window. A non-material item for a subject you were told about in the last 24 hours goes to the digest instead of a DM.
• The 09:00 digest. One DM per person at 09:00 in your Slack timezone (UTC when Slack gives none), listing up to 20 folded items and summarizing the rest in one closing line.
• No Slack link. If your Slack account is not linked, the item is kept in your inbox only (channel inbox).
• One attempt. nima tries each DM once with a 5-second timeout. It does not retry, so a lost response cannot send a duplicate; a failed send shows as failed in the inbox.
• Workspace breaker. If a workspace reaches 200 delivered, digested or proposed fires in an hour, further fires that hour are dropped, not replayed.
• Links. A watch DM links to the beacon or spec in the web app. The web app is an admin panel, so those links land on Integrations. Read the subject with get_beacon, get_document_markdown or get_spec_delivery instead.

Reminder DMs from workspace rules have their own cap of 10 per person per day, are never folded, and approvals and questions are never folded or capped.

Pausing watches: unwatch, no_bell and stop

Pausing a watch stops it firing and never deletes it, so past notifications stay explainable.

stop also removes your pending digest items, so tomorrow's 09:00 DM does not undo it. Only complete commands match; a targeted request such as "stop watching that spec" goes to nima's assistant. nima answers with one line, for example "Paused your 2 watches. nima won't DM you about them again."

To resume, call update_subscription with state: "active". Only watches created through a conversation or the API (AI watches) can be edited or resumed; automatic watches and workspace rules cannot.

Workspace ticket rules (admins)

A workspace ticket rule is a watch with scope: "org" that reacts to tracker tickets for the whole workspace instead of one subject.

Requirements, all at once:

1. Watches are on for the workspace (triggersEnabled).
2. Outbound dispatch is on for the workspace (dispatchEnabled), otherwise 409 "Outbound dispatch is not enabled for this workspace". See Outbound actions.
3. The caller is a workspace owner or admin.
4. The request comes from a signed-in owner or admin session. API keys and MCP tokens cannot create workspace rules today: create_subscription needs subscriptions:write, a rule also needs integrations:write, and no key carries both (the key from /nima mcp-key integrations holds only integrations:write). Either way the API answers 403. Ask the nima team if you need a rule and have no session route.

A rule listens to ticket.opened, ticket.assigned and ticket.comment_added (Jira today) and takes one of two handlers:

• notify with templateKey: "tracker_assignee_reminder". nima DMs a recipient chosen by role (owner, assignee, reporter or spec_owner, with an optional fallback of owner or none). The DM has Snooze 1d and Done buttons. Snooze sends it again a day later; Done ends it. Reminders are capped at 10 per person per day. Mentions are not supported yet. The reminder template speaks for ticket.opened and ticket.assigned only; use an agent rule for ticket.comment_added.
• agent with instructions, tools: ["reply_on_ticket"] and maxActions: 1. nima's AI proposes one reply on the ticket per fire. The reply follows the workspace's action policy for reply_on_ticket. By default it waits for approval on a Slack card. An owner or admin can set an automatic policy, but it applies only in a project marked internal and only when the person who triggered the reply is a workspace member. See Outbound actions. An agent rule runs at most 20 times per rolling 24 hours, and the workspace's daily agent spend cap (dispatch.dailyUsdCap, default $5 per UTC day) applies.

Rules fire only on ticket events that happen after the rule is created. They never replay earlier activity. Anyone can turn a rule's DMs off for themselves with stop.

The nima inbox

The nima inbox is your own list of everything nima has told you about what you watch, newest first. get_inbox (GET /v1/inbox, scope inbox:read) returns it, 20 items per page by default and up to 100.

Each item has a title, body, links, the subject it was about and a channel:

The inbox is personal: nobody, including admins, can list another person's. There is no web page for it; read it over MCP or the API.

To see what happened to a subject instead of what nima told you, use get_history (GET /v1/events). It lists event ids, types and timestamps for one signal, beacon, spec or PR and everything downstream, org-wide, without the underlying text. It needs signals:read.

One-time reminders (scheduled messages)

A reminder saves text now and sends exactly that text to your own Slack DM at a time you choose. It is on for every workspace member whose Slack account is linked; there is no workspace setting to turn it on.

Only pending reminders can be edited (with the version from list_scheduled_messages) or cancelled. Reminder states:

A reminder stuck delivering for more than 5 minutes becomes uncertain. list_scheduled_messages returns up to 200 reminders, pending first by delivery time.

Creating watches and reminders

You can create watches and reminders in Slack, over MCP or over the REST API. There is no web page for either.

In Slack. Ask nima in a DM or an @nima mention in plain words, such as "watch this spec and tell me if it drifts" or "remind me tomorrow at 9". For a reminder, nima asks for a clock time if you gave only a day, confirms the timezone, and says "scheduled" only after the reminder is saved, stating the date, time, timezone and DM destination. See Slack.

Over MCP. The watch tools are list_event_types, create_subscription, update_subscription, list_watches, unwatch, get_inbox and get_history. The reminder tools are get_scheduling_context, schedule_message, list_scheduled_messages, update_scheduled_message and cancel_scheduled_message. Watch and reminder tools need subscriptions:read or subscriptions:write, the inbox needs inbox:read, and history needs signals:read. Parameters are in Watch tools.

Over the API. Routes are documented in Watches and Scheduled messages.