How to answer codebase questions from GitHub, Slack, and Linear

"Why does the trade endpoint reject this?" gets asked in a Slack thread, a pull request comment, or a Linear issue. Answering it means someone with the codebase in their head stops what they are doing. The question is already in a thread; the answer can come back to the same thread.

Mention @ellipsis where the work lives and Ellipsis answers there, 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.

Steer it on the surface, not from the dashboard or the CLI. The agent posts every answer back to where it was mentioned, so that thread is the whole conversation: a message sent from anywhere else would be answered in the thread without the question ever appearing there. The dashboard and agent session connect open a mention session watch-only, and POST /v1/sessions/{id}/messages refuses it with 409.

@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.
• budget.session caps the conversation's cumulative spend, and a resumed conversation runs on the budget remaining after prior spend. Trailing spend limits apply as always.

While a mention runs

Ellipsis adds a 👀 reaction to the comment or message that summoned it, and nothing else: the agent's answer is the reply. On Slack the 👀 marks the message whose turn is pending, so it lands on the message you just sent rather than the top of the thread, and comes off once that message has been answered.

If the session fails, or a pre-execution check cancels it, Ellipsis posts a short reason with a link to the session, so a failed mention never disappears silently.

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.