How it works

Connect the work. Make the next step clear.

Connect GitHub, choose the standards that apply, and decide what follows a finding. Rules check changes, chains coordinate follow-up, and reports keep the evidence.

Install

Install the GitHub app on the repositories you choose. It observes pull requests, reviews, checks and deployments.

Rules

Standards written as sentences, turned into checks you can read. Reporting only until you require the check.

Chains

What happens when a rule fails: a comment, a live card, a message to the owner. Escalated on a timer.

Reports

Questions over the record, answered with rows, scheduled and kept. The evidence for the auditor and the incident review.

01Rules

Write the standard. Read the check before you turn it on.

A rule is a sentence. Warestack shows the checks and the evidence they use, then keeps that interpretation pinned until you adopt an update. A catalog of common rules covers linked issues, approvals, scope, size, tests and deploy windows.

Scoped where it appliesA team, a repository or a path. New repositories join as they arrive.

Reports firstEvery rule starts informational. Merge blocking stays off until you require the Warestack check in branch protection.

Bots never countApproval and review rules count humans. An approving bot does not satisfy them.

A rule, as written

Pull requests that change files under db/migrations/ must include a Rollback section describing how to revert.

What Warestack checks

When any changed file path starts with db/migrations/, the pull request body must contain a heading named Rollback followed by at least one sentence.
Evidence: pull_request_files.path and pull_request.body. Returns Not evaluated only when the changed-file list is unavailable.

Interpretation v1 · pinnedEnabled on orbital/control-planeReports only

02Chains

Decide what happens when a rule fails.

A chain is one trigger, ordered steps and time gates. It posts to the pull request, to Slack, to the Linear or Jira issue, and to a named person when nobody acts. Chains that act on GitHub need a dry run before they are enabled.

Live cards update in placeOne Slack message per pull request, kept current. Escalation happens in its thread.

Time gates count from the triggerChoose when reminders and escalation are due. Count business hours when configured.

Resolves itselfA review, a merge or an approval ends the chain. Nothing is re-posted.

Pull request live cardWhen a pull request opens · until it merges or closes318 runs · 30 days

On openPost the live cardSlack · #pull-requests · one message per pull request, kept current

After 12hRemind the channelReply in the Slack channel · skipped if a review was submitted or the pull request closed

On merge or closeResolveThe card shows the outcome. Nothing more is posted.

One live card stays current. The channel reminder stops once a review is submitted or the pull request closes.

03Reports

Ask in plain English. Keep the answer.

A report is a question over the record, answered with the rows behind it. Save the result, schedule it to Slack or email, or export the CSV. Retention follows your plan or agreement. Briefs summarise one result for the audience that asked, with every claim linked to its evidence.

For the auditorApprover, checks, linked issue and deployment details for recorded changes. Retention follows your plan or agreement.

For the incident reviewWhat shipped, when and who approved it, without reconstructing it from chat history.

For youReview turnaround, unreviewed merges, lead time and deployment frequency per repository, every week.

Question

Which pull requests merged in the last 30 days with fewer human approvals than their branch prefix requires?

Answer

4 of 198 merged pull requests had fewer human approvals than required.

RepositoryPRApprovalsMerged

console-web#1182renovate[bot] onlyOct 2

sdk-go#233copilot[bot] onlySep 28

collector-agent#4021 human · 2 requiredSep 22

billing-service#587dependabot[bot] onlySep 15

4 rows · sample dataDownload CSVSchedule weekly to #eng-quality

04Where the record comes from

Evidence from four systems, one record per change.

No pipelines to build. Warestack listens to events and gathers the evidence each supported workflow needs, which can include pull request diffs, workflow definitions and run logs.

GitHub

Pull requests, reviews, approvals, checks, workflow runs, deployments and branch protection. The check and the comment are written here.

Slack

Channels receive live cards and reports. Confirmed identity links let direct messages reach the right person.

Linear

The linked issue, its status, assignee and description. Rules read it; the timeline is written back to it.

Jira

The linked work item, read through an Atlassian Forge app. The timeline and the result sit on the work item.

Not a code reviewerWarestack checks how a change was delivered, not what the code says. It does not review code, run your CI or orchestrate coding agents. People and agents are held to the same standards at the same point, the pull request.

05The first five minutes

Install, pick a rule, see the first result.

Install on the repositories you choose, enable a rule, and open a pull request to see its check. Connect Slack when you are ready to receive live cards and reminders.

Install from GitHub Marketplace Get started

01Install the GitHub appPick one to three repositories. An organization admin approves once.1 min

02Turn on two rules from the catalogRequire a linked issue and Require approvals by branch prefix are the usual first pair.2 min

03Connect SlackOne channel for live cards. Direct messages work once people confirm their link.1 min

04Open a pull requestThe Warestack Rules check runs and the result appears on the pull request and in Slack.next PR