Rules flag what is missing on a pull request. They 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.
Do not number this pack 1–8. Those numbers collide with catalog rules 1–13. Agents and MCP must cite the IDs in this table (and in /catalog.json).
Recommended first enablement
| ID | Control | What it proves |
|---|---|---|
custom.linear_issue_required | Linear issue in Warestack’s store | Associated Linear ticket. A GitHub issue, a DEV-XXX string, or a branch name does not pass. Tightens catalog 6. |
| 7 | Linked ticket is assigned | Someone owns the work. |
| 8 | Linked ticket is active | Agreed workflow states (typically In Progress / In Review — you name them). |
| 12 | Diff aligns with the issue | Scope drift vs Linear title, description, and acceptance criteria. |
custom.conventions | Branch, PR, and commit conventions | <type>/<linear-issue>-<imperative-description>, Conventional Commit title, body with summary + bullets + Testing + Refs:, and a matching commit trail. |
custom.feature_test_evidence | 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 %. |
| 13 | Approvals by branch prefix | Proposed: feat/ and refactor/ = 2 humans; fix/, test/, chore/, docs/, ci/ = 1. Bots and the author do not count. |
custom.evidence_in_approval_body | Evidence in the approval body | Each counting APPROVED review cites a local command, a CI check, or a development-environment result. “LGTM” is not enough. |
Catalog 6 (“require a linked ticket”) accepts Linear or GitHub issue. The recommended Linear-first set uses custom.linear_issue_required so a GitHub issue alone does not pass.
For authorization and review evidence, use custom.linear_issue_required + 7 + 8 + 12 + 13 + custom.evidence_in_approval_body. The convention and test-evidence rules make that record understandable and honest; they do not fabricate a coverage percentage.
You can change prefixes, severities, Linear states, and which repos are in scope after you see findings. 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 Linear association, or only a key in the title/branch/Refs: | custom.linear_issue_required, 7, 8, 12 |
feat/ or refactor/ with fewer than two human APPROVEs | 13, 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 | Catalog 1–5, 9–11 are available; mark them later unless evidence makes one essential |
Do not
- Call Linear-in-store “rule 1.” Catalog 1 is concise pull requests.
- Treat a ticket string as association.
- Count bots or the author toward 13.
- Turn merge-blocking on until they ask.
When rules re-run
Warestack Rules evaluate on pull request events (opened, synchronized, edited). Submitting a GitHub review updates the live card immediately; it does not by itself re-run the check. A later PR edit or push will.
Findings remain inspectable on the pull-request event timeline. unresolved, acknowledged, and resolved are evidence states; do not describe an in-console waiver workflow that has not shipped.
Full catalog
Keep catalog 1–13 plus custom rules in the draft. Mark unused IDs later. How to propose a pack: For AI agents.