Rules flag missing evidence on pull requests, GitHub issues, workflow runs, and deployments. Pull-request findings show up on the GitHub Warestack Rules check, the Slack live card, Slack commands, and the Linear agent.
Activated only on the scope you approve. Severity starts honest. Merge-blocking off until you ask.
Recommended first enablement
| Rule | What it proves |
|---|---|
Require a Linear issue in Warestack’s storecustom.linear_issue_required | Persisted Linear association. Warestack resolves deliberate branch/title keys, a terminal Refs: trailer, explicit Linear issue URLs, and native attachments; an unresolved string, GitHub issue, or Jira issue alone does not pass. Tightens Require a linked ticket (pull_request.linked_ticket). |
Require linked ticket to be assignedpull_request.linked_ticket_assignee | Someone owns the work. |
Require active linked ticketpull_request.linked_ticket_state | Every verified GitHub, Linear, or Jira issue is in its provider-normalized active work category. |
Detect pull request scope driftpull_request.scope_alignment | Scope drift vs Linear title, description, and acceptance criteria. |
Branch, PR, and commit conventionscustom.conventions | <type>/<linear-issue>-<imperative-description>, Conventional Commit title, body with summary + bullets + Testing + Refs:, and a matching commit trail. |
Feature test evidencecustom.feature_test_evidence | feat/ source changes add relevant tests, or Testing names the behavior and a concrete reason. Generic “N/A” / “not tested” fails. No fake coverage %. |
Require approvals by branch prefixpull_request.branch_approval_policy | Proposed: feat/ and refactor/ = 2 humans; fix/, test/, chore/, docs/, ci/ = 1. Bots and the author do not count. |
Evidence in the approval bodycustom.evidence_in_approval_body | Each counting APPROVED review cites a local command, a CI check, or a development-environment result. “LGTM” is not enough. |
Require a linked ticket (pull_request.linked_ticket) accepts a verified GitHub, Linear, or Jira association in Warestack’s evidence store. The recommended Linear-first set uses Require a Linear issue in Warestack’s store (custom.linear_issue_required) so a GitHub or Jira issue alone does not pass.
The convention and test-evidence rules make that record understandable and honest; they do not fabricate a coverage percentage. Require concise pull requests (pull_request.size_limit) is a size cap, not Linear association.
You can change prefixes, severities, and which repositories are in scope after you see findings. Linked-ticket state uses each provider’s normalized lifecycle category. If a rule is noisy or too quiet, retune it — do not freeze the pack on day one.
Propose this when
| Observation in the last 14 days | Propose |
|---|---|
PRs with no persisted Linear association, including an unresolved deliberate branch/title key, terminal Refs: trailer, or explicit Linear URL | custom.linear_issue_required, pull_request.linked_ticket_assignee, pull_request.linked_ticket_state, pull_request.scope_alignment |
feat/ or refactor/ with fewer than two human APPROVEs | pull_request.branch_approval_policy, custom.evidence_in_approval_body |
| APPROVE bodies that are LGTM / looks good / tested | custom.evidence_in_approval_body |
feat/ source changes with no test file and no concrete Testing section | custom.feature_test_evidence |
| Huge PRs, mixed commits, review routing, fatigue | The rest of the catalog is available; mark unused rows later unless evidence makes one essential |
Do not
- Treat Linear-in-store as Require concise pull requests. That rule is a size cap (
pull_request.size_limit). - Infer an association from an arbitrary ticket-like string. Candidate Linear references come from a known team key in the branch or title, a terminal
Refs:trailer, or an explicithttps://linear.app/.../issue/...link. Warestack must still resolve and persist the association. - Count bots or the author toward Require approvals by branch prefix (
pull_request.branch_approval_policy). - Turn merge-blocking on until they ask.
Custom rules
A normal space-local custom rule keeps a reviewed interpretation of its prompt. Evaluation runs only those persisted checks; a rule without a usable interpretation cannot pass. Each check returns passed, failed, not_applicable, or not_evaluated. Warestack validates complete selector, alternative, and applicability coverage, then derives the overall rule outcome on the server.
Two evidence modes are intentionally dynamic:
- A rule that follows repository instruction files reads and interprets the applicable base-revision files on every evaluation.
- A rule whose description explicitly names another repository can use a bounded repository-context binding after space-admin approval. Each referenced repository independently uses one approved source—a branch, immutable revision, or pull request—and different repositories may use different sources. Warestack collects the selected paths or directories with GitHub App credentials, sends that selected content to the Space’s configured evaluation model, and reevaluates affected pull requests when a dependency changes.
Missing, incomplete, ambiguous, or unauthorized context is unavailable evidence, never a pass. See Custom rule interpretations.
When rules re-run
Pull-request rules re-run on pull_request opened, synchronized, and edited; on review submission or dismissal and qualifying review edits; when a review comment is created, edited, or deleted; and when review-thread resolution changes. Ticket-provider updates and approved cross-repository dependency changes also reevaluate the rules whose actual inputs changed. Stable scope results are reused when their relevant inputs are unchanged; a genuine input change records why reevaluation happened. The Slack live card then reflects the completed evaluation. Issue, workflow, and deployment rules run on their own event types.
Findings remain inspectable on the pull-request event timeline. unresolved, acknowledged, and resolved are evidence states. A space admin can acknowledge an eligible blocking finding in the console with a reason. A GitHub user with Maintain or Admin access to the repository can instead copy the exact command from the current Warestack Rules check into a new, otherwise empty PR comment:
/warestack ack <violation_id>:<64-hex-reference> --reason <reason>The command is revision- and finding-bound, can be consumed once, and does not require a Warestack account. The reason is required and limited to 1,000 characters. Warestack replies once, audits the result, republishes the current GitHub check, and removes the acknowledged finding from attention. A new head or materially changed finding reopens enforcement. Incomplete evaluation evidence cannot be waived. If a merge-blocking rule has no complete trusted outcome, Warestack Rules fails closed and offers a rerun rather than reporting a pass.
Full catalog
Keep the rest of the catalog in the draft. Cite unused rows by name and rule_key, and mark them later. How to propose a pack: For AI agents.