How to build a custom Slackbot with access to your code

A mention trigger with platforms: [slack] turns Ellipsis into your team's Slackbot. It is not a chat wrapper around a model: every conversation runs in a cloud sandbox with your repositories cloned and gh authenticated, so the bot answers from the code in front of it, opens pull requests, and runs your internal tooling, all from Slack.

Prerequisites: the Slack integration connected and the GitHub App installed (Integrations in the dashboard).

ellipsis:
  version: v1
  name: Team Slackbot
  description: Answers Slack mentions and DMs with the Splitshift codebase on hand

claude:
  system: |
    You are Splitshift's engineering Slackbot. Answer questions from the
    code in front of you: cite files and functions, never guess. When
    asked for a change, make it and open a pull request with gh. Keep
    Slack replies short; put detail in the PR description.

trigger:
  type: mention
  platforms: [slack]

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

budget:
  session: 2.00
  day: 20.00

Commit this as agents/slackbot.yaml and it is live when it merges to your default branch. An enabled mention config claims its whole platform: this agent now answers every Slack mention and DM instead of the built-in responder, with the repositories, instructions, model, and budget you chose. Slack conversations have no repository of their own, so the sandbox clones exactly what sandbox.repositories declares.

Two ways to reach it

The same agent is spawned two ways:

• Channel mentions. @ellipsis in a channel starts a conversation in that thread. Replies in the thread continue it, no repeat mention needed.
• Direct messages. A DM needs no mention at all. The DM's top-level messages are one 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.

Both are durable conversations: the agent keeps everything it already said and did as context, stays warm for 10 minutes after each turn, and resumes with working tree and memory intact after that. A 👀 reaction and a "Working…" link acknowledge each mention while the session works. Messages from other Slack bots are ignored unless they tag @ellipsis directly, so automation noise never burns budget.

It works in your codebase

Because the repositories are cloned into the sandbox, answers come from the code, not from a summary of it:

@ellipsis the tip-pool report rounds to whole dollars, cents get dropped. Can you fix it?

Found it: TipPoolReport.total is computed with integer division in
splitshift-api/reports/tip_pool.py. Opened splitshift-hq/splitshift-api#873
switching the split math to cents end to end, with a regression test for
the three-way split case.

The pull request is real work from the session's sandbox: the agent edited the code, ran the tests, and opened the PR with gh, then linked it in the thread. A follow-up reply in the same thread ("also backfill last week's reports") lands in the same conversation, with the diagnosis and working tree already in place.

Lock it down with a read-only token

If you want a Slackbot that can never go rogue, narrow its GitHub token:

sandbox:
  github_token:
    permissions: read_only

read_only grants read access to contents, issues, metadata, and pull requests. The restriction is enforced by GitHub at the moment the token is minted, so nothing running in the sandbox, including a prompt injection, can exceed it. A read-only bot still answers every code question; it cannot push, merge, or open pull requests. One enabled config answers Slack at a time, so pick the posture that fits: read-only for a Q&A bot, full permissions for one that ships fixes.

Bring your internal tools

The sandbox is yours to shape. Install your internal CLIs and scripts with sandbox.image, and inject their credentials by name from the write-only variable store:

sandbox:
  image:
    dockerfile_append: |
      RUN npm install -g @splitshift/reporting-cli
  variables:
    - name: REPORTING_API_TOKEN

Now the bot does not just read the code, it runs it. A non-technical teammate can DM:

how many shift trades completed last week, split by region?

and the agent runs the reporting CLI inside the sandbox and replies with the numbers in the thread. Anything an engineer would run from a terminal (a report, a data export, an internal admin script) becomes something anyone in Slack can ask for, without the answer ever leaving your governed environment.

Budgets and spend

Every conversation runs under the config's budget: budget.session caps a conversation's cumulative spend across its turns, and budget.day, budget.week, and budget.month cap the agent's trailing spend. A conversation that hits its cap stops cleanly and records budget_hit, distinct from an error, and a blocked session never creates a sandbox. Each turn records its cost, so a chatty week is a line-item breakdown, not a surprise. Size budget.session for a conversation's lifetime, not one answer: a busy support thread accumulates spend over days. Details in Budgets.

Every conversation is searchable

Each Slack conversation is a recorded session in Ellipsis: the full transcript of what the agent read, ran, and replied lives in your session history alongside every other agent session. That makes the Slackbot a provenance layer for decisions that would otherwise evaporate in Slack scrollback:

agent session search "tip-pool rounding bug report" --source mention

Provenance questions become queries: "where did the bug report that led to the tip-pool fix come from?" is a search over mention sessions; "what was the motivation for splitting in cents instead of dollars?" finds the conversation where the tradeoff was discussed; a PR-shaped query like splitshift-hq/splitshift-api#873 finds the exact session that opened it. Search covers step text, recap text, created pull requests, and semantic similarity, from the dashboard's Sessions page, the API, or the CLI.

The loop closes on itself: the agent CLI ships inside every sandbox with a session-scoped token, so you can DM the bot the provenance question and it searches the history for you.

Next

Mention mechanics in depth (autocomplete, the ... shorthand, mention settings) are in How to spawn an agent session by mentioning @ellipsis. Shape the sandbox further in How to set up your agent's cloud development environment.