Skip to main content
Captions are checked before publish against an editable rule set in rules.json. Brand-lint has two jobs: hygiene (catch things that read badly or break) and the humanizer layer (flag English AI-writing tells). The humanizer is a selling point, not an afterthought.
  • Errors block publish. The publish guard runs lint before each lane fires and drops any lane whose caption trips an error-severity rule (it logs a lint-blocked activity entry and ships nothing for that lane). Approval does not run lint, so run brand_lint first and fix every error before you approve: that is the operator or agent invoked check, and the publish guard is the backstop.
  • Warns are advisory.
brand_lint is both an MCP tool (see MCP) and the lint panel in the dashboard composer, so you get the same check whether you draft from an agent or from the UI.

​
The rules.json schema

A regex matcher runs against the caption text; flags default to g. A string matcher names one of the built-in matchers. Every rule carries a hint that tells the writer how to fix the line.

​
Editing, disabling, and extending rules

rules.json is the live rule set. Edit it freely.
  • Disable a rule: delete its object. (You can also soften it by flipping severity from error to warn.)
  • Add a rule: append an object that follows the schema.
  • Extend a rule: change its matcher or hint.

​
Built-in matchers

The built-in matchers are platform-aware: In the shipped rules.json only brokenLink is an error; the rest ship as warn, so an over-cap caption is flagged but does not block the lane. Soften or harden any of them by editing severity.

​
The humanizer rules

The shipped default also ships humanizer regex rules that flag English AI-writing tells: Each humanizer rule ships as a warn by default, with a hint that suggests the plain-language fix.

​
The workspace override

The shipped default rules.json lives at the install root. A copy at the workspace root, the rules.json next to your .env, overrides the shipped default. So you can keep your own house rules without editing the installed package: drop a rules.json in your workspace root and it wins.
On a multi-client instance, rules.json is resolved per client (in the active client’s subtree, next to its .env), so each project can keep its own house rules. A single-workspace rules.json is the fallback when a client subtree has none.
The brand name pendpost ships its own house style in these rules, including the em and en dash rule. Your overriding rules.json can keep, drop, or extend any of it.