Start with what is breaking in the delivery path, not with a feature list. Warestack can observe, explain, route, remind, and preserve evidence across GitHub, Linear, and Slack. The rules catalog covers pull requests, GitHub issues, workflow runs, and deployments — twenty-four catalog rules, cited by name and rule_key.
Status on this page is deliberate:
- Available — shipped product surface or authorable template.
- Recommended — a good first enablement, with merge-blocking off.
- Self-serve — configured by the individual, not an admin.
- Not generally available — not a self-serve control yet.
Keep changes tied to intent
| Need | What Warestack does | Use |
|---|---|---|
| Every PR needs a real Linear issue | Requires a Linear association in Warestack’s store — not a key in the branch or Refs: | Require a Linear issue · Recommended |
| Someone must own the issue | Checks that the associated ticket is assigned | Require linked ticket to be assigned · Recommended |
| The issue must be active | Checks the Linear workflow states you mark as active | Require active linked ticket · Recommended |
| The diff must match the ticket | Compares changed files and diff with issue scope and acceptance criteria | Detect pull request scope drift · Recommended |
| A PR links the wrong issue | Shows scope drift in the GitHub check, Slack card, Events, and Linear agent context | Detect pull request scope drift + worked example |
| A feature spans API, UI, and schema repos | Parent issue for the outcome; one sub-issue and one associated PR per repo. Warestack does not inherit the parent | How to ticket · Recommended |
| An urgent fix has no failure evidence | Flags Urgent Linear fixes whose issue does not record an observable symptom | Require failure evidence for urgent fixes · Available |
| An assigned GitHub issue has no acceptance criteria | Flags assigned issues whose body has no verifiable criteria | Require acceptance criteria before assignment · Available |
| A closed implementation issue has no merged PR | Flags closed GitHub implementation issues with no linked merged pull request | Close implementation issues after delivery · Available |
Raise the review bar without surprising the team
| Need | What Warestack does | Use |
|---|---|---|
| Feature work needs two humans | Counts APPROVED reviews by branch prefix; bots and author do not count | Require approvals by branch prefix · Recommended |
| “LGTM” is not review evidence | Requires a named command, CI check, or environment result in each counting approval | Evidence in the approval body · Recommended |
| Review requests sit untouched | DMs the requested reviewer, then the individual repository owner | pull_request_review_sla · Recommended |
| A few reviewers carry the queue | Detects fatigue or reroutes when a reviewer is over capacity | Detect review fatigue / reviewer_at_capacity · Available |
| Only a bot approved | Nudges for a human review | bot_approval_needs_human · Available |
| Changes requested, then silence | Follows up with the author and escalates | review_feedback_follow_up · Available |
| A draft or open PR goes stale | Flags stale drafts or runs a business-hours follow-up chain | Require timely updates for draft pull requests / stale_pull_request · Available |
| Review-bot findings stay open | Flags current actionable bot findings that are not resolved or addressed | Resolve automated review findings · Available |
| Sensitive paths lack owner approval | Requires an independent code-owner approval on configured sensitive paths | Require owner approval for sensitive changes · Available |
Keep changes small, testable, and owned
| Need | What Warestack does | Use |
|---|---|---|
| PRs are too large | Applies a configurable size cap with lock-file handling | Require concise pull requests · Available |
| Commits mix unrelated work | Applies a lines-per-commit atomicity policy | Require atomic commits · Available |
| Review should follow branch or path ownership | Routes to named reviewers by prefix or changed path | Route review requests based on branch prefixes / file paths · Available |
| Feature work has no test evidence | Requires relevant test changes or a concrete Testing explanation; generic “N/A” fails | Feature test evidence · Recommended |
| A large PR has no test files | Comments and adds a needs-tests label | large_pr_without_tests · Available |
| CI/CD changes lack owner review | Detects protected workflow/path changes and can require an owner | cicd_change_without_owner_review · Available; leave its gate off at first |
| A workflow run exceeds its budget | Flags observed elapsed time over the configured duration | Keep workflow runs within budget · Available |
Put the same facts where people work
| Need | What Warestack does | Use |
|---|---|---|
| Slack needs one source of truth per PR | Creates one live card and updates it in place | pull_request_slack_live_card · Recommended |
| Someone wants a fresh answer in the thread | Request Update replies in that thread, never a second top-level card | Live card · Available |
| A person wants the current queue | Shows Overview › Needs attention: For me / For the space | Overview and attention · Available |
| A reviewer wants a weekday summary | Sends a private snapshot of their own For me queue; skips empty mornings | personal_digest · Self-serve |
| A team asks from Slack | Returns status, violations, activity, attention, identity, or assignment commands | Slack commands · Available |
| A Linear issue needs delivery context | The mention-only workspace agent summarizes linked PRs, checks, reviews, and findings | Linear agent · Available when installed |
| An issue has no linked PR | Returns an honest empty result and asks for a link; never invents owner/repo#n | Worked example |
Understand a change, not just one PR
| Need | What Warestack does | Use |
|---|---|---|
| Browse activity across the space | Filters Events by source and attention, then opens the event detail | Events · Available |
| Audit what changed over time | Shows PR/issue/deployment context, findings, and a per-event timeline | Event detail · Available |
| Review a stack of dependent PRs | Shows GitHub-native or Warestack-detected same-repository stack topology and readiness | PR stacks · Available |
| API + frontend or schema + migrations must move together | Named counterpart-repository evidence is not a self-serve control yet | Cross-repository guards · Not generally available |
Cross-repository stacks are not supported: PR stacks stay inside one repository. Cross-repository guards are a separate, not-generally-available capability.
Follow work through production
| Need | What Warestack does | Use |
|---|---|---|
| Production deploys need release notes | Announces only a successful production / prod deployment, with associated PRs or an unassociated commit | production_rollout_changelog · Recommended |
| A deployment approval is waiting | Nudges the approver and repository owner | deployment_review_waiting · Available |
| Deployment review needs one Slack card | Keeps one card current until the review resolves | deployment_review_live_card · Available |
| Default-branch CI failed | Announces it and can create a deduplicated Linear issue | failed_workflow_default_branch · Available |
| A production deploy cannot be traced to a PR | Flags production deployments with no observed pull-request association | Require production deployment traceability · Available |
| A successful production deploy has no verification | Flags production success without health, smoke, or verification evidence | Require production verification evidence · Available |
| Production approval is only the requestor | Flags production deployment reviews without an independent approver | Require independent production approval · Available |
| A failed production deploy has no diagnostics | Flags failed production deployments without a diagnostic description or log URL | Require diagnostics for failed production deployments · Available |
| A release job did not succeed | Flags release workflows when a required job did not complete successfully | Require successful release jobs · Available |
Build a sampleable operating record
| Need | What Warestack does | Use |
|---|---|---|
| Security wants a weekly change population | Runs saved SQL on a calendar and announces the result with summary and/or CSV | scheduled_report · Recommended |
| A team needs a custom slice | Natural-language ask → review SQL → preview → save → run history | Reports · Available |
| Leaders need delivery trends | Shows units, previous-window deltas, trends, and repository breakdowns | Metrics · Available |
| Operators need to know what automations did | Shows chain executions and outcomes in Automations › Activity | Automation activity · Available |
| An admin wants evidence before enabling | Replays supported historical PR/review evidence and sends nothing | Dry-run · Available for supported triggers |
Model the organization without inventing one
| Need | What Warestack does | Use |
|---|---|---|
| Start with two isolated repositories | Applies repository-scoped rules and chains | Scope · Recommended default |
| One team owns several repos | Applies team scope while keeping an individual owner per repo | Teams · Available |
| Only one subpath is sensitive | Applies path scope inside selected repositories | Scope · Available where the rule/chain supports changed paths |
| A repo has no reachable owner | Shows ownership readiness and can notify an admin channel | repository_without_owner · Available |
| People need attributable DMs | Confirms GitHub↔Slack identity before person-targeted delivery | People and identities · Available |
| Branch protection must become the gate | Deep-links to GitHub; Warestack does not silently change protection | Repositories · Optional after the observation period |
Choose the next step
- See representative outcomes: See it in action.
- Configure a bounded first pass: Start the pack.
- Let an org AI draft it: For AI agents.
- Browse every stable object ID: Rules catalog and chain kinds.
Last updated on