Pull requesthigh
Require concise pull requests
Flag pull requests that exceed the configured maximum lines of code, excluding changes to lock files.
You configure
Maximum pull request sizeMerge blocking
pull_request.size_limitCode quality
Product / Catalog
24 standards, ready to enable. Start with the rules that matter to you.
Choose a rule for pull requests, issues, workflow runs or deployments. Review its parameters, choose its scope and see results from the next matching event. Rules report first; require the GitHub check when you are ready to block merges.
Every rule has a severity you can change and the parameters listed under it.
What the catalog watches24 rules · 5 event types
Pull request
Size, commits, linked work item, approvals, routing, scope and review findings.
GitHub issue
Acceptance criteria before assignment; implementation evidence before close.
Workflow run
Required release jobs succeed; runs stay within their time budget.
Deployment review
An approval from someone other than the requester.
Deployment
Verification evidence, traceability to a pull request, diagnostics on failure.
Rules evaluate events and metadata. Depending on the rule, evidence can include pull request diffs, workflow definitions and run logs.
The five GitHub event types the catalog evaluates.
Event
24 of 24 rulesSeverity is the default; change it per rule.
Pull requestmedium
Require atomic commits
Flag commits that exceed the configured lines of code per commit, regardless of the pull request size.
You configure
Maximum commit sizeMerge blocking
pull_request.commit_size_limitCode quality
Pull requestmedium
Route review requests based on branch prefixes
Route review requests to specific team members based on configurable pull request branch prefixes.
You configure
Branch-based review routingMerge blocking
pull_request.branch_reviewer_routingReview process
Pull requestmedium
Route review requests based on file paths
Route review requests to specific team members based on configurable file paths.
You configure
File-path review routingMerge blocking
pull_request.path_reviewer_routingReview process
Pull requestmedium
Detect review fatigue
Flag reviewers who receive more review requests than the configured threshold.
You configure
Maximum open review requestsMerge blocking
pull_request.reviewer_capacityWorkflow
Pull requesthigh
Require a linked ticket
Flag pull requests that are not linked to a Linear or GitHub issue.
You configure
Merge blocking
pull_request.linked_ticketWorkflow
Pull requestmedium
Require linked ticket to be assigned
Flag pull requests with a linked Linear or GitHub issue without an assignee.
You configure
Merge blocking
pull_request.linked_ticket_assigneeWorkflow
Pull requestmedium
Require active linked ticket
Flag pull requests with a linked Linear or GitHub issue that is inactive or not in progress.
You configure
Active ticket statesMerge blocking
pull_request.linked_ticket_stateWorkflow
Pull requestmedium
Require timely acknowledgment of review requests
Flag pull requests that do not receive reviews or acknowledgments within the configured time limit.
You configure
Review acknowledgment deadlineMerge blocking
pull_request.review_acknowledgment_slaReview process
Pull requestlow
Require timely updates for draft pull requests
Flag draft pull requests as stale when they have no updates within the configured time limit.
You configure
Draft pull request update deadlineMerge blocking
pull_request.draft_stalenessWorkflow
Pull requesthigh
Require timely acknowledgment of high-priority linked tickets
Flag pull requests that do not receive reviews or acknowledgments within the configured time limit when the linked Linear task is marked as "Urgent" or the linked GitHub issue is tagged as "Critical"/"Urgent".
You configure
High-priority review deadlineMerge blocking
pull_request.urgent_ticket_review_slaReview process
Pull requesthigh
Detect pull request scope drift
Flag pull requests that introduce changes unrelated to the linked Linear or GitHub issue.
You configure
Merge blocking
pull_request.scope_alignmentCode quality
Pull requesthigh
Require approvals by branch prefix
Mark pull requests that reach merge with fewer human approvals than their branch prefix requires. Bot approvals never count.
You configure
Approvals by branch prefixMerge blocking
pull_request.branch_approval_policyReview process
Pull requesthigh
Resolve automated review findings
Flag pull requests with current actionable review-bot findings that have not been resolved or addressed.
You configure
Merge blocking
pull_request.review_findings_resolvedReview process
Pull requestcritical
Require owner approval for sensitive changes
Flag sensitive-path changes without an independent approval from an observed code owner.
You configure
Sensitive pathsMerge blocking
pull_request.sensitive_change_approvalSecurity
Pull requesthigh
Require failure evidence for urgent fixes
Flag corrective pull requests linked to an urgent Linear issue when the issue does not document observable evidence of the broken behavior.
You configure
Merge blocking
pull_request.urgent_fix_failure_evidenceWorkflow
GitHub issuemedium
Close implementation issues after delivery
Flag closed GitHub implementation issues that have no linked merged pull request.
Parameters
None · runs as-is
issue.implementation_evidenceWorkflow
GitHub issuemedium
Require acceptance criteria before assignment
Flag assigned GitHub issues whose description does not define verifiable acceptance criteria.
Parameters
None · runs as-is
issue.acceptance_criteriaWorkflow
Workflow runhigh
Require successful release jobs
Flag release workflows when an observed required job does not complete successfully.
Parameters
None · runs as-is
workflow_run.release_jobs_successfulCI/CD
Workflow runmedium
Keep workflow runs within budget
Flag workflow runs whose observed elapsed time exceeds the configured duration budget.
You configure
Maximum workflow duration
workflow_run.duration_budgetCI/CD
Deployment reviewcritical
Require independent production approval
Flag production deployment reviews without an observed approval from someone other than the requestor.
Parameters
None · runs as-is
deployment_review.independent_approvalDeployment safety
Deploymenthigh
Require production verification evidence
Flag successful production deployments without observed health, smoke, or verification evidence.
Parameters
None · runs as-is
deployment.production_verificationDeployment safety
Deploymentcritical
Require production deployment traceability
Flag production deployments that cannot be traced to an observed pull request.
Parameters
None · runs as-is
deployment.production_change_traceabilityDeployment safety
Deploymenthigh
Require diagnostics for failed production deployments
Flag failed production deployments whose status history does not expose actionable diagnostic evidence.
Parameters
None · runs as-is
deployment.production_failure_diagnosticsDeployment safety
01Custom rules
If it is not in the catalog, write it as a sentence.
Describe the standard in plain language. Warestack interprets it into objective checks, shows them to you before adopting, and pins that interpretation so results stay stable until you choose to re-interpret.
Objective checks only. Each check names its evidence: a file path pattern, a heading in the description, an approval from a named team. Review the interpretation before enabling the rule.
Scoped where it applies. The migration rule runs where migrations live. The plan-artifact rule only on terraform-modules.
Versioned. Re-interpret to see what a newer model would change, as a diff, before you adopt it.
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
02From catalog to check
Three steps, no code.
Rules report from the next event. Blocking is a branch-protection decision you make per repository, later.
01Pick the ruleSet the parameters listed under it and the severity you want. Defaults are shown.
02Choose where it runsA team, a repository or a path pattern. New repositories join as they arrive.
03Let it reportResults appear on the pull request check, in the event feed and in reports. Require the check in branch protection when you are ready to block.
Each rule evaluates the change evidence it needs. Depending on the rule, this can include pull request diffs and workflow definitions.