The standards are already written down. Agents read them as suggestions.
.cursorrules, AGENTS.md, CLAUDE.md, CONTRIBUTING, the pull request template, CODEOWNERS. Every team adds its own; every agent reads a different subset; nothing checks the pull request afterwards. Warestack turns each standard into a rule with objective checks, runs it where the change is, and makes every exception a row instead of a Slack thread.
Read-only until a chain writes. Chains that act on GitHub are rehearsed with a dry run first.
Warestack Rules— 1 blocking rule violation1 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.
GitHub Technology PartnerHooks and linters stop at commit. Rulesets gate on checks and reviewers.
Drift between the work item and the change is only visible at the pull request, and nothing looks there. So the platform team becomes the manual gate, and the same exception comes back next week.
Instruction files shape what an agent writes. They do not check what it opened as a pull request.
Lint and tests see the code. Nobody checks the process: approvals, scope, the plan artifact, the rollback note.
Every exception is a thread. Every thread is the same one, a week later.
One rule, every repository.
Enable a rule on a team, a repository or a path. New repositories join as they arrive. Rules report first; merge blocking stays off until you require the check in branch protection.
Scoped where it applies. The migration rule runs only where migrations live. The plan-artifact rule only on terraform-modules.
Exceptions become rules. When the same thread comes back, write the standard as a sentence and let Warestack derive the check. Review it before adopting.
Pass rate per rule, per repository. Which standards hold, which drift, and where. Exceptions trend down, or the rule gets rewritten.
The standards that come back every week.
Each written as a sentence, derived into checks, scoped to the repositories where it applies.
For pull requests that change files under db/migrations/, the description must include a Rollback section describing how to revert.
For pull requests in terraform-modules, require a terraform plan output linked in the description or attached as a CI artifact.
Summary, Testing, Risk and Rollback sections present and non-empty, so reviewers can assess the change and its deployment safety.
Flags release workflows when an observed required job does not complete successfully.
Routes review requests to the owning team based on configurable paths.
Marks pull requests that reach merge with fewer human approvals than their branch prefix requires. Bot approvals never count.
Standards hold without the platform team as the manual gate.
The audit answers exist before anyone asks. The time saved is the smallest part of the return.
Standards hold at the pull request. Scope drift, missing approvals and untested changes are flagged before merge, without a person in the loop for every one. A year of Warestack for 40 engineers is about $2,400.
Pass rate. Which standards hold, which drift, and in which repositories. The weekly report names them.
One problem, one notification. Escalation on a timer to the person who can act. Nothing is re-posted. Business hours only, if you say so.
Four weeks on one to three repositories.
Paid, with the success metric agreed before anything is installed. Nothing blocks a merge during the pilot unless you decide it should.
From you. A GitHub organization admin for the install, five minutes. A Slack channel. The repository files and templates where the standards already live.
Success metric: every pull request on the pilot repositories evaluated against the written standards, with exceptions per week down by half by week four.