Read the reviewed diff beside its findings#
On a pull request review, choose View changes to open the base-to-head diff that Proofline reviewed. The view pins both commits from that review run, even if the pull request branch has moved on since then. Select a marker in the diff or a row in Findings to open the Finding inspector beside the code. You can read the cause, the affected component, and the recorded evidence without leaving the file. Press j and k to move between changed files, and press n and p to step through findings. When a finding includes a validated replacement, Proofline shows the Suggested change diff and whether it published a GitHub suggestion.
Run details also displays a change diagram when the review recorded one. On each environment assessment, Declared reach lists infrastructure in the snapshot that declares a dependency on what the change deploys. Coverage gaps appear beside that list so missing evidence stays visible. When a repository enables pull request description sections, choose Write description section to write the review summary to GitHub for that head commit.
Inspect the changes in a review.
Ask questions about a completed review#
Open Discussion on a completed pull request review to ask about the diff, a finding, or the linked environment snapshot. Proofline answers from the evidence recorded for that review run and cites the files and infrastructure records it used. Questions and answers in Discussion stay in the Proofline console and do not post comments on GitHub. When someone asks @proofline a question on the GitHub pull request, Proofline lists that reply separately under GitHub answers.
Explore the codebase and draft implementation plans#
Each repository now has a Codebase tab that builds a module wiki pinned to a specific commit. Wiki pages cite the source lines behind each claim and show whether the claim was verified against that commit. You can also ask codebase questions against the pinned commit and its linked environment snapshot.
Under Plans, you can draft a versioned implementation plan pinned to a repository commit and a World snapshot. Start a plan from a GitHub, Jira, or Linear issue, a pasted specification, a repository Markdown file, or design images from PNG uploads or Figma. After you approve a plan version, Proofline can run each layer in a disposable sandbox and validate the build, tests, and analyzers. Once every layer validates, a person can open the resulting draft pull requests on GitHub.
Each environment also has an Architecture tab that generates an architecture document from World's declared topology and the deployed commit of each linked repository. Missing or ambiguous deployment evidence stays explicit in the document.
Fix and verify findings with coding agents and the CLI#
Connect Cursor or Devin under Integrations and select the repositories that the provider may work on. From an environment finding, choose Fix with coding agent to review the prompt and start a cloud session. Proofline sends the prompt and repository name to the provider, and you review any branch or pull request before merging.
In a local checkout, proofline review --verify re-verifies open pull request findings against your uncommitted edits without posting to GitHub. You can also review selected files at a pushed commit with proofline review --commit REVISION --files PATH... and stop a running review with proofline stop. When a local patch review's change later opens as a pull request, findings you dismissed or accepted locally carry over to the pull request Check.
Coding agents connected to Proofline's MCP server at /mcp can read the codebase wiki, environment architecture documents, approved plans, and open findings. They can also request finding re-verification after pushing a fix. Under Integrations → MCP servers, administrators can register an organization's own MCP servers and approve individual read-only tools for reviews to call.
Start a cloud coding-agent session.
Read the CLI and MCP documentation.
Triage pull requests, enrich issues, and connect Vercel#
Pull requests → Inbox collects open pull requests across connected repositories into For you and For your teams. Each row shows the latest review verdict and finding count, and you can close a pull request if its head commit has not moved. In a repository's Issues tab, administrators can enable a one-time triage comment on new or edited GitHub issues. The comment can list possible duplicates, referencing pull requests, CODEOWNERS assignee suggestions, and allowlisted labels.
You can now connect Vercel directly through the Vercel integration flow or with a bearer token. Map each Vercel project and target (production, preview, or a custom environment) to the Proofline environment it deploys into.
Triage your pull request inbox.
Scope team rules, opt into semantic search, and govern policies#
Team rules in Guidance can now apply when a team member opens the pull request or when the team owns a changed path in CODEOWNERS. Proofline evaluates CODEOWNERS at the pull request's pinned merge base, and each finding records the rule revisions that shaped it. Under Organization → Review models, administrators can keep the Automatic sandbox harness or select Claude Code or Codex for sandbox verification runs.
Under Organization → Semantic index, administrators can opt into repository embeddings that store chunk digests and vectors without storing raw source text. Semantic search returns candidate file locations, while findings still require code and environment evidence. In Evidence, administrators can adjudicate deterministic check families, and enterprise administrators can apply versioned policy templates across member organizations.
