Warestack sits in the tools your team already uses. A Linear issue, a GitHub pull request, a human review, checks, a Slack follow-up, and a production deployment stay connected — so you can see what a change is, who owns it, and whether it actually shipped.
You do not need a compliance program to use it. Teams use Warestack to keep reviews moving, keep Slack current, and stop guessing whether a PR is tied to a real ticket.
What you can do here
| If this is the problem | Start here |
|---|---|
| A ticket key is in the branch, but the PR may not be linked | Rules |
| Reviews disappear into GitHub | Slack live card and Review SLA |
| You need to know what needs you right now | Overview and attention |
| You need to know what actually shipped | Production changelog |
| Several PRs in one repo depend on each other | Pull-request stacks |
See the full use-case map and worked examples.
How the pieces fit
| Moment | In Warestack |
|---|---|
| Plan | Linear stores the issue association and can answer from that evidence |
| Change | Rules flag what is missing on the pull request |
| Review | Slack keeps one live card current and reminds the requested reviewer, then the owner |
| Act | Overview and Events show who needs to do what |
| Ship | Production changelog announces a successful production deploy |
| Sample | Reports save a query you can rerun and, if you want, post on a schedule |
Start with one or two repositories. Merge-blocking stays off until you choose to require Warestack Rules in GitHub branch protection.
Warestack does not treat a ticket string as a link, a bot as a human reviewer, or a merge as a production deployment. If evidence is missing, it says so.
If you also need a sampleable trail for SOC 2 or Vanta, that path is documented separately: SOC 2 and Vanta.
If you are an AI agent drafting a setup, use For AI agents.