Auto-apply rules

Attach regex-based auto-rules to labels in Fabric Agents so sessions get tagged (with extracted values) the moment a message mentions something recognisable.

A label can carry auto-rules: regex patterns that run against each user message. When a pattern matches, the label is applied to the session — optionally with a value extracted from the match.

Auto-rules let you keep your inbox organised without manual tagging. Mention a Linear issue key in a message, and a "Linear" label with the issue ID appears on the session automatically. Type [P0] in a message about a hot incident, and a "Priority: P0" label lands.

What an auto-rule looks like

{
  "pattern": "\\b([A-Z]{2,5}-\\d+)\\b",
  "valueTemplate": "$1",
  "description": "Issue keys like CRA-123 or FAB-4567"
}

Fields:

Field	Purpose
`pattern`	JavaScript regex. Capture groups get substituted into `valueTemplate`.
`flags`	Optional regex flags. Defaults to `gi` (global, case-insensitive). `g` is always enforced regardless of what you put here.
`valueTemplate`	Template for the extracted value. `$1` / `$2` / … expand to the matching capture groups. Omit to use the first capture group (or the whole match, if none).
`description`	Human-readable purpose. Surfaced in the label config UI; doesn't affect matching.

When rules run

Auto-rules evaluate when you send a user message (both fresh messages and ones that were queued while the agent was busy). They do not evaluate on:

Assistant responses.
Tool results.
Message edits or retries.
Label changes made by other means.

So new labels appear within a second of hitting Send.

What the regex sees

The rule runs against the last user message text, with code blocks stripped first:

Fenced code blocks ( ``` ... ``` ) are removed.
Inline code spans (`...`) are removed.

That way The fix for CRA-123 was to rename \isCRA-999`only matchesCRA-123, not CRA-999`. Code is for the agent; tags are for prose.

Typed values

Labels can declare a valueType (string, number, or date). When an auto-rule matches, the captured value is normalised for that type before being attached:

string — used as-is.
number — parsed as a number. Expansions like 45k → 45000, 1.2m → 1200000 are recognised.
date — parsed as an ISO date.

This lets you filter the inbox by numeric priority or chronological range, not just string equality.

Conflict resolution

Several rules on the same label that all match the same message produce one label instance per unique captured value. Duplicates (same label + same value) are deduplicated. A hard cap of 10 matches per message prevents runaway tagging from pasted logs.

If two different labels both match, both get applied. Labels don't compete.

What auto-rules can't do

Remove labels. Auto-rules only add. If you want "remove needs-review when the message says 'approved'", use an automation instead — automations can react to LabelAdd / LabelRemove events and call the appropriate RPC.
Match on assistant output. Only user messages trigger auto-rules. Pattern-match assistant output via automations (PostToolUse, SessionStatusChange).
Chain. A rule can't trigger another rule.

Examples

Linear / Jira issue keys

{
  "pattern": "\\b([A-Z]{2,5}-\\d+)\\b",
  "valueTemplate": "$1",
  "description": "Issue keys like CRA-123"
}

Linear issue URLs

{
  "pattern": "linear\\.app/[\\w-]+/issue/([A-Z]+-\\d+)",
  "valueTemplate": "$1",
  "description": "Linear issue URLs"
}

Priority markers

{
  "pattern": "\\[P([0-3])\\]",
  "valueTemplate": "P$1",
  "description": "Priority tags like [P0] or [P2]"
}

ISO dates for a due-date label

{
  "pattern": "\\b(\\d{4}-\\d{2}-\\d{2})\\b",
  "valueTemplate": "$1",
  "description": "ISO dates (YYYY-MM-DD)"
}

If the label's valueType is "date", the captured string is parsed into a date and the inbox can sort chronologically.

Amounts (numeric)

{
  "pattern": "\\$(\\d+(?:[.,]\\d+)?)\\s*([kKmM]?)",
  "valueTemplate": "$1$2",
  "description": "Dollar amounts"
}

With valueType: "number", $45k → 45000 and you can filter "sessions mentioning >$10k".

Hierarchy

Labels can nest — Priority → P0 / P1 / P2, Team → Engineering / Design. Auto-rules on nested labels work exactly the same as on top-level labels; the label config walks the whole tree when it evaluates.

Filtering the inbox by a parent label includes all descendants.

Editing rules

Rules are stored in {workspace}/labels/config.json alongside the labels themselves. Edit through the label editor UI, or edit the JSON directly — the app re-reads the config on each session's message send, so there's no restart needed for tweaks.

Labels — creating labels, hierarchy, typed values.
Automations — event-driven actions that complement auto-rules (including label removal).
Statuses — a parallel organisation axis; often used together with labels.

On this page