nicolasartman/reviewtato

โ˜… 0Forks 0JavaScriptGitHub โ†—Compare

README

PRtato ๐Ÿฅ”

A friendly tool to make reviewing PRs easier with the help of the same coding agents that honestly probably wrote the code in the first place.

The idea

PRtato is not a correctness checker โ€” agents already do that well, and there's no shortage of linters and static analyzers happy to yell at a diff. What's missing is the part only humans are actually good at: judging whether a change makes sense, spotting the subtle side effect three files away, and understanding why the work happened the way it did.

So instead of another pass/fail check, PRtato generates a guide to a PR โ€” a heatmap of where to actually spend attention, and a "story mode" walkthrough of the change in the order that builds understanding, not file order. A small group of engineers (plus the author) can use it to skip line-by-line reading and go straight to discussing the things that keep a codebase maintainable and communicable over time.

It shows up directly in GitHub's PR review UI: a gutter heatmap, a helper panel, and a full-width "visor" overlay for the story โ€” no separate app, no tab-switching.

Quickstart

./setup.sh

This installs a small native messaging host, registers it with whichever Chromium-based browsers you have, writes ~/.pr-tato/config.json (where the skills find your guides folder), and copies the three guide-generating skills to ~/.claude/skills/. It'll ask where to keep guides โ€” every prompt has a sane default and can be set non-interactively via env vars; see the comments at the top of setup.sh, and the printout at the end of a run.

Then:

  1. Open chrome://extensions, enable Developer mode, Load unpacked, and select this repo's extension/ directory.
  2. In Claude, run /create-pr-guide <pr-url> (or just describe the PR you want reviewed โ€” the skill's trigger phrases will pick it up).
  3. Open that PR's Files changed tab on github.com. The heatmap, helper button, and story mode show up automatically.

Make the skills yours

The installed skills are plain markdown under ~/.claude/skills/ and they are yours to edit โ€” that's the intended workflow, not a warranty violation. Once things are set up, ask Claude to use its skill-creation skills to reshape them to your preferences over time: how deep the risk analysis digs, how terse or narrative the story mode reads, house terminology, extra rubric rules โ€” whatever your team keeps wishing review guides did differently. For example:

"Open ~/.claude/skills/create-risk-heatmap/SKILL.md and make it treat any change to our billing/ dir as at least warning, and tighten annotations to one sentence."

setup.sh never overwrites an installed skill, so your customizations survive re-runs (delete a skill dir and re-run to get a factory copy). The one guardrail to keep: guide JSON must still pass the bundled validator, so leave the "validate until clean" steps in place.

Component map

Component Path What it does
Guide schema schema/guide-types.ts Source-of-truth types for every guide JSON file. Everything else imports from here (type-only in JS via JSDoc @import).
Guide validator schema/validate.mjs Zero-dep CLI, node schema/validate.mjs <guide-dir>. Checked after every write, by skills and by CI alike.
Orchestrator skill skills/create-pr-guide/ /create-pr-guide <pr-url> โ€” gathers PR context, writes manifest.json, and delegates to the two passes below.
Risk skill skills/create-risk-heatmap/ Produces heatmap.json: a skim/warning/risky temperature per region, with blast-radius and grounding notes.
Story skill skills/create-story-mode-guide/ Produces story.json: a branching narrative walkthrough anchored to the diff.
Native messaging host host/pr-tato-host.mjs The only thing with filesystem access. Reads guides, owns one state file. See below.
Chrome extension extension/ MV3, no build step. Renders the guide over GitHub's Files changed view.
Demo guide examples/demo-guide/ A worked example guide directory, useful for exercising the extension without running a skill.
Setup setup.sh Installs the host, registers it with your browser(s), writes ~/.pr-tato/config.json, copies the skills. Safe to re-run โ€” never overwrites edited skills.

Auditing the native host

This is the one part of PRtato that runs outside the browser sandbox and outside an agent's own reasoning, so it's worth being able to check for yourself in a couple of minutes rather than take on faith. host/pr-tato-host.mjs is deliberately small (~100โ€“140 lines), has zero dependencies, and is optimized for auditability over cleverness. Concretely, it can:

  • Read exactly three filenames โ€” manifest.json, heatmap.json, story.json โ€” and only from inside the guides directory you configured during setup. Every path is slugged, validated against a strict [a-z0-9._-] component pattern, and path.resolved and checked against the guides directory's resolved prefix before any file is touched. It never lists a directory and never follows symlinks.
  • Read and write exactly one file: ~/.pr-tato/state.json โ€” the visor-open/current-step/visited-steps UI state, written atomically (temp file + rename) and capped at 256 KB.
  • Talk to the extension over stdio using Chrome's native messaging framing (a 4-byte length prefix + JSON), and nothing else โ€” no network access, no shelling out, no other files.

That's the entire trust boundary. If you want to verify it yourself: read the file (it says as much at the top, in a short "auditor's checklist" comment), or run the smoke test setup.sh prints at the end of a run.

Dev

npm install
npm run typecheck
npm test

npm install needs registry access (it only pulls dev-time type packages โ€” typescript, @types/chrome, @types/node โ€” there are no runtime dependencies anywhere in this repo). npm run typecheck runs tsc in checkJs mode over extension/, host/, and schema/. npm test runs the node:test suites under schema/ and host/ (guide-validator fixtures and a host process that gets spoken to over real native-messaging framing).

Every .js/.mjs file starts with // @ts-check and JSDoc types โ€” there's no build step and no bundler anywhere in this project, by design.

Limitations (v1)

  • Only GitHub's current React-based "Files changed" view is supported โ€” the legacy diff view isn't.
  • No guide-staleness detection: if the PR gets force-pushed after a guide was generated, the extension doesn't know โ€” the manifest's headSha is informational only, not enforced.
  • Chrome/Chromium-family only. No Firefox, no Safari.
  • Not published to the Chrome Web Store โ€” load it unpacked.
  • No multi-user shared state โ€” the visor/state is local to your machine.
  • Only lines that are part of the diff get annotated; unchanged context lines are never decorated.

Contributors

nicolasartman

Issues