Skip to main content
PRFlow combines mechanical evidence with independent review passes to find defects before it hands the change to you. That raises confidence. It does not prove the change is correct. The prflow:review skill moves through setup and classification, a verification checklist, specialized reviewers and a verdict. The prflow:review-and-fix skill uses the same engine, applies justified corrections, verifies them and reviews the result again. A shadow pass checks an approval-side result before the loop exits.

​
Four Review Phases

1

Setup and Classification

The engine identifies the diff under review, its base, the related issue’s acceptance criteria and the risk profile of the changed files.
2

Verification Checklist

PRFlow builds a checklist of the claims this specific change makes: dependency interactions, test and mock alignment, data-format assumptions, API contracts and absolute claims. It drops an absolute claim that does not quote the change’s own text, and removes overlapping checks. Simple presence or absence claims are resolved directly. Deeper claims go to a reviewer for evidence-based evaluation. For a generated claim eligible for INVALID, a failure needs evidence of a broken requirement: the code’s own contract, a repository rule, or what a shipped caller or documented state needs. The reviewer uses INVALID only after establishing that the code is correct and no requirement source supports the claim; a validated INVALID counts as a pass. If the reviewer cannot establish correctness or settle the requirement, the item is inconclusive. A counterexample whose whole case is one an acceptance criterion says the finished change still allows or leaves as before does not fail such an item; one reaching beyond those words, or that the reviewer cannot place wholly inside them, still counts. Acceptance-criterion checks and re-checks of earlier findings follow their supplied grading rules.Each item comes back as pass, fail or inconclusive. A failed item and an inconclusive item both prevent a clean approval.
3

Specialized Reviewers

PRFlow dispatches reviewers with different focus areas, in separate contexts, so they do not inherit each other’s conclusions. Four always run and two run only when the change warrants them.Findings identify a file, a line and a defect type where possible. PRFlow uses that signature to count independent corroboration: when several reviewers report the same defect, confidence in the finding rises. A finding from a single reviewer stays visible for closer human scrutiny.
4

Verdict

PRFlow combines the checklist results, the findings, which reviewers completed and the configured severity threshold into one verdict. It reports incomplete checklist items and any reviewer that did not complete.

​
Which Reviewers Run

Four reviewers run on every review: Two more run only when the diff warrants them:
A reviewer that does not run is not a reviewer that found nothing. When two or more reviewers fail to return results, PRFlow adds a partial review coverage note to the verdict so you can see the gap.

​
The Verdict Vocabulary

Every review reports one of five verdicts.
An approval-family verdict is evidence for your review. It is not proof of correctness and it is not authorization to merge.

​
What Drives a Rejection

Any one of these produces a REJECT:
  • A verification-checklist item that failed, when its severity is at or above the configured severity threshold. The checker grades each item critical, important or suggestion by how much breaks: for a failed item, the requirement or counterexample it found; otherwise, the claimed behavior failing. An item without a trustworthy grade counts as critical. A failed item about inert prose (defined below) counts at its capped grade; the report still lists it. A failed item from the pull request’s last posted review is re-checked against the head being reviewed. Between review-and-fix passes, only a passed checklist item can carry over: it keeps its earlier result when, among other conditions, its cited lines are unchanged.
  • A finding at or above the configured severity threshold. At the important and suggestion thresholds, a finding below Critical whose whole claim is behavior a decided acceptance criterion requires, or that asks for what one excludes, is exempt unless a rule below rejects it or its relation to the criterion is unclear or only partly decided: it stays in the report at its grade, marked [decided by criterion <N>].
The default threshold is critical, so only critical findings and critical checklist failures (less the inert-prose exception above) reject through it; the rules below reject at any threshold, except for inert prose as noted. A lower-graded one does not reject on its own and is listed in the report with its severity. Set prflow_review.verdict_severity_threshold to important or suggestion to make more of both reject. See Review Settings.

​
The Rules That Surprise People

Further rejection rules do not read the severity threshold. Their one exception is inert prose: a code comment, docstring or documentation line that no tool or agent reads to decide behavior. An untrue line of inert prose is capped at Suggestion, or at Important when it ships to readers outside the repository (a README, a published doc page, a release note, a user-facing message), so it never rejects at the default threshold.
If the change’s own diff added or modified a documentation line, a code comment or a test that is untrue, that alone produces a REJECT. It rejects at every threshold setting, including the default. It cannot be lowered by severity configuration and it cannot be waived by deferring the finding. Only fixing the untrue line clears it. The exception is inert prose, capped as described above. When the earlier review a pull request review re-checks holds a finding that rejected a line under this rule, a re-check that finds the line still untrue keeps the REJECT on that review, whatever severity it is graded. A few review-side conditions stop this carry, for example a re-check item the review could not build correctly. See Re-Checking the Previous Review.
“Untrue” here means the added or modified line contradicts the code as it now stands, is already stale or contradicts another part of the same change. PRFlow treats this as a correctness principle rather than a severity grade: a change that documents itself incorrectly is wrong regardless of how minor the wording looks.
A wrong comment or a wrong documentation line survives the pull request and misleads every reader afterwards, including the next automated run. A severity threshold exists so a team can decide how much polish blocks a merge. It is not meant to let a change ship a statement about itself that is false. Rating that as a suggestion, and then letting the default threshold ignore it, is exactly how such lines used to reach the default branch.
If a finding shows the change does not meet a decided acceptance criterion of the linked issue, that alone produces a REJECT, at every threshold setting and whatever severity the finding was graded. It cannot be waived by deferring the finding, and a limitation the change discloses about itself that contradicts a criterion counts as that criterion being unmet, not as honest disclosure that clears it. Only meeting the criterion — or recording that it was genuinely out of scope — clears it. Among the cases that are not a finding of this kind is a change that applies the criterion’s check to more cases than the criterion allows, when, among other conditions, the review runs on a pull request; a line of its description starts (not indented, not a list item) with Stricter than criterion "<criterion>": <case> — <why>, where <criterion> equals the text of one of the review’s decided criteria, and names that extra coverage (a line whose criterion was reworded or removed since, or a numbered Stricter than criterion <N>: line from before this format, is ignored until a fix pass discloses again); the review’s checklist confirms the line against the code, with every other case the criterion names still getting its required outcome; and the report’s Run details name the finding beside that confirmation. The one exception to the rejection is a criterion whose subject is inert prose: its finding is capped at Suggestion, so it rejects only at a suggestion threshold.
This closes a gap where a known-unmet criterion could ship as an “approve with notes” pull request for a person to finish by hand. A general test-coverage or quality finding that does not establish an unmet criterion is unaffected and stays weighed by the severity threshold; once the checklist confirms a Stricter than criterion line, a finding that reports only its departure moves to Informational — Deferred and rejects at no threshold (see Disclosed Stricter-Than-Criterion Fixes). Separately, on every run that builds a checklist, every decided acceptance criterion gets exactly one checklist item, however many the issue carries, and these items never count against the checklist’s size cap. If any criterion is left without an item, the review rejects with a coverage shortfall. A run whose checklist generation failed caps that run’s verdict at APPROVE WITH CAVEAT, because no checklist was generated.

​
Review and Fix

/prflow:review-and-fix runs the same engine inside a correction loop. It evaluates each finding, applies the corrections it can justify, verifies each correction and reviews the result again. The configured default cap is five fix iterations. Before an approval-side result stands, a shadow pass reviews the diff again with the primary reviewers’ conclusions withheld from its prompts; under /prflow:implement, a clean first iteration skips it. Its separate write directory reduces accidental discovery; it does not isolate reads. It can send a missed finding back into another iteration and reports reviewer coverage gaps.
A report with no gaps means only that PRFlow recorded no known gap. It does not mean every defect was found.
The inline review-and-fix loop reports its result in your session. Run the standalone review workflow when you want a formal pull-request review verdict recorded on GitHub.

​
What Independent Review Means

Separate prompts and separate reviewer contexts reduce shared blind spots. Corroboration across several reviewers, and a fresh shadow pass, can expose an approval that nothing actually supports. They narrow the risk. They do not remove it. Reviewers can share the same model limitations, a test can encode the same mistaken assumption as the implementation it covers and production conditions can differ from the repository environment. Use the review output as structured evidence for your own review.