Bug-report qualifier
Whether the described behaviour is real, and then either a scoped engineering story or the actual behaviour written up for the reply.
For the team
Know if it’s a bug before you escalate.
“Is this a bug, or working as built?” is a question support can’t settle alone, and the release notes and the test plan wait on the same reading of the same diff. Now the code gives the first answer, in the thread.
For support and QA
The wait today
Support is asked to adjudicate the product’s behaviour with a help-centre article and a hunch, and QA is asked to describe the risk in a release branch before anyone has read it end to end. Both answers are sitting in the diff, and the price of getting them is an interrupt somebody has to absorb.
They ask
Ask in your own words. The answer names its commit.
Mention @PRCHD with the question you’d have saved for a colleague, and it reaches the agent exactly as typed. The agent reads the project’s checkout in Act mode, which changes nothing on disk, and the answer lands in the thread footed with the commit it was read from.
- @PRCHD a customer says CSV export drops the last row — is that possible in the current code?
- @PRCHD what are the actual rate limits on the public API right now?
- @PRCHD does the app retry a failed webhook, and how many times?
- @PRCHD what behaviour changed in this release branch that a user could notice?
- @PRCHD which of our tests are flaky, and what do they have in common?
They run
The jobs that keep coming back, written down once.
Each is a prompt plus a posture that someone on the team writes once. After that, anyone in a private channel the operator enabled for runs starts it with one slash command, and the result comes back in the thread. These are examples for support and QA, not a catalog to install — PRCHD supplies the engine, and each team writes its own.
Release notes from the diff
User-facing changes in user language, taken from the merges actually in the branch.
Test-plan generator
A manual test plan for what the diff touched, and nothing it did not.
Exploratory pass
A walk through the running app with the browser tool, screenshot by screenshot, and a note on what looked wrong.
Repro harness
A fresh worktree with a failing test that reproduces the reported bug.
Scheduled and triggered
Some of the work is done before anyone asks.
Put the same recipe on a cron line or behind a webhook URL and it starts on its own, so work that used to wait for someone to wake up or find time is already done when people arrive.
- A support webhook on a keyword or a tag, firing the qualifier before a human picks the ticket up.
- A nightly smoke run against the dev server with a screenshot trail.
- A pre-release changed-since-last-tag report on a schedule.
- A CI webhook that fires a why-did-this-break recipe on a red build.
What changes
The first-line answer comes from the code, names its commit, and takes a minute.
Where it stops. The thread shows one “Working on it”, and that message becomes the answer when the run settles, so a long exploratory pass over twenty screens stays quiet until it’s done.
Other roles
The same host answers the rest of the team.
Product managers
@PRCHD is the export limit still 500 rows, and where is it enforced?
Product questions get answered from the code, without booking an engineer.
Engineering managers
@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.
Founders and CTOs
@PRCHD how hard would it be to support a second currency?
Leadership gets ground truth directly, at 22:00, without pulling anyone off anything.
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.
Standing watch
Send this to whoever runs the shared computer.
One person installs it — an afternoon, not a migration. Everyone else asks from a Slack channel they’re already in, and nobody creates an account, installs an app, or pairs a phone.