About Relay
Relay exists for teams that serve clients in Slack and build somewhere else. It keeps the two conversations connected without exposing every internal thought or asking somebody to copy updates all day.
Automation should carry context—not remove judgment.
A small client request rarely stays small. It needs triage, an owner, a question, a pause, a fix, and a useful close-out. When those steps happen across channels, the work becomes invisible on one side and noisy on the other.
Relay turns that gap into a controlled route. Every top-level client message becomes a task candidate. Every meaningful status change can return to the original thread. The mapping remains intact for the life of the work.
Relay does not forward every engineering message to the client. Normal discussion stays internal. A teammate has to use !ask or !reply to cross the boundary.
It also does not turn the spreadsheet into a second database. Google Sheets is a readable mirror; Slack and the Relay ledger remain the place where work changes.
Product principles
The client hears about ownership, meaningful progress, blockers, questions, and completion—not every timer event or internal note.
The top card is re-rendered after every change. The SQLite ledger keeps task state, work sessions, and an append-only event history.
A reaction claims the work. Assignment changes are explicit. Starting another task pauses the first so two clocks cannot run at once.
The team keeps exact effort and rich internal context. The client gets resolved names, plain language, and rounded time when work is done.
What it is made of
Relay is a TypeScript service using Slack Bolt in Socket Mode, SQLite for durable task state, a small authenticated HTTP API, and an optional Google Sheets mirror.
Read the implementation
Start with the workflow in the README, then inspect the shared transition path that keeps task state and client updates together.