Fixes as pull requests
Most tools in this category hand you a ranked list and leave the work with you. A finding we can derive a file change for arrives as a branch your team reviews.
What the pull request contains
The body is written to be read by the developer who has never seen our console, and increasingly by an agent acting for them. Evidence is quoted rather than narrated, because the text came off a page we do not control.
- The finding, and the evidence that justified it
- Every file in the change, listed by path
- The gates we checked before proposing, with their verdicts
- What we did not do, stated plainly
Re-running an audit does not open a second one
The branch name is derived from the finding and the content of the change, so a re-run reuses the branch instead of stacking duplicate pull requests for something nobody has merged yet.
A finding we cannot derive stays a finding
A finding that describes your site rather than a file in it, and one that needs a value from you before the change can be written, are both reported rather than guessed at. We name which, and why.
Questions
Which findings become pull requests?
The ones where we can derive an exact file change from what we read. Findings about the site rather than a file in it, and findings that need a value from you first, stay findings with the reason attached.
Do you ever commit to my default branch?
No. Every change goes to its own branch and is raised as a pull request. Protect your default branch with a required review and nothing can reach it without a person approving it.
More in Turn a finding into a change
Run it against your own site.
No signup, no card. It reports what it could not check as well as what it found.