What ships today

Everything it does. And the edges it keeps.

Know where it stops before you install it. Every capability sits beside what it depends on, and every limit carries the same weight as a feature.

For the developer

Leave the desk

An agent needs you for a minute at a time — a question, the diff, the tests, the merge. A personal host brings that minute to your phone: one computer, one phone, your own tailnet, and the agent still working in the real checkout.

Pairing, hosts, and access

Pair once by QR or a typed code, then manage each device from the computer or the phone.

Short-lived, single-use pairing code
The phone pins the computer’s stable public key
The computer keeps only a hash of the bearer token
Several computers in one filterable project list
Immediate device revocation and live-stream drop
Face ID, Touch ID, or passcode app lock

Projects

A project is one local git repository on one computer, attached where it already lives.

Node, Rust, Go, Flutter, Python, and Ruby detection
Workspace-aware monorepo package roots
Editable setup, run, and archive scripts
Command buttons with working directories and ports
Per-project agent and notification defaults
Guarded detach with a preservation receipt

Workspaces

Each piece of work owns its own worktree, branch, snapshotted base, processes, and git state, so parallel work stays apart.

Chat-first, terminal-first, or GitHub issue-backed
Several chats and terminals in one tab strip
Persisted drafts, unread state, and closed transcripts
Merge & Close or confirmed Discard & Close
Failed merges preserve the worktree and branch

preparingThe setup script is running

activeNormal work and review

needs attentionSetup failed; inspect or retry

needs mergeClose hit a conflict; worktree preserved

closedMerged or explicitly discarded; history readable

Agents

Claude Code, Codex, and Grok share one set of controls — model, reasoning effort, and mode — sourced from whichever backend you pick.

Ready, needs login, and not installed states
Model catalog advertised by each backend
Backend-specific reasoning effort rungs
Plan, Act, or Work mode
Attach files, mention paths, and pin context
Stop, steer, context meter, and compaction where supported

Model, effort, and Plan, Act, and Work controls sourced from the selected backend

Review

You review the real thing: your computer renders live file and diff views from the workspace being changed.

Combined and per-file diffs
Fork-point and last-commit anchors
Whole files, commit history, and commit-scoped diffs
Syntax highlighting rendered on your computer, in both palettes
Markdown preview and source mode
Span selection with a note for the agent
Stale-safe single-file revert

Host-rendered diff of GridScreen.tsx with the row-count header change

Execution

Know it works before it lands. Commands, tracked processes, and interactive terminals stay attached to the workspace.

Command buttons grouped by purpose
Ad-hoc commands and a real PTY
Completed, stopped, and crashed outcomes
Replayable ANSI output after reconnect
Allocated port for the project run script
Open the live app over your tailnet

Git and GitHub

Land the work from wherever you are. Local git is built in; issues, pull requests, and PR review need a GitHub remote and the gh CLI signed in on your computer.

Update from base with abort or agent-assisted conflict handling
Editable drafted commit messages
Push with remote and ahead or behind state
Issue-backed workspaces and editable trailers
Editable PR title, body, base, and draft flag
Automated PR review from a disposable worktree
Host-owned posting with repaired anchors and duplicate guards

Staying informed

Know when you’re needed without watching for it. Activity separates what needs you, what is running, and what happened recently.

Cross-host and multi-project filters
Opt-in push per device and project
Daily quiet hours in the phone’s timezone
Lock-screen copy that names the project and workspace
Closed-vocabulary payloads with opaque routing ids
Authoritative state read from your computer on open

For the team

Ask the code

Questions only the code can answer used to mean interrupting an engineer. A team host answers them in Slack: one computer the team owns, one Slack workspace per project, and membership of a bound channel as the whole grant. The operator sets it up once; everyone else just asks.

The Slack connection

The team’s own custom Slack app, installed from a published manifest, connected outbound from the machine.

Socket Mode: the host opens the connection and nothing listens
A project answers in exactly one Slack workspace, or none
Adding a project to a second Slack workspace is refused by name
Replies queue in a durable outbox and drain when the socket returns
A dead token parks the Slack workspace instead of reconnecting into a lockout
The dashboard states the connection state in words

Channel bindings and their two switches

A binding points one channel at one project. Two switches decide what that room can do and who sees the traffic.

Runs: on only for a private channel the operator enabled
Visibility: a private binding keeps its activity on the computer
A channel speaks for exactly one project
Only a project already added to that Slack workspace can be bound
Channels shared with another organization are refused
Every reconnect re-reads each binding against Slack’s own answer
A private channel made public loses its run permission automatically
A channel that became externally shared is unbound

Host dashboard listing each bound channel with its project, run permission, and feed visibility

Inquiries

A mention opens an Act-mode inquiry in that project’s checkout. It reads the working tree and leaves the repository exactly as it found it.

Reacts, posts “Working on it”, then edits the answer in
Footed with the project, commit, branch, and mode
Follow-ups in the same thread continue the conversation
The question reaches the agent exactly as typed
A channel can pin the model and reasoning effort its answers use
A mention in a channel that is not bound is silent, and recorded

/prchd run

A stored recipe, started from a channel by anyone in it.

Announces the recipe, the project, and who asked
Threads its result under that announcement
Every run is attributed and visible to the channel
Runs require a private channel the operator enabled
A public channel can never be runs-enabled
An ask-only channel says so rather than failing quietly
The channel supplies input text; mode and target come from the recipe

status, recipes, and help

Three slash commands that answer only to the person who typed them.

/prchd status — what this channel is bound to and whether runs are on
/prchd recipes — what reaches this project
/prchd help — the whole vocabulary, which is short
The channel itself stays uncluttered

#payments-engSlack

Sam Prescott14:06
/prchd status

PRCHDAPP14:06

project     payments-api
channel     #payments-eng · private
connection  connected
runs        enabled
inquiries   Act mode · pinned model

The Slack notifier

A built-in MCP server that lets a run report itself into a channel rather than only replying where it was asked.

List channels, find a person, post, DM, edit a message, upload a file
Ships off; enabled per project
The bot token reaches the agent as a Keychain account name, never as a value
This is what turns a scheduled recipe into a delivered report
Long answers split at paragraph boundaries, up to four messages, then a notice
About one message per second per channel, with retry and backoff

The audit trail

Every Slack interaction lands as a content-free event beside the chat’s own transcript.

slack.* events name the Slack workspace, channel, and asker’s Slack id
Question received, run requested, refused, reply posted, reply failed
A refusal records its reason in plain words
Every user-triggered event records the surface that caused it
The append-only event log is the source of truth; every view is a projection

Visibility isolation

Two teams on one computer, kept apart — and a developer’s own feed kept clear of the team’s traffic.

Each binding carries a visibility switch
A private binding’s activity stays on the computer entirely
The device boundary drops it in all four directions
A team host with no paired device sends no push at all
Its notification path is the Slack thread the work was asked in

Runs while you’re elsewhere

Already done

Crash triage, the morning brief, the nightly suite: unattended work that used to wait for someone to find time is finished when people arrive. Write a recipe once and fire it four ways — its posture belongs to the recipe, whichever way it starts.

Recipes

A recipe is a title, a description, a prompt, and the posture it runs under — a record you author in PRCHD, rather than a file anything scans a repository for.

Kind: a fresh worktree off the latest base, or the attached project root
A project-root recipe runs in Plan or Act only
Mode: Plan, Act, or Work, fixed by the recipe
Deliverable: keep the worktree to review, or drop it as scaffolding
A failed run keeps its worktree as evidence; run history survives cleanup
Tools: whether this run wants the project’s built-in MCP servers at all
Scope: one project, or every project on the computer
Optional model and reasoning-effort pins

Mode	Your repository	Tools with effects	Typical use
Plan	Reads only	None attached	Research, proposals, design review
Act	Reads only	Yes — file a ticket, post, browse, query	Every Slack question; triage that files a story
Work	Writes, runs, commits	Yes	Recipes that produce a branch

Act leaves your repository exactly as it found it, and still gets things done in your other systems. The prompt itself reaches the agent verbatim, and the skills the agent already discovers in the repository, the repository’s own instructions, and its hooks all apply exactly as they would in a normal session.

Alongside the team’s own recipes, PRCHD ships built-ins that are part of how the product works — naming a workspace, drafting a commit message, drafting a pull request, reviewing one, framing a Slack thread, and reading the work tracker. Their prompt text is editable and overridable per project, resolving project, then computer, then shipped default, one field at a time.

Overnight suite

Runs the full test suite on the latest base and writes up what broke, with the change that most likely did it.

kind: workspace
mode: Work
deliverable: worktree

Crash triage

Reads a crash against the real code, then files a story through the tracker the agent already reaches.

kind: project
mode: Act

Monday shipped list

Reads last week’s merges and writes the leadership summary in plain language, then posts it.

kind: project
mode: Act

Three examples. Each is a prompt plus a posture that a team writes for itself.

Recipe editor with kind, mode, deliverable, tools, scope, and the model and effort pins

One recipe, four ways to fire it

One launcher sits under all four, so a recipe behaves the same whichever one starts it.

The surface	What starts it	What the caller supplies	The guardrail
On demand	Run now, on the computer or the phone	Nothing, or a line of input	The recipe’s own posture, unchanged
From Slack	/prchd run <recipe>: <input>	Input text	A private channel the operator enabled for runs
On cron	Five fields in the host’s timezone	Nothing — the prompt reads the fire	A slow run joins the one in flight rather than stacking
From a webhook	A delivery your verifier admitted	Up to 24 short variables	Built-in recipes are refused a URL outright

Automations

Put recurring work on a schedule: standard five-field cron in the host’s timezone, per project, at minute granularity.

A schedule can run a command, a command button, or a recipe
A slow run never stacks; the next fire joins the one in flight
Run now uses the same path and leaves the schedule as it was
A window missed while the computer slept is skipped, not backfilled
Catching up once on start is opt-in, per automation
Every fire records start, end, outcome, summary, and what it produced
The summary outlives the worktree, so a discarded run is still readable
Prompts interpolate {{fired_at}}, {{last_run_at}}, and {{last_success_at}}
A prompt can tell whether this fire was cron or manual
An absent value reads as the word never, not as a blank
A schedule whose recipe was deleted says so rather than failing quietly
Deleting a recipe is refused by name while an automation still points at it

0 9 * * 1

Every Monday at 09:00, in the host’s timezone.

runs: Monday shipped list → posted by the Slack notifier

New automation sheet scheduling a nightly test command with kind and repeat controls

Webhook triggers

Let the event start the work. A trigger binds one project, one recipe, and one verifier to a URL an external provider can call.

The URL lives on the public PRCHD service, not on your computer
Every delivery is sealed on arrival — ECIES over P-256, ciphertext at rest
The host collects by polling outbound, with no port open
A verifier you wrote runs in a fresh process under a two-second timeout
Three verdicts: not authentic, uninteresting, or worth a run
Only the third can supply a dedupe key, a shaped body, and variables
Up to 24 short variables the prompt interpolates as words
Admission is ordered by cost: verify, dedupe, size, depth, admit
Every rejection is recorded with a reason in plain words
Repeats dedupe; bursts are bounded by queue depth and two concurrency limits
A delivery older than three hours expires before it starts, not mid-run
Failures dead-letter and stay replayable by hand for a week
A replay re-runs the payload, not the verifier
The payload is deleted as the run starts

01The eventA crash, an alert, a red build, a ticket movingtheir system
02Sealed on arrivalECIES over P-256; ciphertext at restPRCHD service
03Collected outboundThe host polls for it — triggers need no inbound portyour computer
04Your verifierFresh process, 2 s, the exact transmitted bytesyour computer
05The recipeA stored prompt under its own posture, with your variablesyour computer
06The deliverableA story filed, a branch left, a summary postedyour computer

The editor ships starter snippets for common providers — a signature check, a bearer token, a threshold — and they are text you edit rather than a provider registry. A trigger carries no provider id, so an internal tool that posts a webhook is the same amount of work as any well-known one.

A trigger with its last deliveries: ran, ignored, and rejected with a reason

The numbers

The limits an evaluator asks for, in the units they ship in.

Slack

Answer length: Split at paragraph boundaries, up to 4 messages, then a notice
Outbound pacing: ~1 message per second per channel, durable outbox, retry with backoff
Missed-mention backfill: Mentions from the last 15 minutes are answered; older ones get a “missed” reply
Vocabulary: One mention and one slash command — the whole vocabulary

Triggers

Verifier timeout: 2 seconds, in its own process, per delivery
Verifier variables: Up to 24, short scalars, interpolated as words
Body after shaping: Up to 64 KB; a larger body is refused, not truncated
Queue depth per trigger: 200 pending or running, then saturated
Concurrency: Separate limits for worktree runs and project-root runs, set per computer
Stale delivery: Expires at 3 hours, before it starts rather than mid-run
Dead letters: Replayable by hand for 7 days; rejection diagnostics kept 1 day, body-free

Host

Cron: Standard five fields, host timezone, minute granularity
Environment variables: 64 per scope, 8 KB per value, write-only, Keychain-sealed

The edges we keep

Where it stops

Each limit is a decision with a reason behind it, so each one gets the same weight as a feature.

The shape of the product

What PRCHD is, stated as plainly as the feature list above it.

Access is a device or a channel
A device token on your own tailnet, or membership of a bound Slack channel, is the whole grant. PRCHD has no accounts, roles, or per-person permissions, so someone joining means nothing to provision.
Shared answers, not shared editors
A workspace is one worktree, one branch, one live session, with no shared buffer or cursor. Slack is where the team asks and starts work; hands-on editing happens on a developer’s own computer.
Runs on the computer you own
Repositories are read where they sit, and nothing is uploaded to be indexed. PRCHD hosts no repositories and runs no compute of its own.
macOS on Apple Silicon
That is where the host runs today. Windows, Linux, and Intel builds are not out yet.
New work starts when the computer is reachable
Work already running carries on while you’re away. Starting something new needs the computer reachable — the phone keeps no queue to send later.
Voice is your keyboard’s dictation
Dictate with the phone keyboard you already use. PRCHD runs no speech service of its own.
The mode is chosen before the turn
Plan, Act, or Work is picked before the turn runs and holds for the whole turn, in place of a prompt for each tool call.
Merge conflicts finish at the desk
A close-time conflict keeps the worktree and the branch intact until you resolve it in your own editor.
Previews stay on your tailnet
A dev server opened from PRCHD is reachable over your tailnet, and only there.
Usage is reported in tokens
Context and token usage are reported. PRCHD doesn’t estimate monetary cost.
Model access is yours
PRCHD drives the agent CLIs already signed in on the machine, under your own or your team’s accounts, and resells no model access.
Tools come from the agent’s own setup
Third-party tools reach the agent through its own MCP configuration; PRCHD has no MCP client of its own. The reach is as wide as your agent’s, and none of it is ours to certify.

Where Slack and triggers stop

The details an operator asks about before binding a channel or pointing a webhook at a trigger.

The Slack app is the team’s own
Installed into your Slack workspace from a published manifest. Socket Mode apps can’t be listed in the Marketplace, so setup is pasting two tokens rather than one click.
Asking happens in channels
The bot’s messages tab is read-only, and only a mention starts a turn.
Slack is words, not widgets
A mention and one slash command are the entire vocabulary — no buttons, modals, home tab, or message shortcuts to learn.
One reply, edited in when done
A thread gets one “Working on it”, then the answer edits itself in. A long run looks quiet while it works.
Reconnect reads back channel mentions
Recent channel-level mentions are read back when the computer reconnects. A follow-up posted inside a thread while it was offline is not.
A trigger runs a stored recipe
It supplies input to a recipe the operator wrote and runs under that recipe’s posture, with no prompt, mode, or target of its own. That is a limit, and it is the point.
The first real delivery is the test
In place of a test button, a new trigger’s URL goes live immediately and answers every delivery as ignored until its verifier exists — so you write the verifier against real bytes.
The verifier’s isolation is a contract
Your own code runs in its own short-lived process with the obvious globals removed, to catch accidents. It is a contract, not a jail for code you didn’t write.

Read the security mechanisms →Check the requirements →Read the FAQ →

Where your code lives

The computer you own is the computer that runs.

Repositories, worktrees, prompts, transcripts, diffs, command output, attachments, environment values, and the event log stay on the computer you installed PRCHD on — the one that already has your code and your tools. The agent works there, so there is nothing to copy into a hosted environment and nothing uploaded to be indexed.

One small public service handles what a computer with no open port can’t do on its own: it enrolls your computer’s identity, forwards short push notifications, and holds webhook deliveries until your computer collects them. Each delivery is sealed to your computer’s public key the moment it arrives, so the service only ever holds ciphertext, and it is never in the path of your work.

Your checkout stays where it isOutbound only — nothing listensRead the mechanisms →

Your computer already has the code.

Give it a remote control: install PRCHD there, then pair your phone over your tailnet, bind a Slack channel for the team, or both.

Download for Mac

App Store Google Play

Set it up for yourself →Set up a team host →