Rules
A rule says which files need a passing verdict from which agents. Slipmark checks every pull request against your rules and posts the result as a GitHub check called Slipmark policy.
What a rule is
A rule has three parts:
- A name people will read on the pull request, such as “Auth changes need a security review”.
- File patterns, one per line. The rule applies to any changed file that matches at least one pattern.
- Agents whose verdict counts. These are the
--bynames your agents attest with. Any one of them is enough.
A rule is met when every changed file it covers has a current, passing verdict from one of those agents. Current means the file's SHA-256 still matches the one in the attestation. Passing means the verdict was pass or cleared. A verdict on an older version of the file does not count, which is the whole point.
Rules apply to every repository the account owns. Add or turn them off on the Rules tab of your dashboard. Only organisation admins (or the account owner for a personal account) can change them.
Pattern syntax
| Pattern | Matches |
|---|---|
| ** | Any number of folders, including none. src/auth/** matches everything under src/auth/. |
| * | Any characters within one file or folder name. migrations/*.sql matches migrations/001.sql but not files in subfolders. |
| ? | Exactly one character. v?.json matches v1.json. |
Patterns are matched against the full path from the repository root, with forward slashes. A leading ./ or / is ignored.
Templates
The Rules tab offers one-click templates for the rules most teams start with. Each one fills in the form so you can change the patterns or agent names before saving.
| Template | Patterns | Agent |
|---|---|---|
| Auth and permissions need a security review | **/auth/** **/*auth*.* **/permissions/** **/middleware.* | security-reviewer |
| Database migrations need a DB review | **/migrations/** **/*.sql **/schema.prisma | db-reviewer |
| Infrastructure and CI need an infra review | .github/workflows/** **/*.tf **/Dockerfile **/k8s/** **/helm/** | infra-reviewer |
| Payments code needs a security review | **/billing/** **/payments/** **/checkout/** **/*stripe*.* | security-reviewer |
| Dependency changes need a supply-chain review | **/package.json **/package-lock.json **/pnpm-lock.yaml **/yarn.lock **/requirements*.txt **/go.mod **/Cargo.toml | dependency-reviewer |
The agent names are suggestions. Use whatever names your agents actually attest with, or several, such as security-reviewer, security-audit.
Suggested rules
Slipmark also looks at the files your agents attest most often that no rule covers yet, and suggests a rule for them. If your agents keep reviewing src/billing/ but nothing requires it, you will see a suggestion to protect it. Suggestions come from your own attestation records. Nothing is sent to an AI model and nothing is added until you save it.
How the check reports
On every pull request, Slipmark takes the list of changed files from GitHub, applies each enabled rule, and posts Slipmark policy:
- Success, “Every rule met”, when each covered file has a current, passing verdict from a required agent. A pull request that touches no covered files also passes.
- Failure, “N rule(s) not met”, with a table of each rule, how many changed files it covered, and which files are missing a passing verdict.
If the account has rules but no active plan, or every rule is turned off, the check is still posted, as neutral (“Rules not enforced: no active plan” or “No rules turned on”). GitHub treats neutral as passing, so a required check never holds up a pull request for billing reasons.
Rules are judged on Slipmark Cloud's own result for each verdict, re-checked against GitHub's copy of the commit, not on what CI reported.
The check only blocks merging once you make it required in branch protection. See step 5 of the quick start. On pushes to a branch, the changed files of the pushed commit are used instead.