Spawn an agent session by mentioning @ellipsis

Mention @ellipsis where the work lives and Ellipsis answers in the thread, with the conversation as context and the session's tools available for code changes. This works with no config at all: a built-in responder answers every mention.

Add a mention trigger to take over mention handling with your own agent, controlling which sandbox repositories, model, and limits those sessions use:

ellipsis:
  version: v1
  name: Mentions
  description: Answers @ellipsis on GitHub, Slack, and Linear

trigger:
  type: mention
  platforms: [github, slack, linear]

sandbox:
  repositories:
    - name: splitshift-web
    - name: splitshift-api

budget:
  session: 2.00

A mention agent needs no system prompt: its response is built from the conversation it was mentioned in. If several enabled configs claim the same platform, the oldest one answers.

Platforms

platforms scopes where this agent answers. Leave it empty to answer everywhere.

Where mentions work

On GitHub, @ellipsis is detected anywhere in the comment. On Linear, the comment must lead with @ellipsis so a mirrored GitHub thread does not summon Ellipsis twice. On every platform, a mention starts a durable conversation on its surface.

A GitHub mention adds the PR's or issue's repository to the sandbox automatically, so a PR comment mention can read that PR's code even if the config lists other repositories. Slack and Linear mentions have no repository of their own; those sessions clone the repositories the config declares.

Conversations

A mention starts a durable conversation, not a single-shot session. The surface is the conversation: a Slack thread, a Slack DM, a GitHub pull request, a GitHub issue, or a Linear issue is one remembered conversation each. Every later mention on the same surface is delivered into it, and the agent keeps everything it already said and did as context.

How a follow-up reaches the conversation differs by platform. On Slack, any reply in a thread continues that thread's conversation, no repeat mention needed. A DM's top-level messages are their own continuous conversation, answered top-level like a person chatting; replying in a thread under any DM message forks a separate conversation for that thread, so several workstreams can run in parallel in one DM. On GitHub and Linear, a comment must mention @ellipsis again to be delivered; comments that do not are not seen by the mention agent.

A mention conversation never ends on its own: it goes idle between messages, and a later mention on the same surface picks it up again, even after the PR merges or the issue closes.

@ellipsis why do expired shift trades still show as pending in the manager view?

After the agent answers in the Slack thread, a bare reply continues the conversation:

fix it and open a PR

The follow-up needs no context restated: the agent already diagnosed the bug in this conversation and opens the PR from the same working tree.

How a conversation behaves, on every platform:

• A message into an active conversation is delivered within about a second; the agent attends to it at its next natural pause, exactly like typing to Claude Code while it works.
• Each turn posts its reply on the surface it came from: the Slack thread or DM, the PR or issue comment thread, the Linear issue. In a DM's top-level conversation the reply is a top-level message, and the emoji reaction lands on the message the turn answered.
• After a turn, the conversation stays warm for 10 minutes. While warm, the sandbox keeps running and its compute bills like any other sandbox time.
• After the window, state is snapshotted. The next message resumes the conversation, working tree and memory intact, in a fresh sandbox within seconds.
• Stopping a session stops the current turn only; the next message re-engages the same conversation.
• limits.run caps each burst of activity, and a resumed conversation runs on the budget remaining after prior spend. Trailing spend limits apply as always.

While a mention runs

Ellipsis acknowledges a mention two ways while the session works: a 👀 reaction on the triggering comment or message, and a one-line "Working…" reply linking to the live session. When the session succeeds, the "Working…" message is deleted; the agent's answer is the lasting reply. When it fails, the message is updated in place with a short reason and keeps the session link. A session cancelled by a pre-execution check posts the same style of message directly. Either way, a failed mention never disappears silently.

On Slack, the "Working…" reply is a toggle (Agents settings, "Post a Working… link in Slack", on by default): turn it off to keep just the 👀 reaction in threads. Errors and cancellations post either way.

Mention settings

The dashboard's Agents settings page controls who and what can summon Ellipsis on GitHub:

• Author and repository matrix. Human and bot authors are gated independently for public and private repositories. Human mentions trigger everywhere by default; bot-authored mentions (dependabot, renovate) are ignored by default, so a bot writing @ellipsis in a PR body does not spend your budget unless you opt in.
• Leading ... shorthand. A GitHub comment that starts with ... (or …) summons Ellipsis exactly like a leading @ellipsis. On by default; always leading-only, since ... is far too common mid-sentence.
• Require a leading mention. By default @ellipsis triggers anywhere in a GitHub comment body. Turn this on to require the comment to start with the mention.

Autocomplete on GitHub

GitHub's @-mention suggester only offers accounts with access to the repository, and app bots never appear in it. @ellipsis works without setup but does not autocomplete.

Two ways around that. The zero-setup one: start the comment with ... instead of a mention. A leading ... summons Ellipsis exactly like @ellipsis and needs no autocomplete at all (the shorthand is on by default; see Mention settings):

...why does the shift-trade expiry migration need a backfill?

The other: get real autocomplete by inviting the ellipsis-agent machine account to the repository as a read-only collaborator. Any repository admin can run:

gh api repos/splitshift-hq/splitshift-api/collaborators/ellipsis-agent -X PUT -f permission=pull

Ellipsis accepts the invitation within a minute. From then on, @ellipsis-agent autocompletes for everyone with access to the repository, and mentioning it starts a session the same way @ellipsis does.

• Collaborator access is per repository: run the command once for each repository where you want autocomplete.
• ellipsis-agent receives pull (read) access only.
• Ellipsis accepts invitations only from accounts with an active installation and declines everything else.
• On GitHub Team and Enterprise plans, an outside collaborator on a private repository uses a paid seat. Public repositories and Free-plan organizations are unaffected.

What to ask

Mentions fit work that needs repository context or integration actions:

@ellipsis why does the shift-trade expiry migration need a backfill?

@ellipsis fix the double-booking race from this thread and open a PR

The first gets an answer in the thread grounded in the migration code. The second produces a reply linking the pull request the session opened.

Next

Mentions are one of three trigger types; the same agent can also declare cron and react triggers.