Rule creation
Warestack helps you define and enforce protection rules for all your operations, from pull requests to workflows and deployments. This guide explains how rules work, what events you can monitor, and how to create both predefined and contextual rules with AI.
Rule Definition
A Warestack rule defines the boundaries of how your team should operate, specifying what’s allowed, what’s enforced, and where flexibility is permitted.
Warestack supports rules for GitHub Issues, Pull Requests, Workflow Runs, and Deployment reviews.
It then watches your DevOps processes at real-time against these rules.
Rules take the stress out by catching and blocking mistakes early. They reduce bugs, prevent errors, and keep your team aligned. Use them and become a better developer by pushing your self to good habits and confident shipping.
Contextual Rules
A contextual rule adapts its decision based on the situation, actors, or intent, like Merges require passing checks, unless a Senior Dev approves a hot-fix. Learn more here ↗.
Warestack supports, three types of rules.
| Rule Type | Description | Visibility | Provider |
|---|---|---|---|
| Standard | Predefined rules recommended by Warestack. Useful for enforcing common best practices across teams. | Private | Warestack |
| Custom | Created by users or AI to match your team’s unique context and workflows. | Private | User owned |
| Community | Created by the Warestack user community. Publicly available for anyone to browse, copy, or adapt. | Public | User owned |
⚠️ Note: Public rules are reviewed by Warestack before release, so you can safely use the ones that fit your needs.
Enabling Rules
- Browse the 📁 Rule Catalog of standard rules.
- Configure its settings with a team (e.g.,
SRE,Frontend) and a severity level (Low,Medium,High,Critical). Optional parameters likelabels,time windows, and more. - Activate – The rule becomes visible under the Active Rules tab.
See a full list of rules here ↗
Creating Custom Rules
Custom rules can be written in natural language. Your prompt is evaluated against best practices, feasibility, potential risks such as harmful behavior or unfair enforcement. If valid, a safe rule suggestion is generated for you to accept or refine.
Follow two simple steps:
- Open the ✨ Create Rule Overlay and describe the rule in natural language, e.g.,
If a pull request triggers a deployment in main, it must be approved by a senior developer. - Review the recommended rule, make any tweaks, and activate it. The rule will be saved under the AI-Generated Rules tab.
For inspiration, explore the rules that follow.
Restrict Weekend Commits
Commit
🛑 Block commits to protected branches during weekends unless explicitly approved by a team lead.
Require Label Before Assignment
Issue
👍 Prevent assignment unless a priority or hot-fix label is added.
Bypass Review with SRE
Pull Request
👍 Require 2 reviewers unless the PR is labeled hotfix and approved by an SRE team member.
Block Off-Hours Deployments
Deployment
🛑 Block production deployments outside business hours unless approved by both QA and Engineering.
Enforce Coverage on Main
Workflow
🛑 Block workflow runs on main unless all checks pass and test coverage is above 80%.