Skip to content
Archiedocscookbooknewssign in

    Review a pull request

    Run archie's multi-stage review on a pull request and post its findings as inline comments, with or without approving them first.

    Archie reviews a pull request in stages and posts its findings as inline review comments on the forge.

    Before you start

    • archied is connected to the forge that hosts the repository, with permission to read pull requests, diffs and archives, and to post review comments.
    • The pr-review workflow is enabled for your org.

    Start a review

    1. Click New task in the top bar. On the Workflows page, use the pr-review workflow's Run button instead.
    2. Under Workflow, choose pr-review.
    3. Set Repository to owner/repository and pr_number to the pull request number.
    4. Optionally set depth to exactly quick, standard or deep. If you leave it empty, archie picks it from the lines added and deleted: under 100 is quick, under 500 is standard, anything larger is deep. The three depths review up to 3, 6 and 12 dimensions.
    5. Fill in Title and Instructions, choose Run as identity, and click Start task.

    A review can also start from a captured forge event: bind the event to pr-review and map its payload to pr_number and the repository.

    What the review does

    1. Intake fetches the pull request's metadata and diff and resolves the depth.
    2. Anatomy maps the change's blast radius (the files that depend on the changed files) and groups the changed files.
    3. Lenses propose the review dimensions for this change.
    4. Review runs one reviewer per dimension, up to 8 at a time.
    5. Precision gate drops nitpicks, style issues and unverifiable claims. It only runs when it's turned on.
    6. Verification checks that each finding is supported by the code, has an adversary try to refute it, and marks findings that only matter in combination.
    7. Coverage and consistency sends reviewers to changed files no dimension covered, and checks the findings for obligations they break across each other.
    8. Synthesis scores and ranks the findings and keeps the top 25.
    9. Operator approval holds the review for you. It only runs when it's turned on.
    10. Merge gate decides which findings block the merge: a broken build, a security hole, data loss, a contract break or a regression.
    11. Output tightens each comment's wording and posts the review.

    Each comment is attached to a line of code, so archie only posts findings that point at a specific line. The task's result says how many were posted, whether the review went up as a comment or a change request, and which stages were skipped because the budget ran out.

    Approve findings before they post

    Turn on Approve before posting under Settings → Review.

    The task then stops in waiting_human after synthesis. Its page shows Review findings with the head commit and one entry per finding: title, file and line, severity, score, confidence, evidence and any suggested fix. Every finding starts selected.

    • Approve posts the selected findings, worded exactly as you saw them, against the head commit the review ran on. Findings that don't point at a specific line still appear in the list, but they won't be posted.
    • Re-review asks for instructions and runs the review again. The lens and reviewer stages get your instructions.
    • Reject ends the review.

    A review with no findings doesn't wait.

    Fewer, more certain findings

    Turn on Precision gate under Settings → Review. You trade some recall for precision, and verification costs less because fewer findings reach it.

    Both settings are off by default.