⌥
GitHub
Where the work lands
Installed as a GitHub App scoped to the repositories you pick. Elisha clones, branches, commits, and opens pull requests. It never merges.
Contents (read/write) · Pull requests (read/write) · Metadata (read)
Integrations
Connected to the tools you already have
Elisha doesn't ask your team to move anywhere. It shows up in the board, the channel, and the repository you already use — and it only ever gets the access it needs to do the job.
Eight surfaces, one engineer
Three of these are where work comes in. The rest are context — the things a human engineer would go and look at before writing the fix.
N
Notion
Where the work is planned
Point Elisha at a board and it reads cards as tasks, then writes status back to the card as the run progresses — in sandbox, shipped, or needs a person.
Only the pages and databases you share through Notion's own consent screen
#
Slack
Where the work is reported
Assign a task by messaging Elisha in a channel or a thread. Progress, questions, and the finished pull request come back in the same thread.
Bot token · posts messages and uploads run evidence to the channels it's invited to
▲
Vercel
Where failures surface
Elisha subscribes to deployment errors, so a failed build can become a task without anyone opening a dashboard. It reads projects and deployments; it does not deploy.
Read access to Projects and Deployments · deployment.error webhook
G
Google Workspace
Context that lives in docs
Reads the spec in the doc and the thread in the inbox when a task points at one, so the ticket isn't the only thing it knows.
Read access, granted per workspace
◆
Figma
What the change should look like
For UI work, Elisha reads the frame the task links to and compares its own screenshots against it before opening the pull request.
Read access to the files you share
⌁
PostHog
Whether it actually mattered
Pull the numbers behind a bug report — how many sessions hit the error, which release it started in — and attach them to the pull request.
Read-only queries · charts uploaded privately to Slack
△
Google Cloud
Logs, when a bug isn't in the code
A read-only surface: list, describe, get, and read logs. Enough to find the failing request; not enough to change anything.
list · describe · get · readLogs — no write access of any kind
Setting them up
Connecting an integration is an OAuth handshake and nothing else — you approve the scopes on the provider's own consent screen, and the token comes back encrypted at rest. GitHub, Notion, and Slack are required to finish onboarding; the rest are optional and can be added later from Settings.
You can disconnect any integration at any time. Revoking the grant on the provider's side works too — Elisha treats a rejected token as a disconnected integration and says so rather than failing quietly.
Don't see the tool you use?
Tell us what it is. The list above is what a small product team needed first, not a finished map — hello@elisha.dev.
Connect one, and try a task
GitHub takes about a minute. You can add the rest whenever you need them.