How it works
Ticket in. Pull request out.
Elisha is not a chat window that returns snippets. Every run ends the same way: a branch pushed, a pull request opened against your default branch, and a plain-English note on the surface you assigned the work from.
The run, step by step
The same eight steps happen on every task, whether it arrived as a bug report or a feature request.
You assign the work where you already write it down
A card on a Notion board, a message in a Slack channel, a GitHub issue, or a phone call. There is no ticket template and no special syntax — Elisha reads the request the way a teammate would.
The task gate researches before it decides
Elisha clones the repository and reads it against the ticket before touching a single file. Then it does one of three things: accept the work, ask one question that sharpens a vague request, or hand the task back because it genuinely needs a person.
Everything happens in a throwaway sandbox
Each run gets its own isolated environment and a short-lived, scoped token. Nothing runs on your machine, nothing runs on your default branch, and the sandbox is destroyed when the run ends.
Bugs get reproduced before they get fixed
For a bug report, Elisha drives a real browser against your app to reproduce the failure first. A patch that doesn't change what the reproduction does isn't a fix, and the run says so instead of claiming success.
Your test suite is the judge
Elisha runs the project's own test command, reads what comes back, and retries on failure. Where the change deserves one, it writes the regression test that would have caught the bug.
A review pass reads the diff again
Before the pull request opens, the change is re-read as a diff — the same way a reviewer would see it — to catch the leftover debug line, the half-renamed variable, the file that got touched for no reason.
A real pull request, against your default branch
The output is a branch and a pull request with a written description, the files it touched, the checks that ran, and before/after screenshots where the change is visual. A person still merges it.
It reports back where you asked
Status lands on the surface the work came from — the Slack thread, the Notion card, the GitHub issue — in plain English. The person who reported the bug finds out it's fixed without chasing anyone.
What a run can and can't touch
The honest way to think about autonomy is blast radius. Here is the whole of it.
| A run can | A run cannot |
|---|---|
| Edit files in its own sandboxDestroyed when the run finishes. | Merge anythingNo code path in the worker merges a pull request. |
| Push a branchScoped to the repositories you selected. | Delete your dataCloud access is list, describe, get, and read-logs only. |
| Open a pull requestAgainst your default branch, for review. | Touch production configNothing in a run deploys or changes environment settings. |
| Write status backTo the Notion card, Slack thread, or issue it came from. | Reach another customerCredentials and storage are scoped per organization. |
More detail on isolation and credentials in Security.
Questions people ask first
Can Elisha merge its own pull requests?
No. Elisha opens pull requests; a person reviews and merges them. Nothing in the worker merges anything.
What if the test suite is already failing?
Elisha reports the pre-existing failures rather than claiming its own change is green, so you never get a pull request whose passing checks are borrowed from a broken baseline.
How long does a task take?
It depends entirely on the task and the size of the repository. A one-line guard on a well-tested codebase is minutes; a change that needs a browser reproduction and several test cycles takes longer.
Give the queue to someone else
Connect GitHub, point Elisha at a board or a Slack channel, and assign it the first thing on the list.