Start with the reason the change can fail
A Proofline finding names the failure, the code that causes it and the evidence supporting it. An environment finding includes a fix prompt that asks your coding agent to verify the explanation before editing.
Read that prompt against the current code. The original review refers to a specific commit and environment snapshot. Inspect a finding and its fix prompt.
The finding
- Change
- A build step starts calling a new verification script.
- Evidence
- The pinned builder image was published before that script existed.
- Failure
- The build cannot find the script in its image.
The task for the agent
- Verify
- Check the step, script and pinned image reference.
- Propose
- Keep the step disabled until an image containing the script is published and pinned.
- Review
- Inspect the patch and rollout order before activating the step.
Use your coding agent or a connected cloud session
Use the fix prompt with your local coding agent. Proofline's CLI and MCP connection let supported agents read recorded reviews and findings. Connect your coding agent.
For an environment finding, you can also review the session prompt and send it to a connected Cursor or Devin account. An administrator chooses which repositories that connection may work on. The vendor bills its connected account for the session.
Inspect the patch and verify the new commit
Review the agent's branch or pull request and run your normal checks. A finished agent session does not establish that the finding is fixed.
After a fix is pushed, the next Proofline review re-verifies each open finding whose cited files the push changed, or every open finding on a full review. Read whether each finding is resolved, still present or could not be verified. Earlier reviews and their evidence remain unchanged.
In a local checkout, proofline review --verify re-verifies open pull request findings against uncommitted edits without posting to GitHub. Read about local verification.
A sandbox check can establish code behavior. Environment conclusions still need recorded infrastructure evidence. Your team decides what to merge.
Built-in fix generation is in development
Proofline has implemented workflows for generating a fix and combining up to ten findings with Fix all. Required analyzer checks are not yet available, so generated fixes cannot currently complete validation or be applied.
The intended workflow checks the patch, build, tests, analyzers and any required reproduction. A validated combined fix would become one commit or a separate pull request based on the original branch. Overlapping fixes and changes belonging outside the repository would be left out with a reason.
Use coding-agent handoff today. The release notes describe the built-in workflow and its current availability.
Request focused changes with finishing recipes
Finishing recipes propose changes such as adding tests, adding doc comments or simplifying changed code. Each recipe defines its allowed files and required checks. You inspect the proposal before asking for it to be applied.
Questions
Does Proofline merge the fix?
No. Your team reviews the resulting code and decides whether to merge. A coding-agent session does not grant merge approval.
Does marking a finding fixed verify it?
No. Mark fixed records a person's assessment. A new review or re-verification checks the changed code and names the commit it examined.
Can a sandbox test verify my production environment?
No. A sandbox test checks code behavior. A conclusion about production needs recorded evidence from that environment.
Start with one repository.
Review its next pull request, read the findings and use their evidence to guide the correction.
Get Started with GitHub