Workflows

The queue nobody has time for

Elisha is at its best on the work that is real, small, and permanently second in line — the bug in #support, the red deploy, the card that's been on the board for three sprints.

What Elisha picks up

Each of these starts somewhere your team already works, and each ends with a pull request and a message on the same surface.

A bug reported in Slack

Someone describes what broke in #bugs or #support. Elisha reproduces it in a browser, finds the cause, patches it, adds a regression test, and replies in the thread with the pull request.

TRIGGER · MESSAGE IN A CONNECTED CHANNEL

A deployment that failed

Vercel reports a build error. Elisha reads the build log, works out whether the break is in code the last change touched, and opens a fix — often before anyone notices the deploy is red.

TRIGGER · DEPLOYMENT.ERROR WEBHOOK

N

A card that reaches the top of the board

Elisha watches the Notion database you point it at. When a card is ready, it picks it up, moves it to In progress, and writes the outcome back to the same card.

TRIGGER · CARD STATUS ON A NOTION BOARD

The small stuff that never gets done

Copy fixes, empty states, a missing loading spinner, a validation message that says the wrong thing. Individually too small to interrupt anyone; collectively the reason the product feels rough.

TRIGGER · ANY OF THE ABOVE

A design that changed in Figma

The task links a frame. Elisha reads it, makes the change, screenshots its own result, and puts both images side by side in the pull request so the reviewer can see the difference.

TRIGGER · TASK LINKING A FIGMA FRAME

Work on a schedule

Recurring jobs — dependency bumps, a weekly sweep of the error tracker, a scheduled report. Elisha runs them on the schedule you set and only speaks up when there's something to say.

TRIGGER · CRON

And what it hands back

Some work should not be done by an agent working alone, and pretending otherwise is how you end up reviewing forty files of confident nonsense. Elisha hands a task back when:

  • The ticket is ambiguous in a way that research against the repo can't settle.
  • The change is an architectural decision — a migration strategy, an auth rewrite, a choice between two designs that both work.
  • Doing it properly needs context that lives only in someone's head.

When it hands work back, it says specifically what it needs. “Blocked” is not a useful answer; “there are two coupon code paths and I can't tell which one the customer hit” is.

Point it at the oldest thing on your board

The one that's been sitting there long enough that everyone has stopped seeing it.