How it works

Architecture overview

PCR.dev is designed to sit passively in your development workflow, capturing the prompt-to-code decisions your team makes and surfacing them for human review without adding friction. It has three components: the CLI (pcr-dev), the Supabase backend, and the Next.js dashboard.

The CLI

The pcr CLI runs on your machine. It does two things: watches AI tool session files for new prompts, and sends those prompts to the PCR.dev backend.

Session files are plain JSONL files that Cursor and Claude Code write to your home directory as you work. The watcher monitors these directories:

Project scoping

When you run pcr init in a project directory, PCR computes a slug from the directory path and registers it locally in ~/.pcr-dev/projects.json. The watcher then only captures prompts from registered project slugs, ignoring everything else.

Authentication

The CLI authenticates using a CLI token, a long-lived token you create in the PCR.dev Settings page. Unlike OAuth sessions, CLI tokens are stored in ~/.pcr-dev/auth.json and survive machine restarts.

The Supabase anon (publishable) key is bundled in the CLI. It is designed to be public and can only perform operations allowed by Row Level Security policies.

Data flow

• –Cursor or Claude Code writes a session transcript to disk
• –The pcr start watcher detects the file change and saves new prompts as local drafts in ~/.pcr-dev/drafts.db
• –For Claude Code, the watcher inspects tool call file paths and records which registered projects were touched (touched_project_ids), so the draft surfaces in pcr bundle for every repo it edited — not just the session's primary repo
• –When ready for review, run pcr bundle to see drafts and group them into a named prompt bundle
• –pcr push seals any open bundles and uploads them — including prompts and incremental git diffs — to PCR.dev
• –Teammates who ran pcr init in the same repo can see each other's bundles in the dashboard