Auto-apply rules

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:

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.

Semantic rules

A semantic rule is a yes/no question instead of a regex. The decision model answers it for every user message, and the label is applied when the "yes" probability reaches the threshold. A regex can't express "this message is about billing"; a semantic rule can.

{
  "id": "billing",
  "name": "Billing",
  "autoRules": [
    { "semantic": "Is the user asking about billing, invoices or charges?", "threshold": 0.9 }
  ]
}

• Inert without the decision model — when it is off (or the Semantic label rules switch is), semantic rules are validated and stored but never evaluated.
• Off the critical path — regex rules run before the turn starts; semantic rules run in the background and their labels appear a moment later. Messages shorter than 20 characters are skipped, and so are rules whose label the session already has. A label you removed while the judgment was in flight is not re-added.
• One kind per rule — a rule has either pattern or semantic, never both.
• Automations fire — a semantic match fires LabelAdd automations like any other label change, which is why the default threshold is high.
• Privacy — the message (code blocks stripped, cut to 8k characters) is sent to the configured decision provider; every call is logged to ~/.fabric-agent/logs/decisions.jsonl without the text.

From the CLI:

fabric-cli label auto-rule-add billing --semantic "Is the user asking about billing?" --threshold 0.9

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.

Related

• 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.