PRCHD

Chat was never the hard part

Talking to a coding agent from your phone is easy now. Delivering a story from it isn't.

Between the ticket and the merge there's a branch to cut, a plan to read and approve, a diff to review, tests to run and a pull request to write. Every one of those steps lives at the desk the agent runs on. So the agent finishes in twenty minutes, and the story waits until you sit down.

PRCHD puts the whole job on your phone. The agent and the code stay where they are.

The team lane

The codebase, in a Slack channel

Install PRCHD once on a computer the team already owns and bind a Slack channel to a project. Product, support and QA ask the code directly, and the engineers they would have interrupted keep working. Nobody creates an account, installs an app or pairs a phone. Joining the channel is the whole onboarding.

Ask. Anyone in a bound channel mentions @PRCHD with the question they'd have taken to an engineer. Before the session opens, the checkout is fast-forwarded from origin. The agent reads the real code in Act mode, uses the team's own tools, and answers in the thread. Then the answer signs itself:

answered from payments-api @ 4f2c9ab (main) · Act mode

The signature names the repository, the commit and the mode, so anyone reading the thread later knows exactly what the answer was based on.

A follow-up in the thread continues the same session, with every human message posted since the agent last replied. Act mode is structural here, not a setting: a question can't be turned into something that writes to the repository.

Run. /prchd run <recipe>: <input> starts real work, and only in private channels the operator has enabled for it. Public channels can never run anything. The run announces itself, threads its result, and leaves a branch to review.

React. When something happens elsewhere (a crash, a red build, a ticket moving to Ready) a webhook trigger turns it into a run, under the posture the operator already chose. A trigger can't name its own prompt, mode or target, so whoever sends the webhook can't choose what runs.

Recipes. A recipe is a prompt with a fixed posture: a fresh worktree or read-only in the project root, which mode, which model, what becomes of the result, and whether the run gets the project's tools at all. One recipe can fire four ways: on demand, on a schedule, from Slack, or from a webhook.

Automations. Scheduled runs never stack: a nightly suite that overruns its next slot doesn't start a second copy. A missed window catches up once, not once for every hour the machine slept. A run can ask when it last succeeded, so "since last time" means something.

Triggers. Webhooks from GitHub, Sentry, Stripe, ClickUp or anything that can send a request. The public URL lives on PRCHD's service, which seals each delivery to the host's own key and stores only ciphertext. The host collects deliveries outbound, so nothing on it listens on the internet.

A small verifier you write decides whether each delivery is rejected, ignored or run. It runs in its own process with a two-second budget, and gets its input on stdin, because command-line arguments are readable by anyone running ps. Failed runs wait in a dead-letter queue for replay.

PRCHD ships no vendor integrations to maintain. Any tool your agent can already use works here on day one.

Governance

• The channel is the whole grant. Membership is the entire access list. Remove someone from the channel and they're removed from the product. No accounts, no role matrix, no seats.
• A channel that turns public loses its right to run. Channels shared with other companies are refused. Bindings are re-checked on reconnect, never assumed.
• One computer can serve several Slack workspaces, kept apart in the schema: every row is keyed by workspace, and a project answers in exactly one of them because the schema can't express anything else.
• Replies wait in a durable outbox through rate limits and restarts. Questions older than fifteen minutes when the host comes back get told why they went unanswered, instead of starting a surprise run.
• Every interaction leaves an audit event with no content in it.

The numbers

From the repositories, as of 30 September 2026.

• 1,089 commits in 96 days, from 26 June to 30 September 2026. One author.
• About 242,000 hand-written lines across host, mobile app, service and website, not counting generated code. 39% of the product code is tests: about 3,480 of them.
• Three agents, three platforms, one contract of 116 gRPC calls.
• Seven releases, from 26.8.1 in August to 26.9.4 on 30 September.
• Built with itself. From 13 July, PRCHD's own features were built in PRCHD workspaces: 50 workspace branches merged into its main branch, and 96 workspace branches across six of my repositories.

What's next

• The Floor. A desktop view for a small team running eight to twenty agent sessions. It starts from one idea: agents multiply output until the bottleneck is human decisions, so the interface's job is a queue of decisions routed to the right person. Status: specified, not built.
• No Tailscale to install. A network PRCHD manages for you. Two candidates, settled by spikes before any code: an embedded Tailscale node (that's why I built libtailscale), or iroh, which needs no control plane and adds less to the binary.
• Windows and Linux hosts. Not yet, and on purpose: the macOS host has to be right first.

What this project says about how I work

• The spec came before the first line of code, and it's still the contract.
• The trust boundary was designed first. The features came second.
• One typed contract, shared by all three platforms, so they can't drift apart.
• It ships with its limits written down, including the ones a marketing page would rather hide.

• prchd.app
• prchd.app/teams
• App Store
• Google Play
• github.com/velzosoft/prchd/releases
• x.com/prchd_app