Usage
Everything you need to know about your day-to-day workflow with PURA — from triggering a review to understanding what comes back.
1. Trigger a review
To start a review, open a pull request and post a comment with /pura reviewas the very first line. That's it — PURA will pick it up and get to work on that PR right away.
Active plan required. Your account must be on an active trial or paid plan for reviews to run. If your trial has lapsed, reviews pause until you choose a plan.
2. Reading a PURA review
PURA posts one review per request. Every review contains three things: a short summary of the change, a list of findings each tagged by severity, and a verdict.
Findings come in three severities:
- P1 — must fix: correctness issues, security vulnerabilities, breaking changes, or anything that can cause data loss.
- P2 — should fix: robustness concerns, missing tests, or notable style and performance issues worth addressing.
- P3 — suggestion: polish, alternatives, or nice-to-haves that are entirely optional.
The verdict is one of APPROVE, REQUEST_CHANGES, or COMMENT. Any P1 finding automatically makes the verdict REQUEST_CHANGES. A clean review with no significant issues comes back as APPROVE.
Many findings include a ready-to-apply code suggestion, posted inline on the exact lines so you can accept it directly in GitHub:
3. Drafts and skips
PURA skips draft pull requests. Mark a PR as ready for review in GitHub before triggering PURA, and it will pick it up normally.
Comments posted by the PURA bot itself are always ignored — so PURA will never accidentally review its own output.
4. Re-running a review
Pushed new commits and want a fresh look? Just comment /pura review again. Each run reviews the latest state of the PR— so you always get feedback on what's actually in the branch right now.
Every run is independent.PURA doesn't carry over findings from a previous run — it reviews the PR fresh each time you ask. A new review supersedes the previous PURA review (the earlier one is dismissed).