Org engineering standards live in wikis. Nothing checks pull requests against them.
Warestack checks every pull request and deployment in your GitHub organization against the standards you already wrote. Was it approved by the right people, tested, linked to an issue, and kept in scope?
Free for open source projects and for teams that ship a light volume.
1 blocking Warestack rule violation detected.
Detect pull request scope drift: Linked Linear issue ORB-418, Batch mute alert rules by label, does not match this pull request. The change pins the kaniko executor and passes base_ref through the preview build.
Recommended action: Limit the pull request to ORB-418, or link the issue that describes this build change.
Research & innovation
UKRI-funded research collaboration
Warestack is an industry partner in a UK Research and Innovation (UKRI)-funded project led by Birkbeck, University of London, advancing software governance and compliance evidence.
A rule finds the problem. A chain acts on it. A report keeps the record.
Write a standard in plain English and Warestack turns it into checks you can read before turning them on. A catalog covers the common ones: linked issues, independent approvals, scope, size, tests, deploy windows.
When a rule fails, a chain decides what happens: a comment on the pull request, a live card in Slack, a note on the Linear or Jira issue, a message to the owner if nobody acts. One problem, one notification, escalated on a timer.
Ask a question in plain English and get the answer with the rows behind it. Schedule it to Slack or email, export the CSV, and keep every run. The record for the auditor, the board, or the incident review.
It shows up where your team already works.
GitHub connects first. Slack, Linear and Jira share the same rules, the same chains and the same record. Nothing new to adopt.
As wide as the organization. As narrow as one folder.
Every rule is enabled on a scope you choose: a team, a repository, or a path inside one. Different rules, different scopes, one organization. New repositories join their team's rules as they arrive.
Rules report first. Merge blocking is a separate switch, per repository, that stays off until you require the check in branch protection.
The record is ready before anyone asks for it.
Ask a question in plain English. Get the answer with the rows behind it, scheduled to Slack or email, exported as CSV. Every run is kept for up to 365 days.
Four weeks on one to three repositories.
A paid pilot with the success metric agreed before anything is installed. Nothing blocks a merge during the pilot unless you decide it should.
A GitHub organization admin for the install, five minutes. A Slack channel. The standards document you already have.