For the team
HEAD.The answer is in the code, and today getting it means interrupting an engineer. Install PRCHD once on a computer your team already owns and bind a Slack channel to a project. Anyone in that channel can then ask the code directly, from the Slack they already use — and the answer comes back stamped with the commit it was read from.
@PRCHD does a declined card retry, and how many times?
eyes · PRCHD
Working on it…
Yes — declines classified as soft (issuer timeout, insufficient funds) are retried up to 3 times with exponential backoff at 1m, 5m, and 30m. Hard declines (stolen card, invalid number) are never retried.
The retry budget is per charge, not per customer, and it is enforced in billing/retry_policy.rb rather than at the gateway.
What actually changes
It is the round-trip to the one person who has the context. Every “does our webhook retry?” becomes an interrupt, a thread, a meeting, or a wiki page that is wrong by Thursday.
| Today | With a team host |
|---|---|
| “Who knows the payments code?” — find them, wait, interrupt | Ask in #payments; the answer lands in the thread while the engineers keep coding |
| A crash report sits in a queue until someone triages it | The crash fires a webhook, and the triage recipe your team wrote reads the real code and files the story |
| The weekly report is somebody’s Sunday evening | A scheduled recipe writes it and posts it |
| An exec’s question travels down three layers and back | The exec asks in a channel and reads the answer |
| Answers come from a wiki that describes last quarter’s code | Answers come from HEAD, footed with the commit they were read from |
| Giving someone answers means giving them repository access | Channel membership is the whole grant |
| Automation lives in CI YAML and can only run tests | Automation is a prompt with a posture, so it can do judgement work |
Today the fastest way to get this answer is to interrupt the person who knows.
With a team host, the question still gets asked, and the person who knows keeps coding.
Who can ask
Ask · Run · React
Mention @PRCHD in a bound channel with the question you would have taken to an engineer. An agent reads the real checkout, uses the team’s own tools, and answers in the thread.
Act-mode inquiry in the project root
The jobs your team repeats, written once as recipes with a fixed posture. Start one from a private channel, a cron schedule, or a webhook.
/prchd run <recipe>: <input>
When something happens elsewhere — a crash, an alert, a red build, a ticket moving — a webhook trigger turns it into a run.
Trigger URL → verifier → recipe
The footer
A wiki page can’t tell you when it stopped being true. Every answer here names the project, the commit, the branch, and the mode it was read under, so nobody has to ask how current it is.
/prchd run Repro harness: PROD-882
Running Repro harness in payments-api — asked by @sam
Reproduced. A failing test now covers the decline path that drops the retry counter when the issuer returns a 402 without a decline code.
branch prchd/repro-prod-882 tests 1 failing (spec/billing/retry_policy_spec.rb:88) kept worktree — there is work to review
The four ways work arrives
Work reaches the team host four ways, and two of them start on their own. Every one ends in the same place: a real agent session, on real code, on the team’s own computer, recorded in a durable event log.
A mention in a bound channel opens an Act-mode inquiry in that project’s checkout.
/prchd run announces itself in the channel and threads its result under that announcement.
When an event happens elsewhere, a webhook trigger starts the run: one project, one recipe, and one verifier bound to a URL.
For the jobs that should just happen: five-field cron in the host’s timezone, per project, at minute granularity.
A webhook never points at your computer
What the agent can actually reach
A chatbot over an index answers from a stale copy of the words. The agent here has the repository itself, a shell, a browser, and the team’s other systems.
Three postures
| 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 channel is the grant
Access works the way your Slack already does. Membership of a bound channel is the entire grant, and every member of it has the same reach. Add someone to the channel and they can ask; remove them and they are removed from the product.
Bindings are re-checked, not assumed
A permission granted on Monday lasts only as long as the condition it was granted under.
What teams write
Triage, reports, first-pass reviews: the jobs that repeat are the ones that wait longest for someone to find time. Everything below is a recipe a team writes for itself — a prompt plus a posture, run by the same engine — and adding one takes a minute.
| The event | The verifier’s job | What runs | What the team sees |
|---|---|---|---|
| Crash reported | Check signature, drop below-threshold, dedupe on issue id | Triage recipe (Act) | A story in the tracker, a summary in #incidents |
| Error spike or alert fires | Verify, extract service and severity as variables | Blast-radius recipe (Act) | Which code, which deploy, who to wake |
| CI build goes red | Verify, dedupe on run id | Failure-analysis recipe (Act) | Cause and suspect commit in the build channel |
| Ticket moved to Ready for dev | Verify, extract ticket key | Implementation recipe (Work) | A branch and a draft PR waiting |
| Ticket filed with a label | Verify, extract summary | Grooming recipe (Act) | Acceptance criteria and a scope estimate on the ticket |
| Pull request opened | Verify, extract number | Review recipe (Work) | An anchored GitHub review |
| Release tag pushed | Verify, extract tag | Release-notes and docs recipes | Notes drafted, docs PR opened |
| Analytics anomaly | Verify, extract metric and window | Correlation recipe (Act) | The deploys and diffs that line up |
| Dependency advisory | Verify, extract package and version | Reachability recipe (Act) | Filed only if this codebase reaches the path |
| Support ticket tagged possible bug | Verify, extract ticket body | Qualifier recipe (Act) | A real story, or a correct answer for the reply |
| Form submission | Verify, extract the body | Intake recipe (Act) | Deduped against existing tickets, filed or linked |
| Uptime check fails | Verify, dedupe | Diagnostic recipe (Act) | Recent changes to the failing path, posted |
Each is one recipe on one cron line, delivering into a channel through the Slack notifier. Because a prompt can interpolate the last successful run of the same recipe, a report can honestly say since last time instead of guessing at a window.
Daily
Weekly
Monthly
Who gets what
For most of the team, the whole product is a Slack channel they are already in. Pick a role to see its question, and what changes when the code answers it.
@PRCHD is the export limit still 500 rows, and where is it enforced?
Product questions get answered from the code, without booking an engineer.
@PRCHD what’s changed on main since Friday, and what’s risky in it?
The status an engineering manager currently assembles by asking five people assembles itself.
@PRCHD how hard would it be to support a second currency?
Leadership gets ground truth directly, at 22:00, without pulling anyone off anything.
@PRCHD a customer says CSV export drops the last row — is that possible in the current code?
The first-line answer comes from the code, names its commit, and takes a minute.
@PRCHD this stack trace [paste] — which commit last touched the line it dies on?
The alert arrives already triaged, attributed, and written up.
@PRCHD are the new empty states live on main, and what do they look like?
Design QA happens against the real app, without waiting for a build or an engineer.
@PRCHD signups dropped 12% on Tuesday — did anything ship that touches the signup path?
Analytics questions and code questions become one investigation.
@PRCHD is the rate-limit number in our docs the number in the code?
Doc drift gets caught on a schedule, not by a customer.
@PRCHD which endpoints skip the auth middleware?
Security questions get answered from the code, not from a spreadsheet of what someone believed it did.
The limits
Every product has edges. These are ours, stated plainly, so you can plan around them before the first channel is bound.
The host runs there today. There is no Windows, Linux, or Intel build yet.
Access is channel membership, with the same reach for every member. If your compliance story needs per-person roles inside the tool, this is not that tool.
Installed into your Slack workspace from a published manifest. Socket Mode apps can’t be listed in the Slack Marketplace, so setup is paste-two-tokens rather than one-click.
The bot’s messages tab is read-only. A mention dispatches a turn; a plain reply never does.
PRCHD drives the agent CLIs your team already signs in. It resells no model access.
Third-party tools reach the agent through its own configuration; PRCHD has no MCP client. The range is as wide as the agent’s, and none of it is ours to certify.
Token and context usage are reported. Monetary cost is not.
The recipe the operator bound to it, under that recipe’s posture. A trigger can’t name its own prompt, mode, or target, and that limit is the point.
A mention and one slash command are the whole vocabulary. There are no buttons, modals, home tab, or message shortcuts.
A thread shows one “Working on it”, then the answer edits itself in. A long run stays quiet while it works.
A trigger has no test button. Its URL is live immediately and answers every delivery as ignored until its verifier exists.
Your own code runs in its own short-lived process, with common globals removed to catch accidents. It guards against slips in code you wrote, not against code you didn’t.
Where your code lives
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.
Standing watch
One person installs it in an afternoon, on one computer, for every project. Everyone else is already in the channel.