For the team

Ask the code what the product actually does.

Half your questions are ones you’ve asked an engineer before. The other half are “is this already built?”, which only the code can answer. Now you ask the code yourself, in a channel you’re already in.

For product managers

The wait today

Product decisions get made against a mental model of the code, and that model is always a little out of date. The gap is filled by interrupting somebody — which is expensive enough that most questions never get asked, and the ones that do arrive as a meeting.

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 which of last week’s refund changes touched the webhook retry path?
  • @PRCHD is the export limit still 500 rows, and where is it enforced?
  • @PRCHD we’re being asked for SSO — how much of the auth layer already supports it?
  • @PRCHD what does the app actually do when a payment is declined? walk me through it.
  • @PRCHD read this crash report [paste] — which feature does it belong to?

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 product managers, not a catalog to install — PRCHD supplies the engine, and each team writes its own.

Feasibility sketch

A scoped estimate with the files it would touch, the risky parts, and what it cannot tell from the code alone.

Spec-to-reality diff

Where the implementation has drifted from a spec document, point by point.

Story writer

A scoped story, filed in your tracker through the agent’s own configuration, with acceptance criteria taken from how the code behaves today.

Competitive teardown follow-up

What your equivalent screen does today, after the agent opens theirs with the browser tool.

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 weekly what-shipped digest written from the merge history in plain language, not commit subjects.
  • A ticket-hygiene sweep that flags stories describing behaviour the code no longer has.

What changes

Product questions get answered from the code, without booking an engineer.

Where it stops. Questions run in Act mode, so the agent reads the checkout and changes nothing on disk. Starting a recipe from Slack happens in a private channel the operator enabled for runs.

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 →

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.