It runs in Claude Cowork, Anthropic's desktop app for knowledge work — not a coding tool.

It ships in Anthropic's plugin repo next to six other design skills: accessibility review, design critique, design handoff, design system, research synthesis, and user research.

Install with npx skills add https://github.com/anthropics/knowledge-work-plugins --skill ux-copy.

The repo was last updated the day this was checked.

• Context — the screen, flow, or feature.
• User state — what the user is trying to do, and how they are feeling.
• Tone — formal, friendly, playful, or reassuring.
• Constraints — character limits and platform guidelines.

It applies five principles — clear, concise, consistent, useful, human — and a set of per-surface formulas:

• Error messages: what happened, why, how to fix it.
• Empty states: what this is, why it's empty, how to start.
• Confirmation dialogs: state the action and the count (Delete 3 files?), describe the consequence, and label buttons with the action (Delete files / Keep files) rather than OK/Cancel.
• CTAs: start with a verb, name the specific outcome.
• Tooltips, loading states, onboarding: one concept at a time, set expectations.

Tone is mapped to four states: success, error, warning, neutral.

1. It triggers on phrasing. The agent matches an incoming request against a list in the file's description to decide whether to load the skill. That list holds two kinds of entry:
   • Exact phrases — "write copy for", "what should this button say?", "review this error message".
   • Tasks — naming a CTA, wording a confirmation dialog, filling an empty state, writing onboarding text.
2. It fixes the output format — see the next row.
3. It checks for connected tools. Two cases, and it defers to a shared connectors file rather than naming a specific product:
   • A knowledge base is connected — it pulls the brand voice and style guide from it.
   • A design tool is connected — it reads the screen in Figma and takes character limits from the design.

• A recommended-copy line — the single answer.
• An alternatives table, with the columns Option, Copy, Tone, Best For.
• A rationale.
• Localization notes — idioms to avoid, character expansion, cultural context.

• 3.4 KB in one file. No scripts and no validators — everything it does, it does by instruction.
• No terminology source, and no access to a codebase or repo.
• It can't see the thing it is writing for unless a design tool or knowledge base happens to be connected.

• An alternatives table with a Best For column gives a reviewer a choice rather than a single suggestion. Choice teaches judgment; one line trains obedience.
• A required localization-notes section surfaces translation cost while the copy is still being decided, so “we’ll localize later” cannot hide expansion and plural problems.
• Ask for context, user state, tone, and constraints before polishing words. Without that gate, the skill invents a situation and writes beautifully for the wrong one.

The distinction it is built around: most AI copy tools judge each string on its own, which catches wording but not whether the screen works.

To answer it, the skill works at three levels rather than only on the words:

• The screen — whether the thing holds together: one clear primary message and next action, and a reading order that matches the order the user needs.
• The component — whether the copy follows the pattern for that particular surface, and whether the content belongs in that component at all.
• The string — wording, approved terminology, and the house style guide.

It is also explicitly allowed to conclude that the fix is structural rather than verbal — recommending a component or layout change instead of a rewrite.

• Quick check — hierarchy, state of mind, path forward, style guide, glossary, then one reviewer subagent pass in a clean context.
• Full review — all of that, plus three additions:
  • It answers its own questions about the feature from the product code before asking a person.
  • Before any copy work starts, a fresh subagentA separate agent instance with its own clean context window, spawned to do one bounded job (validate a draft, role-play a user) and report back. The clean context is the point: it can't be biased by the main agent's reasoning. looks at the rendered screen with no context and answers one question: does this screen make sense as a whole, or is it the wrong screen for the job? If it's the wrong screen, no amount of rewording will fix it, so the copy work pauses there.
  • On any screen with more than one button, a separate subagent is shown only the button labels and asked which it would click. A mismatch with the intended action is a finding.

The steps that run inside either mode:

• Map the hierarchy and run a fixed diagnostic against it before touching any words.
• Check the copy against that component's own rules, from a catalog of 41 reference files. If the message doesn't suit the component it's been put in — an error stuffed into a toast that disappears before it can be read, say — it recommends changing the component rather than rewording the text.
• Work out whether the user can actually do anything about what the copy is telling them — the step its instructions call "the most critical". If an error says a payment failed, is there a button on that screen to retry it? It reads the code to find out rather than assuming. An action the user can't see — buried in a hover tooltip or a collapsed menu — is treated as no action at all, and the gap gets flagged as a design problem rather than written around.
• Check the terms against Wix's internal UX writing glossary — the company-wide record of approved wording — swapping anything prohibited for the approved term.
• Hand the near-final copy to a reviewer subagent — a fresh instance with none of the preceding reasoning in its context — for a cold pass against the guidelines.

• The corrected copy first — always the actual fixed wording, never just a flag that something is wrong — shown against the original.
• An Element / Before / After table when a whole screen is under review; numbered options when several approaches are genuinely viable.
• The reason, in at most two or three one-line bullets.
• Design flags, one line each, written as problem then recommendation. Not optional when the path-forward step found a missing action, the wrong component, or a hidden warning.
• Everything else pushed to the bottom — an unverified assumption, a persona-panel finding — under a plain "More detail" heading, capped at about five lines.

• It never grades its own work. The review always runs in a fresh subagent, never as role-play inside the conversation that wrote the copy — the skill's own reasoning is that a model reviewing its own output rates it favourably no matter how critical you tell it to be.
• What the creator says is a claim, not a fact. Where the code can settle a question, it has to read the code rather than take the answer on trust — and if the two disagree, say so plainly instead of softening it.
• It must not invent how the user got there. The arrival route is traced from the code, because both the cold read and the persona panel take it as an input; a made-up entry point produces confident reactions to a journey nobody actually takes.
• Anything it couldn't verify is labelled as such in the output, rather than presented as established.
• One persona's reaction isn't a verdict. A finding counts when two or more independently hit the same confusion, or a predicted click misses — and after a material rewrite it re-runs the check once to confirm the fix landed.

Every one of those constrains how confident the output is allowed to sound. None of them measures whether it was right.

• Not inspectable. File structure, line counts, and the persona definitions aren't public — this card is built from the skill itself, read internally.
• Adoption is not quality. The figure above says people run it, not that its output is good.
• No deterministic checker. The one mechanical step is the glossary call; everything else is judgment by a model.

• Separate the thing that writes from the thing that judges. The review runs in a fresh subagent with none of the drafting reasoning in its context — role-playing a critic in the same conversation doesn't work, because the model rates its own output favourably however you word the instruction.
• Ask whether the user can actually do the thing your copy implies. Read the code to find out rather than assuming, and treat an action nobody can see — behind a hover, an icon, a collapsed menu — as no action at all.
• Let the review conclude "this isn't a copy problem." Giving it permission to recommend a different component or a layout change is what stops it polishing wording on a screen that shouldn't exist in that shape.
• Test decision screens by showing only the buttons. Hand a fresh subagent the labels with no surrounding copy and ask which it would click; a mismatch with the intended action is a finding that a "is this clear?" question never surfaces.
• Label what you couldn't check. Unverified assumptions travel into the output marked as unverified instead of being presented as fact.

The build lesson underneath all of it: six months of improving the prompt didn't work, and splitting the job into separate verifiable checks did. The quality came from the architecture, not the instruction wording.

• A full terminology guide, when you give it a feature area. It works out which concepts in that feature need an agreed word at all, then writes an entry for each one. That file becomes the place the team looks up what to call things.
• A single recommendation, when you name the candidate words yourself. It researches that one concept, then returns a verdict on which word to use, a table of what each competitor calls the same thing, and a confidence rating.

1. Extract candidate concepts from the artifacts.
2. Research each one against four sources — competitor research, prior UX research, a scan of real support tickets and feature requests for how users describe the thing themselves, and a live check against Wix's own internal glossary.
3. Filter out the ones that don't need deciding. Not every word in a feature is a terminology question. It keeps a concept only if all three are true: users will see the word on screen, there is more than one reasonable thing you could call it, and different teams would otherwise call it different things. Anything that fails one of those is just writing, and stays out of the guide — which is what stops the guide filling up with words nobody was ever going to argue about.
4. Define it in three fields:
   • Definition — what the thing is.
   • Context notes — scope and boundaries: which objects it applies to, and where it stops.
   • Example usage — one sentence showing the pattern.
5. Write it to the guide, weighing the four sources in a fixed order when they disagree: the internal glossary first, then how users actually talk about it, then industry convention, and plain language last.

Throughout, every claim has to trace to a source, and the agent is explicitly allowed to say it doesn't know.

• Wix's internal glossary — what the company already calls this. A match in the same product area is binding; a match somewhere else is flagged rather than treated as a conflict.
• User language — how people describe the thing in support tickets and feature requests.
• Industry convention — what competitors and the wider field call it.
• Plain language, last, when nothing above settles it.

• Definition — what the thing is.
• Context notes — which objects it applies to, and where it stops.
• Example usage — one sentence showing the pattern.

• Not inspectable. File structure and line counts aren't public — this card is built from the skill itself, read internally.
• No accuracy measurement. Nothing checks whether a recommended term was the right one.
• No deterministic checker. The decision hierarchy is applied by a model, not enforced.

• Filtering out the words that don't need a decision — not treating every single word as a term that's worth fighting over.
• Ranking the four sources in advance, so a disagreement resolves by rule and not by the agent.
• Making terminology decisions before the copy exists. Terminology decided during design is a decision; if it's decided after launch, it becomes a migration.

Selected rules from its checklist, in its own terms:

• Remove first-person pronouns entirely. Refer to the AI as Gemini and the infrastructure as the system or the CLI.
• Use the system for execution, Gemini for analysis — doing versus thinking.
• The verb signal check: use definite verbs (is, will, must) for what the system actually did, and hedged ones (suggests, may, appears) for anything the model came up with — so the user can tell a fact from a guess.
• The skip test: do the first three words describe the user's intent? If not, rewrite.interesting
• Goal-first sequence: [To accomplish X] + [do Y].
• Status updates under five words, and for tasks over three seconds cycle through sub-states ("Parsing logs…" then "Identifying patterns…") rather than a static spinner.
• Telemetry over etiquette: remove "Please wait", "Thank you", "Certainly"; replace with progress data.
• Pair every error with exactly one fix — a command, a link, or a suggested prompt such as "Ask Gemini: 'Explain this port error.'" Human-readable explanation before machine error codes.
• Reserve warnings for destructive or irreversible actions, and every warning must name a corrective action.
• Use technical metrics (latency, tokens, compute) instead of "speed" or "cost".interesting

• It triggers on requests to review text or user-facing strings.
• It assigns a role first — "Act as a Senior UX Writer" — before applying the checklist.
• Terminology routes to a separate file. Terms are checked against references/word-list.md. Anything marked "do not use" or "use with caution" gets corrected to the preferred term.
• One surface has its own rules. If the settings schema file is modified, a distinct rule set from references/settings.md applies instead, so settings labels and descriptions follow their own conventions.

The failure mode to teach: a checklist without the product’s own word list will “pass” copy that uses the wrong product name in perfect grammar. Pair mechanical rules with a glossary, or the review becomes a spelling bee.

The format is a numbered list where every item names the principle that was broken, then shows the before and after against it:

1. **{Rationale/Principle Violated}**
  - ❌ "{incorrect phrase}"
  - ✅ `"{corrected phrase}"`

Naming the violated principle on every item is what makes the output auditable — a reviewer can check the call against the rule rather than taking the rewrite on trust. The skill also tells the agent not to write anything outside the list — no intro, no summing up — so the output stays a clean list another tool can read.

• Scoped to one product's strings. It reviews the repo it ships in, and nothing else.
• The rules are shaped by a terminal. The five-word status limit and the telemetry rules assume a CLI, not a consumer app.
• No deterministic checker. Nothing here fails a build — the word list is read by the model, not enforced by a linter.

• Naming the exact verbs for each situation — definite ones for what the product actually did, hedged ones for what the model worked out — so hedging is a rule rather than a matter of taste.
• Giving a surface with different conventions its own reference file instead of burying an exception in the main list.
• Making every suggestion name the rule it came from, so a reviewer can check the call rather than trust the rewrite.

• DESIGN.md — what the interface looks like and says. Design tokens, the component inventory, and a Voice & Content section.
• A skill called ux — what it does as the user moves through it. Empty states, loading states, errors, long lists, draft safety, button hierarchy, progressive disclosure.
• A skill called ux-audit — the reviewer. Checks one finished screen against the other two.

Nothing to install: the files sit in the product repo — DESIGN.md at the root, the skills under .agents/skills/ — so any agent working in that codebase reads them as part of its instructions.

The ux skill is marked user-invocable: false. Nobody summons it; the agent loads it on its own whenever the work touches a user-facing feature.

From the Voice & Content section, verbatim:

• A closed term list: "Never alternate synonyms (no 'bot / assistant / AI agent' drift for Agent)," followed by the full canonical list — Workspace, Agent, Group, Context, Memory, Integration, Skill, Topic, Page, Provider, Evaluation, Benchmark, Dataset, Test Case…
• A closed verb set: "reuse the same verb for the same action everywhere: Create / Connect / Run / Pause / Retry / View details / Clear Memory."
• "Name actions with a verb and a noun (Create Agent, Delete Session), never a bare Confirm, OK, or Submit."
• "In-progress states use a present participle with an ellipsis (Generating…, Saving…)."
• "Confirm outcomes by naming the specific thing that changed; skip 'successfully' and superlatives."
• "Layered, not split — one main line that is simple and actionable, plus an optional second line… Don't ship 'simple vs pro' variants."

Two rules go further than wording and put numbers on tone.

• A warmth budget. "Default to 80% information, 20% warmth; at key moments (first run, empty state, long waits, failures, data-loss risk, collaboration conflicts) up to 70/30. Hard cap: at most half a sentence to one sentence of warmth, always followed by a clear next step."interesting
• A fixed order for sensitive messages. "1. Acknowledge the situation, without judgment. 2. Restore control — pause, replay, edit, undo, clear Memory, view Context. 3. Give the next action."
• Three named anti-patterns: preachy encouragement ("don't worry"), grand narratives, and over-anthropomorphising ("I understand you").

1. You point it at one screen. A whole-app sweep in a single pass is explicitly out of scope. Nobody invokes the ux skill; the agent loads that by itself whenever the work touches a user-facing feature.
2. Three kinds of evidence are available to it — the source code (L1), a screenshot of the rendered page (L2), or a click-through of the working product (L3). The code is cheap and always gathered; the other two cost more and get gathered when a finding needs them.
3. Every claim has to rest on evidence that can actually support it. The skill ships a list pairing each kind of claim with the evidence that settles it — the coverage matrix:
   • "There's no error state." The code is evidence for this.
   • "Send is the most prominent button." The code isn't enough to determine this, so the agent would need a screenshot for better evidence.
   • "The page takes too long to become usable." The code or a screenshot can't answer this. The agent would need to actually click through the product to find out.
4. Gaps that keep recurring get added to the checklist as new checks, so the review grows out of what it kept missing.interesting

• DESIGN.md — the canonical term list, the verb set, and the numeric tone limits.
• The ux skill — the rules for states the interface only produces at runtime.
• A pattern language from outside the company — Jenifer Tidwell's Designing Interfaces, kept in the repo as a catalog the audit is measured against alongside the checklists.
• The screen under review, at whichever depth the run allows: the code, a screenshot of the render, or a click-through of the live journey.
• Twenty-five completed audits committed to the repo, as worked examples of what the output should look like.

• Patterns in use — which interface patterns the screen uses, and how well, grouped by family.
• Strengths worth keeping — an audit that lists only what's broken has turned into a bug report.
• Gaps, ranked. Each one names the rule it breaks, the depth it was found at, the evidence, and a one-line fix. Three severity tiers: breaks trust, dead-ends the user, or friction.
• Feedback on the checklists themselves — which of these findings apply beyond this one screen.

Every finding cites its evidence — a file and line number, the screenshot, or the captured measurement. The skill's name for the rule: evidence, not vibes.

• Written for one product. The term list and the verb set are LobeHub's own words, so the method transfers but the contents don't.
• No deterministic checker. The closed lists are written to be mechanically checkable, but nothing in the repo checks them — an agent reads them and is trusted to comply.
• Nothing to read means nothing to find. A capability that was never built leaves no code, no failing branch and no button, so a review of the repo can't surface it. Their own example: an audit of the OAuth consent screen reported button-hierarchy and retry gaps, and missed that the screen gives the user no way to switch account.
• No content designer was involved at any point.

• Writing the terminology as closed lists — here is the full set of words you may use, rather than a set of words we prefer. A closed list can be checked; a preference can only be argued.
• Putting a number on tone — a ratio, a hard cap, and a named list of the moments that earn the warmer setting, instead of asking a writer to judge how friendly is too friendly.
• Pairing each kind of claim with the evidence that can support it — the coverage matrix, which is what stops a reviewer asserting something about the rendered screen on the strength of the code.
• Filing each rule by what it governs — the words and the visual tokens in one file, the way the screen behaves as someone uses it in the other. A new rule has one obvious home, so the two files never drift into saying the same thing differently.interesting

It exists because Intercom already had a content design agent (VERBI, next card) but it lives in a browser, and designers had moved into Claude Code to prototype — so content feedback was arriving at design review, too late to be anything but rework.

How it reaches other designers isn't stated. A shared repo, a plugin, or copied folders are all possible; what's known from the format is that a skill is a folder of markdown files with no server behind it, so distributing it means getting those files where each designer's agent already looks.

• Code you're prototyping — reviewed inline as you build.
• A screenshot of a design — it reads the UI and validates.
• A Figma URL — fetched via the API; it checks every text layer.
• Raw text — a quick spot check.

• Foundational rules from Surge: punctuation, capitalisation, character limits, text patterns.
• Per-component rules: accordions, buttons, badges, labels.
• Voice and tone.
• Feature-name conflicts — catches a name that clashes with an existing feature.
• User research, pulled in when relevant.

• Extract the content out of whatever was handed over — code, screenshot, Figma file, or pasted text.
• Identify the component each string belongs to — is this a button label, an accordion header, a badge?
• Check that component's rules, not the general ones.

A real rule set, from the skill's validation-workflow.md, for buttons:

Verb-led
  Start with an action word
Max 4 words
  Scannability across languages
Action-oriented
  Describe what happens when clicked
No period

Every rule carries its reason in the same line, so the skill can explain a flag rather than only raise one.interesting

Two more mechanics, both given in reply to a direct challenge that agents tend to ignore parts of a skill:

• A strict checklist the skill must follow — an ordered list to work through, not prose describing good practice.
• Every source file is tagged with when to read it — always read first, read per component, search when needed, or suggest. Without a tag, the agent decides for itself whether a document is worth opening, and a document it isn't sure about is one it skips.

Size: about 1,000 lines of markdown across 5 files, of which only the main SKILL.md (about 120 lines) loads on activation; the rest are pulled in on demand. He reached that size by asking Claude to optimise the skill's own spec, which trimmed it 70% without changing behaviour.

• Internal and unreleasable as-is, so nothing here can be inspected. His guidance for replicating it: document your guidelines, then write a SKILL.md telling the agent to validate against them.
• Only the author's account exists. No article, no repo, no third-party report.
• No deterministic checker. Character limits and punctuation rules are the kind a linter could enforce; here a model reads them.

• Validate against the design system while someone is still prototyping, not only in a late content review. Catching hierarchy and missing states early is cheaper than rewriting a polished screen.
• Accept more than one input shape — code, screenshot, or Figma text — so the same standard shows up wherever the draft lives.
• Use the tool as a teacher of the guidelines, not only as a gate. If designers learn the standard by seeing it applied, you spend less time restating it in critiques.

It exists because the requests never stopped — review this flow, rewrite this screen, name this feature — and there were always more of them than one person could answer.

Why not the obvious alternatives: Gemini's custom Gems couldn't be shared with other people, so a tool only one person can use doesn't scale a team. ChatGPT was customisable but only with static files — it couldn't point at live URLs, so every style-guide change would mean re-uploading.

• Role — a content designer supporting product designers.
• Employer — Intercom, and its products.
• Resources — the sources it is allowed to draw on.
• Tone — the voice to answer in.
• UI components — must follow the design system's guidelines only.
• Use cases — the tasks it handles.

From there it retrieves from the curated collection and answers in chat.

Three guardrails sit in that same system prompt, so they apply on every response rather than at a separate review step:

1. Against flattery — inform, challenge, and assist; never placate; don't agree by default; if something's wrong, say so.
2. Against invention — if the answer isn't in the resources, say you don't know; don't guess and don't answer from general knowledge.
3. Against padding — keep answers short; cut the fluff; skip social niceties; only go long if asked.

Together they describe a content partner who pushes back, admits ignorance, and doesn't waffle.

• The style guide, including a list of the rules broken most often.
• Tone of voice guidance.
• The product glossary — hundreds of feature names.
• The monetization glossary — pricing and plan naming.
• Product marketing messaging guides.
• Research insights.
• Surge, the design system. It lives in Storybook, which is served to Glean through Glean's Indexing API — so component guidance is read live and never goes stale. This is what lets the agent answer something as specific as the correct date format for Japan.
• Two public Intercom sites.

• The system prompt needs periodic tune-ups as the business changes. He describes this as minor upkeep.
• You have to go to it. VERBI is a place you open in a browser, so it only helps when someone remembers to ask. That is the gap the validation skill in the previous card was built to close.
• The two tools share a corpus but are not interchangeable. Answering questions on demand and checking work in progress turned out to need two different products.
• Only the author's account exists. Internal, so nothing here can be inspected.

• Put the guardrails in the system prompt, not in a separate review step, so they apply to every answer.
• Get the live source indexed instead of maintaining a copy of it. Serving Storybook to Glean through the Indexing API is what makes the component guidance read live rather than pasted into a document and re-pasted after every change.interesting

• It classifies the question before retrieving. It works out the question type first, then searches only the part of the documentation that matches it rather than the whole corpus. Built with Dust's "Tools" feature — each use case listed against its knowledge base, the documentation labelled clearly ("Terminology," "Email guidelines"), and the routing logic in the instructions.
• Temperature set deliberately low — 0.2, labeled "Factual" — after starting at 1.0 and getting "a flood of hallucinations."
• The model was chosen separately from the retrieval design, on output quality: ChatGPT → Claude Sonnet → Claude 4.
• It is instructed to admit ignorance when retrieval finds no confident match:

  If you don't find the information in your database:
  → say that you don't know
  → don't guess and don't give answers based on general knowledge

  The writeup is explicit that this reduces hallucinations rather than eliminating them.

• Standalone in Dust, not yet integrated into where the work happens — so it only helps when someone goes to it.
• Only the author's account exists, and it's from 2025 — so parts of it may be out of date.
• No deterministic checker. Everything rests on retrieval plus a low temperature.

• Classify the question before retrieving, rather than searching the whole corpus every time.
• Cover the basics before you polish anything. Her advice on what to write first is to "start with the most key documents," which "already solved most cases" — and not to "necessarily aim for pitch-perfect documentation, but at least cover all the basics the AI will need."
• Decide what you are building before you tune it. A temperature of 0.2 reads as the wrong setting for anything to do with writing — until you accept what the thing actually is: "You're not training a Content designer, you're training an assistant that can focus on the guidelines and make sure to apply them."

The problem it was built against: too many content surfaces, not enough governance, and quality dropping in teams with no content designer — plus the plain time cost of routine copy and release notes.

The writeup is by three content designers: Tim Pike, Ann Henley, and Aaron Ruby.

• Content Assistant in Slack — general drafting and review.
• A Release Notes agent in Jira Service Management — where release work already happens. This one carries the 88% figure.
• A Brief Builder for PMs — structures a documentation request so the content nearly writes itself, fixing the input rather than the output.interesting

Every request needs to include:

• The copy itself, pasted in, when the ask is a review.
• A description of the surface and situation — which component, which screen, who is reading it — when the ask is a draft.

Real examples from the writeup:

• !content can you review this message: "Authentication was successfully completed…"
• !content I need text for an info toast message that appears when you click on a data insights card…
• !content write a tooltip to explain what headcount used is to a user…

Users include engineers, PMs, and marketing — not only designers.

1. Work out the intent and which standards are needed. Their example: a success-message request needs the structural and writing guidelines for success messages, plus the product glossary.
2. Read those guidelines and apply them.
3. Draft the copy.
4. Prepare the draft with a rationale — which sources and guidelines it used.
5. Run a quality check on its own output, then reply.

Step 1 is the part that makes this more than a prompt: the standards it fetches are held as what Atlassian calls context stores — content standards structured so a model can read and apply them, rather than a style-guide PDF.

Where the stores physically live isn't stated. Rovo reads across Jira, Confluence, Slack, and the rest of Atlassian's tools, so the standards sit in the documents those tools already hold.

Their warning is the practical core of it, and it applies to any grounding corpus:

• Stale standards cost you time. If the guidance hasn't been updated since 2023, teams spend longer editing the output than they saved.
• Undocumented standards cause hallucination. If the source of truth is buried in a Slack thread, the agent invents one.

The rationale is produced first, before the draft. They report that ordering it that way improved the quality of the answers, not only their auditability.interesting

• Work is routed by risk into low, medium, and high-touch human review lanes, rather than everything getting the same read. Their reasoning: a minor release note and a pricing flow carry fundamentally different risk.
• A human edit counts as data. "Every AI-generated draft that gets edited by a human is a signal. We wire those back into the system so that it gets smarter, not just faster."interesting Efficiency and quality metrics are tracked on a dashboard.

So the loop is real. What is missing is a baseline — nothing establishes whether the output was right to begin with.

• 1,500+ requests through the Content Review Desk in under 9 months
• Drafting time down from a couple of hours to about 15 minutes
• Release notes production time down 88%
• 700+ hours returned to content designers
• Hundreds of monthly users

All of these are time and volume figures. None of them is a quality measurement.

• The review rubric isn't published. The criteria that sort a request into low versus high-touch review are missing, as is who staffs each lane — and that rubric is what decides whether the model saves time or just moves it.
• The writeup reports only successes. No failure modes and no course corrections.
• Internal. Only the authors' account exists; nothing can be inspected.

• Make the agent give its reasoning before its answer, rather than after. Atlassian found it improved the copy itself, rather than only making the tool easier to check.
• Name the standards it used in the reply, so a writer can argue with a specific guide instead of with “the AI.”
• Put the assistant in the tools people already open (here, Slack). A perfect content bot nobody switches to is not a system.

The writing rules travel through the same pipeline as the component metadata, so the call that tells an agent a component's props can also tell it how to word that component's copy.

It only covers the design system, and it says so. Atlassian's company-wide content standards sit in a separate internal store the tool tells the agent to fetch as well — so a full content answer is meant to come from two sources, not this one. Detail in Grounding.

• Eleni Misthos — Senior Developer Content Designer.
• Kylor Hall — Principal Prompt Engineer.
• Farid Sabitov — Lead Design Technologist.
• Julian Fleetwood — Lead Content Designer.

Four ways in:

• The hosted URL — point any agent-tools client at it.
• An npm package — @atlaskit/ads-mcp, run locally.
• An internal agent skill — atlassian-design-system, published with @atlassian/skills, Atlassian-only. It bundles progressive-disclosure guidance for tokens and components with agent-oriented workflows, generated from the same source.
• Flat files — the content guidance also ships as llms-content.txt, ~29 KB of markdown, for anything that can't call a tool.

• Hosted: https://mcp.atlassian.com/v1/ads/public/mcp over HTTP.
• Local: npx -y @atlaskit/ads-mcp.

It was also wired into the design system's help channel in Slack, so the same tools answer questions there.

You ask the agent for something — "write the empty state for this screen," "check this error message" — and the agent decides the design system's guidelines are relevant, picks its own search terms, and makes the call. Then it writes with the returned rules in context.

What that tool covers, from its own description:

"Content & UX writing: messaging types (empty state, error, success, warning, info, feature discovery), voice and tone, inclusive language, grammar and style, date/time copy handoff, vocabulary pointers."ads_get_guidelines, tool description, retrieved from the live server 2026-08-24

Its stated use cases include "writing or reviewing user-facing copy."

What comes back. Asked for empty state, voice and tone, and error message, it returns roughly 22 KB of markdown — per-surface rules, not principles:

• "Limit your CTA to one or two words."
• "Write in sentence case and don't use punctuation unless it's a question."
• "Keep messages one to two sentences long."
• "Use imperative verbs such as 'Try', 'Remove', or 'Create' … instead of vague terms such as 'OK'."

• It fuzzy-matches the agent's terms against guideline keywords and body text, so "empty state" finds the empty-state page without an exact title match.
• It returns concatenated markdown for the matches — the guidance itself, not a summary of it.
• It never looks at your copy. Nothing is checked, scored, or flagged. The agent gets the rules and is responsible for applying them.

• The design system's own schemas — this server. Every answer is generated from them rather than retrieved from prose docs, which is why component guidance can't go stale.
• Atlassian's company-wide content standards — held in an internal store the tool tells the agent to fetch separately, by calling get_content_standards_docs on Atlassian's internal Context Engine server.

"When working with content, use this tool alongside the Context Engine agent-tools tool get_content_standards_docs for Atlassian-wide content standards (CDSTD/BAIT-style org guidance); this tool supplies ADS-specific foundations."ads_get_guidelines, tool description, retrieved from the live server 2026-08-24

So a full content answer is meant to come from both sources: company-wide voice, terminology, and editorial rules from the internal store, and how those apply to a specific component from here.

Those schema files live in the design system's own repository, next to the source code of the components they describe. So a component and the rules for using it are edited in the same place, by the same people, in the same change.

From that single source they generate "content for the ADS agent tool server, the design system skill, DESIGN.md files, and whatever other formats we need in the future."

Writing the rules once and generating every agent format from them is what stops the agent tool server, the skill, and the DESIGN.md files disagreeing with each other.

• 4.9% more accurate code.
• 11% fewer errors.
• 26% fewer tool calls.
• 34% faster task completion.
• 16% fewer tokens consumed.

• Content is retrieval-only. A tool hands the agent the rules; nothing checks a string against them. ads_get_lint_rules returns ESLint rules for code, not copy.
• Half the grounding can't be inspected. The company-wide content standards this tool defers to sit on an internal server, with no public documentation or endpoint.
• A separate "52% accuracy improvement" is claimed for unnamed "specific queries," which isn't checkable.
• Its relationship to the Content Assistant is undocumented. Neither writeup mentions the other. They serve different people — one is a Slack agent you go to and ask, the other a tool an agent calls while building — and both draw on company-wide content standards restructured for machines, but whether that is the same corpus is not disclosed.

• Serve content guidance as a tool call, not only a document. A file has to be found and fetched; a tool gets called mid-task, with terms the agent chose.
• Generate every agent format from one source — agent tool server, skill, and DESIGN.md from the same definitions, so they can't drift apart.
• Put routing rules in the tool description. When to call it, and when not to. The agent reads that before it reads your content, so it decides what to fetch.
• Say what you don't cover, and where it lives instead. Declaring "this covers the design system; company-wide standards are over there" keeps two teams from duplicating each other's rules, and stops an agent treating a component note as the whole editorial standard.

Two things prompted it. Research found designers were prompting 30–50 times to design a single workflow with AI, iterating on structure and visuals before content came up at all. And content design roles had shrunk across the industry, leaving PMs, engineers, and product designers writing copy with no content partner.

Their diagnosis of why the existing guidelines went unused: people weren't applying them because they didn't know how to evaluate what quality, on-brand content looks like.

Inside the company it ships through a central AI skill directory where employees register, find, and install validated skills — and updates push automatically to everyone who has one installed, which is what stops the standards drifting between teams.

Their before-and-after on the same toast message:

• Plain Claude rated the message compliant and suggested no changes.
• With the plugin enabled, it loaded the right reference files, flagged the issues, and suggested the correct pattern from their confirmation guidelines.

• One skill holds the standards; the rest read from it. Everything about what "good" looks like lives in that one place, and a request routes automatically to whichever specialized skill fits — which then reads the shared references rather than carrying its own copy to drift out of step. Their stated reasons for that shape: retrieval accuracy, token usage, and management overhead.
• A skill loads the reference files for the surface in question, then checks the content against those specific standards rather than general best practice.
• The structure was designed, not accepted. They mapped several possible shapes in FigJam before committing, deliberately rather than simply taking the model's recommendation.

• Overlaps between skills.
• Inconsistencies between them.
• Places where two skills were competing to trigger on the same conditions.

She then rewrote the skill descriptions based on user research — the trigger language had to match the words designers actually use, not the words the system uses.

That audits the system's structure. Nothing measures whether its content judgments are right.

• Their own stated limit: the plugin scales their system, but it doesn't scale craft.
• Not public: the skill files, and the list of specialized skills.

• Keep the standards in one skill and have the others read from it, rather than giving every skill its own copy to drift out of step.
• Audit your skill set for competing descriptions. Two skills triggering on the same request is a failure mode that stays invisible until someone looks for it.
• Write the trigger words people actually say, taken from research rather than from your own vocabulary.

The reasoning behind the format: a style guide living in a wiki doesn't get applied. Shipping it as a dependency makes it versioned, updatable, and enforceable at the point where work gets merged.

Their stated design principle translates as "design starts from words."

Install it as a dependency and name the preset in the textlint config. Every rule in the pack then runs on whatever files textlint is pointed at, alongside any other presets in the same config.

The architecture lesson is why the format matters more than any single rule:

1. Someone changes a house term — the package gets a new version, with a changelog entry.
2. A product team pins or upgrades the same way they would a library, after reading the diff.
3. The check runs where the merge happens — command line, build, or editor — so the style guide is not a wiki page someone meant to open later.

That is the failure mode it is designed against: a beautiful guideline that nobody applies because it lives in the wrong place. Shipping the guide as software does not make the rules wiser; it makes them present.

• Japanese only, and specific to SmartHR's house style.
• 120 stars against the AI-writing preset's 1,100 — a company's own rules are useful mainly to that company.
• The rules are UI-writing rules, but the checker can't tell where the text will appear. textlint reads text — .txt and .md by default, HTML with a plugin, and in principle a strings file if someone writes a processor for it. What it never gets is the knowledge that this string is a button label with twenty characters of room, so a character limit or a per-component rule can't be expressed in the pack at all.
• No English equivalent exists. No company in this report publishes its UX content guidelines as an installable, versioned package.

• Publish the house style as a versioned package, not a document. This is the clearest example in the report of treating content standards as software — with releases, diffs, and a version number a team can pin.
• Keep the terminology dictionary in the same package as the rules, so the words and the style ship together.

Its framing: content quality doesn't scale when one person reviews everything, so catch the 80% of issues that are obvious and let a human spend time on the 20% that needs expertise.

A build workflow rebuilds an installable zip on every change, and the repo is versioned like software.

Tone example for a frustrated user: "Payment failed. Your card was declined. Try a different payment method." against the poor version, "Error 403."

• It loads itself. Nobody has to summon it — the frontmatter description is deliberately long, naming every surface it covers (buttons, labels, errors, notifications, forms, onboarding, empty states, success messages, help text) and every verb (writing, editing, auditing, reviewing), so a matching request pulls it in.
• It checks one standard per pass — four passes over the copy, in this order, each with a definition it checks against:
  • Purposeful — it helps the user or the business reach a goal.
  • Concise — every word has a job.
  • Conversational — write how you speak.
  • Clear — plain language.
• Reading level is set by who is reading — 7th grade for general audiences, 10th for professional ones.
• Length is capped per surface, with its own sentence-length and character-count targets depending on where the string sits.
• Active voice is a proportion, not an absolute — about 85% of the time, rather than a rule with no exceptions.interesting
• A small entry file, the rest on demand. SKILL.md holds the framework and the patterns; an accessibility guide, a usability checklist, the detailed patterns and a voice-chart template sit in references/ and load only when needed.
• Templates and worked examples ship with it — fill-in templates for error messages, empty states and onboarding, plus before-and-after pairs with analysis and scoring.
• No code anywhere. Everything it does, it does in prose.

• Generic by design. It carries published doctrine, not your house style, so it won't know your terminology or your components.
• No deterministic checker. The testable numbers — 85% active voice, a reading-level target — are the kind a script could measure, and nothing does.

• Before/after pairs as the doctrine format. They teach a model, anchor a judge, and double as eval cases — one authoring effort, three uses.
• Turn a framework into a sequence of steps rather than a list somebody has to remember. A list gets skimmed and half-applied, whereas steps in a fixed order get worked through.
• Put testable numbers in the guidance, so the advice can be checked rather than only agreed with. For example, "keep sentences short" becomes "under 30 words", which is something a script can count and a reviewer cannot argue with. You can also say "~30 words" if you don't want it to be too specific.

The whole pipeline that produced the model is published alongside it.

Why build one at all: reviewing copy at volume through a frontier API is expensive, and a general model doesn't know your standards. A small tuned model can run cheaply, locally if needed.

Four Hugging Face artifacts, all Apache-2.0: the merged weights (gr33r/ux-writing-1), the standalone LoRA adapter (-lora), a quantized GGUF build for laptops (-GGUF), and a copy of the adapter under the build-small-hackathon org it was made for. Adapting it to your own voice: 100–500 pairs, about $2–6, via a single command, documented in a fine-tuning guide.

• It starts from an off-the-shelf model — Qwen3.6-27B — and adapts it rather than training from scratch. The method (QLoRA, 4-bit) tunes a small set of added weights instead of rebuilding the model, which is why the whole thing runs on a hackathon budget.
• It learns from about 1,400 rewrite pairs — buttons, errors, labels, confirmations — plus permissively licensed real microcopy.
• Roughly 20% of those examples say "already good, change nothing." That is what teaches restraint, rather than a model that rewrites everything put in front of it.
• No string appears in both training and test. The splits were deduplicated, so the evaluation isn't scoring it on what it memorised.
• He trained it twice and kept the two runsOne complete pass of the training process, producing one version of the model. Change something about the data or the settings and you run it again, which gives you a second version to compare against the first. apart on purpose — one learned from text alone, the other from text plus screenshots — so it stays possible to say whether the screenshots helped. So far only the text-only version has been released.

• The training system prompt.
• The rubric the dataset was built against.
• The eval's ground truth.

One definition of "good," three consumers, no drift.

Two rules inside it:

• The model is explicitly permitted to return copy unchanged and say so.
• Safety-critical copy — destructive actions, payments, privacy, security — must keep its consequence and must not be softened.

• The rewrite.
• The reason for it.
• A risk rating, tagged against a fixed eight-key list: generic action, vague error, blame language, missing context, inaccessible link, high-stakes ambiguity, wordy copy, terminology drift.

The fixed taxonomy is what makes the output countable. You can ask which failure your product has most of, which a free-text explanation could never answer.

The format is also enforced during evaluation: a response that isn't valid structured data with an actual rewrite in it scores zero rather than being skipped. Malformed output is treated as a wrong answer, not a missing one.

How the author checked whether the tuned model was actually better than the one he started from — keep this as the headline measurement story:

• A test set of 90 strings, written by hand, none of which the model had seen during training.
• A blind comparison. Both models rewrote each string, and the reviewer judged the two answers without knowing which came from which. Sides were shuffled.
• The result: the tuned model won 65 of 78 comparisons where the reviewer had a preference (83%), and won every one of the nine inline-error cases.
• Malformed answers score zero. If a model returns something that isn't valid structured data with an actual rewrite in it, that case counts as a loss rather than being dropped from the count — which would have flattered whichever model failed more often.
• A stated bar for shipping: at least 60% preference across at least 30 decisive comparisons, and no regression on the safety-critical categories.

The same two models were also scored automatically, and those scores came out almost identical — 0.928 for the tuned model against 0.917 for the base, a gap too small to mean anything. It is printed on the model card.

So the automatic metric could not see a quality difference that humans picked 83% of the time. Anyone who had trusted the score alone would have concluded the fine-tune did nothing.

Measurement as a practice, not a lab moment. A June 2026 writeup adds colour around owning the fine-tuned model: running large batches of strings at a known cost, and comparing outputs in a public arena-style setting. The preference test remains the quality headline; the cost and comparison work shows why someone would keep measuring after the first win — so readers see evaluation as ongoing, not a single screenshot of 83%.

One efficiency claim alongside the quality result: the tuned model returns about half the output tokens of the base model for an answer of equivalent quality — a smaller model that is also less verbose per call. Pair that with the batch-cost notes from the later writeup if you are arguing for a fine-tune budget: quality preference and cost-per-string are different slides of the same practice.

• Hugging Face lists it under image-text-to-text, a tag inherited from the vision-capable base model. The released fine-tune was trained on text only, so the label does not describe what it does.
• English-centric.
• Scoped to short-form product UI copy, not long-form.
• A reviewer's assistant, not an authority — its author's own framing.
• It can over-specify on vague, context-free input.
• Never auto-apply. Output is explicitly for human review, especially for destructive, payment, privacy, or security copy.

• Write your test cases by hand, and keep them out of everything else.
• Judge blind. Don't let the reviewer know which system produced which answer.
• Count only the comparisons where the reviewer had a real preference.
• Decide the passing number before you look at the results.
• Don't let an automatic score be the verdict. Here it reported no real difference where human reviewers picked one 83% of the time. The closer a question gets to whether the writing is actually better, the less a score can see.interesting

Why a hook rather than a skill: a skill fires only when the model decides to load it, so anything that has to hold every time can't depend on the model choosing to check.

1. A skill that rewrites technical error strings into human language.
2. A background agent that audits existing strings across the codebase using file search.
3. A PreToolUse hook — the part that fires every time, and the reason the setup works at all.

The nine rules, all mechanical on purpose: 25 words maximum; plain language, no jargon; actionable where applicable; no exclamation marks; no banned words (please, invalid, disabled, oops); sentence case; Oxford commas.

Judgment stays with the skill and the human; only the mechanical rules go in the hook.

• It only covers edits made through the agent — author-stated. A manual edit outside that flow passes unchecked, which is what a build check is for.
• Nine mechanical rules and nothing above them. Whether a string is the right string isn't something the hook can ask.

• The nine rules are a usable starter set for any string-file hook — short, mechanical, and hard to argue with mid-edit.
• Put judgment in the skill and the human; put only mechanical rules in the hook. A hook that tries to decide whether the string is the right string will either block everything or block nothing useful.
• The honesty about coverage: a hook guards the agent’s door; a build check guards the repository’s. Neither replaces the other. If you only have one, know which door is still open.

Its argument for judging words, layout and type together: they do different parts of the same job. Spacing and position establish the hierarchy before anyone reads a word, the words carry the meaning, and type decides whether they can be read at all. Split that into separate audits and each one can pass while the screen still fails.

• UI polish — 14 rules.
• Accessibility — 9.
• Typography — 9.
• Layout — 7.
• Writing — 7.
• Plus icons, animations, surfaces, performance, and a common-mistakes list.

Everything consolidates into one prioritized verdict rather than a report per section.

• Recon before judgment — establish scope and mode before reviewing anything.
• Evidence required for every finding.
• Read-only by default — it does not change the file unless asked.
• One row per root cause, not one per occurrence, and never pad the report to fill a quota — no findings means no table.
• An anti-flattening rule, which is rare: "Preserve intentional brand character when it remains clear and appropriate to the stakes: treat a difference from generic plain language as a finding only when it creates inconsistency, ambiguity, translation risk, or an inappropriate tone."

The seven writing rules:

• One voice, flexible tone. The product has one voice, set by what already exists rather than invented during a local edit. What flexes is the tone, and it ships a table saying how warm to be at each level of risk:

  Context	Tone
  Success, onboarding, empty states	Warm, can be light
  Routine actions, settings	Neutral, minimal
  Errors, destructive confirmations	Calm, plain, zero playfulness
  Data loss, security	Serious, explicit

  It also fixes terminology to the file: "if it's 'Archive' in the menu, it isn't 'Move to storage' in the toast."
• Plain words over clever ones. No idioms or humour that won't translate; match the verb to the device — "tap" on touch, "click" with a pointer, "select" when both are possible; and never concatenate fragments around a variable, because word order changes per language.
• Verb-first buttons — "Send", "Save draft", "Delete project". Never "OK!", "Let's go!", or a bare Yes/No on a consequential action. Confirmation buttons repeat the consequence, so the dialog is answerable without reading the body: "Delete this project?" offers Delete project and Cancel.
• Links describe their destination — because screen-reader users navigate by a list of the page's links. Never "Click here," and never a bare "Learn more" when several appear on one page; suffix each one — "Learn more about exports."
• One capitalization policy per element type, applied consistently. Sentence case is the safer default.
• Errors say how to fix, next to where it broke.
• Empty states point forward.

The report is a findings table. One row per problem, with columns for severity, where it is, the before text, the after text, and why. Each row is a fix you can apply rather than a comment you have to interpret.

Around that table sit three things that make the report checkable:

• A coverage table first, listing every dimension it reviewed and what it found. If it didn't review one, it has to say why — so you can tell "nothing wrong here" from "didn't look."
• A "considered but rejected" table — things it inspected and chose not to flag, with the reason. Its instruction: these must be real candidates, "not invented filler."
• One verdict at the end: Block, Needs changes, or Approve.

On the canvas, each row from the table also appears as a small card in the margin beside the frame, colour-coded by severity, with a line pointing at what it refers to.interesting It never draws on top of the design, and re-running replaces the old notes rather than stacking new ones on them.

The most-used content guidance on the shelf is filed under design critique and written by a designer.

• Writing is one seventh of it. Seven rules against 60 KB of everything else — good rules, but not a content practice.
• No terminology source. It enforces consistency with whatever is already in the file, which cannot catch a term that is wrong everywhere.
• It sees a static design. A frame on a canvas can't show how the interface behaves, so a string can't be checked against what the product actually does.
• The skill is made of a single flat file — 60 KB of it, with no reference files to load on demand, because the platform allows nothing else.

• The tone-by-stakes table. Four rows that answer "how warm should this be?" without a debate.
• Confirmation buttons that repeat the consequence, so a dialog is answerable from the buttons alone.
• The anti-flattening rule — brand character is only a finding when it causes a named harm.
• The coverage table and the rejected-candidates table. Together they let a reader tell "nothing wrong here" from "didn't look."
• Reviewing content in the same pass as layout and type, and consolidating to one verdict.interesting

Its framing: "Treat interface copy as part of a user task, not as isolated prose."

• Review — diagnose and propose. No edits.
• Rewrite — improve existing copy inside the requested scope.
• Generate — write copy for specified screens or missing states.
• Harmonize — align terminology and patterns across a flow.

When edit intent is unclear, it defaults to Review. The safe mode is the fallback, not the enthusiastic one.

• It frames before it judges. A five-part step establishes who is reading and what they need, what the person is trying to accomplish, which moment this is (discovery, decision, waiting, error, risk, success, or return use), what action the interface actually allows next, and which terms, components, rules and states already exist. One guard on that: "Never present an invented persona or need as research."
• It reads a string in its frame, not on its own. Selected text layers are read inside their complete parent frames, with adjacent steps, related states and responsive variants inspected too.
• It writes in the language of the design. In a multi-locale file it preserves each locale and its conventions, and won't translate unless asked.
• The selection is the edit boundary. It may inspect parent frames, nearby screens, variants and comments for context, but may not edit them — and it preserves components, variants, variable bindings, Auto Layout and every visual style. Only text changes.
• It asks at most one question. Use visible evidence first, ask one concise question only when the missing context would change the result, otherwise state the assumption and carry on.

A block titled "Protect Meaning and Trust" sets four things it must not do:

• Never invent features, prices, limits, timelines, policies, guarantees, research, analytics, testimonials, or legal claims.
• Never silently alter consent, privacy, security, payment, or deletion content.
• Preserve the consequence of every action, along with product behaviour, hierarchy, and brand voice.
• Never claim a static design proves anything — not usability, not accessibility compliance, not localization quality, not implementation behaviour.

• No house style inside it. It is a method, not a style guide — it infers terminology and tone from the file, so it can't tell you your own rules.
• The skill is made of a single flat file, with no reference files to load on demand, because the platform allows nothing else.
• It sees a static design. By its own rule it can't judge how the interface behaves — which also means it can't check a string against what the code actually does.

• A stated edit boundary. Any agent operating on a live design file or codebase should have one: what it may read, and what it may change.
• Default to the read-only mode when intent is ambiguous.
• A named list of things the tool may never invent — prices, limits, policies, research. Without it, a model asked for copy whose facts it hasn't been given will supply them, and they will read as confidently as the parts that are true.
• Write down what your tool is not able to judge. This one says a design sitting still on a canvas cannot prove the interface is usable, accessible, correctly localized, or built as drawn — so it may not claim any of that. Every review tool sees one kind of evidence; naming which kind is what stops it overclaiming.

Its own scope note says what it leaves out: product terminology, and per-component writing patterns.

• Draft — produce strings that follow the rules, citing the rule by name for any non-obvious choice.
• Review — check a draft against each applicable rule. Its instruction: "Don't flag rules they didn't violate. Don't add filler considerations."
• Answer — for "what does Figma do for X?", quote the relevant rule directly.

• It matches rules to slots by layer name. It walks the selection for text nodes and records each string with its context — "Primary action button", "Title", "Description" — then applies the rules for that slot. Layer naming becomes load-bearing for content review.interesting
• It skips hidden layers rather than reviewing invisible copy.
• It is told not to sound too sure. "These are suggestions and not a replacement for real UX writing judgment… your capabilities are largely directional. Don't make a user think you are capable of the gold standard." The output is required to read as "suggestions to consider," not "rules applied" — the opposite of the confident-reviewer voice most tools adopt.
• Alternatives are offered only where wording is genuinely subjective — error messages, CTAs, loading states, headers, callout body copy. For mechanical fixes like apostrophe type, capitalization, or number formatting: "one correct answer only." That splits judgment from mechanics inside the output itself, so a reviewer isn't offered a menu for something with a single right answer.

• Bolding — bold user-generated content (names, emails, file names, domains) and bold critical information (dates, money, implied costs, roadblocks). Don't bold when several font weights already appear in the same area.
• Date and time — relative time for most UI, absolute for version history. Three-letter months with no periods, cardinal not ordinal (Aug 16, not Aug 16th), AM/PM without periods, no days of the week.
• Keyboard shortcuts — Mac uses no plus signs (⌥⌘K), Windows does (Alt+Ctrl+Del). Detect the platform; if you can't, show both with Mac first.
• Placeholder text — never put critical information there, because it disappears when typing starts. Mark optional fields in the header with "(Optional)", not in the placeholder.
• Loading states — present tense, no punctuation, not even an ellipsis, and "Do NOT be cute — loading states are not the right context for delight."
• Punctuation in tight spaces — in toasts and tooltips, prefer a comma splice to an em dash, because "em dashes are visually heavier and more distracting in tight spaces." It calls the comma splice a "hard comma." Its example: "File moved, open it in the new project" rather than "File moved — open it in the new project."
• Word choice — two lists. Preferred: co-create, together, make, big ideas, collaborate, build, flow. Avoided, each with its reason: dream (too lofty), creativity (too unspecific), playful (too ambiguous), supercharge (too marketing-speak), magical (too fantastical), artist (too poetic), utilize (too stiff).
• Be concrete — "Write lines people can picture." Its example marks "Less lorem ipsum, more true-to-life designs" as good and "Less guesswork, more accurate mocks" as too abstract.
• Localization — Japanese may be shorter but taller, German and French may run 50% longer, put "Learn more" at the end of a sentence because mid-sentence order flips in translation, and never start a sentence in a header and finish it in the options below.

[Rule name] what's wrong
  Fix: "corrected string"
  Alt: "alternative"

Chat first, canvas only on request. It lists findings in the conversation, shows violations only, and then asks whether you want them added to the canvas. It never draws uninvited.

If you say yes, it leaves each finding on the canvas as a sticky note next to the design.

• It excludes terminology by design — the row of content work most likely to cause real inconsistency.
• No per-component patterns, stated in its own scope note.
• No deterministic checker. Several of these rules are mechanical enough to lint — the date format, the shortcut separators — but a model applies all of them.
• The skill is made of a single flat file, with no reference files to load on demand, because the platform allows nothing else.

• Tell the tool how sure to sound. Writing the expected level of confidence into the instructions stops it stating a guess in the same voice it uses for a rule.
• Offer options only for judgment calls, and exactly one answer for mechanics.
• Attach a reason to every avoided word. "Supercharge — too marketing-speak" is teachable; a banned-words list isn't.
• Write punctuation rules per surface. What reads well in a paragraph is wrong in a toast or on a button, because every character competes for space there — so the rule for a notification has to be written separately from the rule for body text rather than inherited from it.interesting

But the brand skill is inert without a Salesforce org that has the feature enabled, so you can read it without being able to run it.

The returned payload carries six things: brand voice, brand tone, key messages, content rules, style guidelines, and guardrails — "hard restrictions on language, topics, or claims."

These are its four stated principles:

• "Brand first, content second — always extract brand instructions before generating content."
• "Never assume brand guidelines — only apply what was explicitly retrieved."
• "Respect guardrails absolutely — brand content rules are hard constraints, not suggestions."
• "Show your work — tell the user which guidelines you applied and how."

Two consequences of keeping the standards outside the skill: they can change without touching it, and the same skill works for any customer's brand.interesting

• You can't run it standalone. Without a Salesforce org with the feature switched on, the skill has nothing to fetch — so the half that matters, the brand payload, can't be inspected from outside.
• No deterministic checker. The guardrails are described as hard constraints, but a model is what honours them.

• Serve your standards over a tool call instead of embedding them in the skill, so the rules and the tool can change independently.
• Write "show which guidelines you applied" into the instructions as a requirement, rather than hoping the tool does it unprompted.
• Write into the instructions that the tool may not assume anything. Salesforce's version is one line: only apply what was explicitly retrieved. It closes the gap where a model fills in a brand voice from memory instead of admitting it found nothing.

1. On prompt submit — if a VOICE-AND-TONE.md exists at the project root, inject a mandatory instruction to delegate to the voice-and-tone agent.interesting
2. Before any edit or write — hard-block edits to copy paths unless a session marker exists, returning a deny decision: "BLOCKED: Cannot edit copy file without voice & tone review."
3. After the review subagent runs — create the session marker, unlocking edits.
4. On stop — delete the marker, so the next turn requires a fresh review.

There is also a dedicated no-em-dash deny hook. Two implementation details in it:

• Its search strings are built at runtime from a character code, so the hook file doesn't flag itself.
• It carries a small whitelist for upstream markers that legitimately contain em dashes.

The gate passes copy that follows every documented rule but still doesn't sound like the person whose voice it is meant to be. In their words, the agent "has no oracle for 'what Tom says' separate from the general rules."

Three phrases that passed the rules and a human rejected anyway:

• "came due" — correct, but a finance idiom.
• "narrative tide turns" — correct, but a journalism cliché.
• Stacked abstract nouns that satisfied the guide's define-on-first-use rule "mechanically but failed Tom's editorial bar for plain English."

Their own diagnosis of why: the voice principles are too abstract to check, and the banned-word list is checkable but far too short. Nothing sits in between.

The fix they propose — derive a voice reference from a body of already-published writing rather than trying to write the rules down — is what writing-eval actually implements.

One more, in common with every hook here: it only guards edits made through the agent. A hand edit outside that flow passes unchecked.

• Block the edit until a review has actually run, rather than hoping the agent remembers to load a skill. Hooks fire every time; skills fire when the model chooses.
• Separate “did a review happen” from “did the writing pass.” A hook can require the review step; a human or a later check still owns taste.
• Scope the hook to the files that carry product strings, so ordinary code edits are not taxed with content review noise.

A commercial content system: a copy library acting as the source of truth for product strings, with AI layered on for drafting, linting, and review.

Include it here because it is the clearest commercial assembly of the whole stack this report teaches — approved library, rule-citing review, pull-request bot, agent access, and (in 2026) component-level specs — in one place.

Their sales argument is worth knowing, because it is aimed at teams considering a build: generating text is now cheap and interchangeable, so the product is the approved library the generation is anchored to. They market that explicitly against building your own.

Rules: style guides authored as discrete "this, not that" rules, each with a name, description, and examples, covering terminology, tone, formatting, compliance.

The library is the centre; each surface is a different way to reach it. Teach the surfaces as one system with many doorways, not as five separate products:

• In Figma — a designer pulls approved strings into a mockup, or pushes new ones back, so the design and the library stay the same text.
• Through agent tools — a coding agent can search the approved library before writing anything new, and fetch the style rules that apply. The point is that the agent asks the library rather than inventing a string.
• In a pull request — their GitHub bot reads the changed strings, checks them against the style guide, and leaves inline comments. It also surfaces existing library text that would do the job, so a duplicate string gets caught before it merges.
• At the command line — the same checks in a script, so a build can run them.
• As a packaged agent setup — connection, standing instructions, and review skills travel together, so the copy library becomes default equipment rather than a tool someone must remember to call.

Underneath all of it, the linting checks text against every enabled rule.

And then analytics track how the enforcement itself is performing, so rules can be refined — which rules fire most, and which ones people override.interesting

Getting started from nothing: an onboarding agent scans a live codebase, extracts customer-facing strings in every language, builds a first copy and translation library, and drafts a style guide from the voice patterns in the existing copy.

Specs (the 2026 chapter worth teaching). Beside a component in the codebase, a small markdown file (they use the .ditto.md name) lists every piece of user-facing text that component shows — the title, the button label, the helper text, the tooltip — and carries the style rules that apply to those pieces. A file at the root of the project can hold rules that apply everywhere; component files add the specifics. When an agent edits that component, the right rules are already sitting next to the code, the way a stylesheet or a test file would be. You do not have to hope the agent remembers to go fetch the style guide.

Setup, in plain steps: start a project-level rules file; scaffold a file next to a component; declare each text surface and tag what kind of text it is (for example, a call to action); pull the matching rules from Ditto’s platform into that file; commit it so the whole team shares the same rules in version control. Helper skills walk a person through scaffolding, auditing real copy against the specs, and spotting patterns that should become new rules.

A single giant style guide in the repo root gives every component every rule. Agents then grab the first thing that looks relevant. Specs try to give the agent only the rules for the surfaces it is touching.interesting

That one requirement does two jobs: a writer can argue with a specific rule rather than with the tool, and a wrong suggestion points at the rule that needs fixing instead of eroding trust in everything else the tool says.

• Closed source. You can buy it and read the documentation, but you cannot inspect how any of it works.
• The value sits in the approved library, and the vendor doesn't populate it. The onboarding agent drafts a first version out of your existing code; after that somebody has to own the strings and the rules.

• Cite the triggered rule on every suggestion, so a writer argues with a rule rather than with the tool. A wrong suggestion then points at the rule that needs fixing instead of eroding trust in everything else.
• Search for an existing approved string before generating a new one. Generation is cheap; an ungoverned duplicate is expensive forever.
• Put the rules next to the component that uses them, not only in a root style guide. Agents (and humans) load what is nearby.
• Package the connection and the review habit together, so “use the library” is the default path, not a memory test.

These are architecture decisions, not features you need to buy.

A Figma-native content management tool: a copy library, localization handoff, and an AI writing assistant grounded in previously approved content.

Through 2026 it pushed harder into two loops content designers care about: reviewing and editing from Figma with a rebuilt plugin, and closing the gap when a string was born in code and never drawn on a canvas.

Figma plugins (including a rebuilt plugin that arrived in August 2026), plus a live connection that lets agents read and edit workspace copy from Claude, Cursor, ChatGPT, and Copilot.

Keeps the approved copy in one library, hands it off for localization, and writes new strings against the guidelines that apply wherever the string sits.

It also offers ways to push copy from code-built interfaces into the library, so strings that never lived in Figma can still join the same system of record.

Content guidelines attach to main design-system components. Write the empty-state rule once on the EmptyState component, and any AI operation on any instance of it anywhere automatically loads that rule. Retrieval by location instead of by search — the design system becomes the index.

That is the teaching core. Most style guides ask an agent (or a person) to search for the right chapter. Frontitude’s bet is that if you already know which component you are on, you already know which rules apply.

The open question, stated plainly: if a string was born in code and never drawn in Figma, how does it find the right component’s rules? Push-from-code is their answer to that loop. Verify it on a real repository before you tell a team the problem is solved — vendor demos and a production monorepo are different tests.

Agent access matters for the same reason Ditto’s agent surfaces matter: the library has to show up where the draft is happening, not only where the design file lives. If designers use Figma and engineers use a coding agent, both doorways need the same rules or you have two standards again.

• Closed, and described only by the vendor. None of it can be checked from outside.
• The rules are organised around Figma components. An agent can fetch them from Claude, Cursor, ChatGPT or Copilot. Push-from-code is the proposed bridge for code-only strings — treat it as a claim to validate on your repo structure, not as a solved problem.

• Treat the component as the unit of guidance — not one voice guide for the product, but a rule for the empty state and a different rule for the button. That is how retrieval stops being a scavenger hunt.
• Write new copy against copy that was already approved, not only against the rules.interesting Approved strings are a record of everything the rules never settled, and they are a corpus you already have. Different move from Ditto’s reuse check, which asks whether the string already exists — this one asks what the approved ones sound like.
• Ask early how code-born strings enter the library. If your product ships screens that were never drawn in Figma, a Figma-only index will silently miss them.

A review tool for writing that already lives in code: button labels, error messages, pull-request descriptions, README files, and other text the product ships.

It is not trying to be a blank-page writer. Its job is to read what you are about to ship, flag what is unclear, and suggest a sharper line — using one editorial standard everywhere the check runs.

Commercial. You can buy and install it. You cannot open it up and read how the review engine is built. The company says it measures and publishes how accurate the reviews are — that claim comes from them, and this card does not independently verify the numbers.

The same review engine shows up in four everyday places, so a finding means the same thing whether you are drafting or merging:

• While you talk to a coding agent (Claude Code, Cursor, and similar). The agent can call ContentRX as a tool mid-conversation, so the flag appears next to the draft instead of later in a separate review pass.
• In your code editor, as underlines and suggestions you can accept in place — the same idea as a spellcheck, but for clarity and usefulness of product writing.
• On a pull request, as an automated check. You can configure it so a merge waits until review findings are handled.
• On the command line, for a quick check of one string, a whole file, or a habit that runs before you commit.

There is also a simple website where you paste text and get a review, with no install.

It reads writing in context and returns two things: what is wrong, and a suggested rewrite.

Their own demos are easy to picture:

• A pull-request summary that says “fixed some stuff with the auth flow” becomes a summary that names the actual change and what stayed the same.
• An error that only says “Something went wrong. Try again later.” becomes a message that says what failed and what the person can do next.

ContentRX describes itself as more than “ask a model to review this.” The useful teaching point is the pipeline around the model:

1. It looks at the writing where it lives — next to the code, the pull request, or the file — so the review is not judging a sentence floating in a vacuum.
2. It applies one opinionated editorial standard across every surface. The point of that sameness is trust: if the editor and the pull-request check disagree, people stop reading both.
3. It returns a judgment you can act on — what to change, and often a rewritten line — rather than a vague score.

The architecture lesson for anyone building their own checker is simple: one brain, many doorways.interesting If your Figma plugin, your Slack bot, and your pull-request bot each invent their own rules, you have three tools and no standard.

What is still unclear from the public site is how far you can replace their opinionated standard with your own house style guide, and whether every suggestion names a specific rule the way Ditto does. Check that before you treat it as “cite the rule” infrastructure.

The surrounding code and the product writing already in the repo, plus ContentRX’s own editorial standard. Your brand voice is only in the loop if you have a supported way to plug it in — confirm that on their docs before promising it to a team.

Findings plus suggested rewrites, delivered in whatever surface you are in (chat, editor underline, pull-request comment, or terminal). The public demos show concrete before-and-after lines rather than numeric scores.

The company says accuracy is measured and published. This card does not re-run those measurements. Until you can see the method, treat it like other closed review tools: useful to try, not yet a proven yardstick.

• You cannot inspect the engine. You learn from the behaviour and the docs, not from reading the source.
• Opinionated by design. That helps a team with no written standard. It fights a team whose doctrine already disagrees with theirs.
• It reviews pieces of writing, not whole screens. A button, an error, and a title can each “pass” and still fail as one screen — the problem Coinbase’s Figma plugin writeup hits head-on.

• Run the same review standard in the draft moment and in the merge moment. If only the pull request is strict, people learn to ignore the early warning. If only the chat agent is strict, bad copy still merges.
• Separate “the check ran” from “the writing is approved.” A green build that only means “the tool finished” is how weak copy ships with confidence. If findings should block a merge, say that out loud in the setup.
• Show the sharper line, not only the complaint. Reviewers who only say “unclear” train writers to guess. A suggested rewrite teaches the standard.

Gummble is a large library of real product interfaces — screenshots, step-by-step flows, recurring patterns, and the words those products use.

In 2026 they added a way for coding and design agents to search that library live. The content-design reason to care is the microcopy search: an agent can look up how real products word an empty state or an error before it invents “Oops! Something went wrong.”

Commercial. Agent access comes with their paid plans. You sign in through a normal account login rather than pasting a secret key into a config file. The connection is read-only: the agent can search and look things up, but it cannot change your files through Gummble.

Inside agents that can call outside tools — Claude, Cursor, Codex, Windsurf, v0, and similar. You add Gummble once; after that the agent can ask it questions during a task.

It answers research questions with evidence from products that already shipped. Typical asks:

• Show me mobile paywalls that put the yearly plan first.
• Compare onboarding flows for language-learning apps.
• Find empty-state microcopy from fintech apps.

They say the library holds on the order of hundreds of thousands of screens and tens of thousands of flows. Treat the exact counts as marketing numbers; the teaching point is “searchable evidence,” not the headline figure.

Gummble’s own explanation of neighbouring tools is the clearest way to teach this:

• Gummble finds outside evidence — what other shipped products look and sound like.
• A Figma connection reads your file, components, and design system.
• Component libraries help after you know the direction, when you need something buildable.

Those jobs are easy to mix up. An agent that only knows your Figma file will remix your existing patterns. An agent that only knows the internet will sound like a moodboard. The healthy sequence is: gather evidence, then apply your system, then build.interesting

In practice, you ask the agent for a direction. The agent calls Gummble’s search tools, gets references with product context, and — if you prompt it well — has to show those references before it writes. For microcopy, that means it can study how real products handle validation, recovery, and empty states instead of falling back on training-data clichés.

Other companies’ shipped interfaces. That is the point, and also the risk. Gummble will not enforce your voice. Pair it with your style guide, your approved string library, or your own review skill — or the agent will learn taste from the market.

Search results: screens, flow steps, pattern families, and microcopy examples the agent can cite. It does not rewrite your copy by itself; it feeds the conversation that does.

None published for whether fetching microcopy references actually improves the writing an agent produces. This is a research shelf with an agent doorway, not a scored writing tool.

• Evidence from other brands. Great for pattern literacy. Dangerous if you paste it in as your voice.
• Costs money. It is not a free public corpus.
• Read-only. It will not stop a bad string from merging. It only informs the draft.

• Make “show your references” part of the writing brief. Even without Gummble, ask the agent to pull three approved empty states from your own library before it drafts a fourth.
• Keep research tools and design-system tools separate in your head. One answers “what do good products do?” The other answers “what do we already ship?” Confusing them is how generic copy lands in a branded product.
• Use outside microcopy to critique, not to clone. Steal the structure of a recovery message; rewrite it in your words.

A folder of instructions an agent can load when the task is user-facing interface text: buttons, errors, empty states, notifications, onboarding, and the rest.

It covers voice and tone, plain language, microcopy craft, and the accessibility and translation concerns that live inside the words themselves (alt text, plural forms, strings that will expand in other languages). It is one skill in a bigger pack aimed at coding agents; the pack also claims measured gains on engineering best practices. Those measurements are about the pack overall, not a public test of microcopy quality.

Public and free to read. You can install the pack for Claude Code and other agents that understand skill files, or copy the writing skill on its own. Always-on routing is optional: the agent can load the right skill from the description of the task, without you naming it every time.

In a coding agent, while someone is building or reviewing product UI. It is not a Figma plugin and not a website you paste copy into.

Two jobs, on purpose:

• Write interface copy against the bundled rules.
• Audit existing copy for clarity, consistency, tone, accessibility of language, and readiness for translation.

The skill is clear about its boundary: it owns the language. Decisions like “should this be an empty state or a blank table?” belong to neighbouring design skills in the same pack.

Under the hood it is still markdown rules — but the pack is built around a loop that matters for long agent sessions:

1. Only load the rules this task needs, so the agent is not drowning in every standard at once.
2. Bring those rules back into view across turns, because long conversations make early instructions fade.
3. Check again at the end, before the agent declares the work done.

That loop is the teaching core. A beautiful style guide that appears once at the top of a chat will lose to a messier guide that keeps getting re-applied.

The writing rules themselves are grouped into files — language system and plain language, microcopy surfaces, errors and feedback, accessibility and localization — so an audit can walk a known path instead of free-associating.

The bundled standards (including plain-language and accessibility language criteria). Not your product glossary, and not your legal word list, until you add them.

Written copy or an audit, depending on the mode. Exact field layout depends on how you invoke it; the important split is write versus audit, not a single “make this better” blob.

The parent pack publishes coverage-style results for engineering practices. There is no dedicated public test set of labelled UI microcopy attached to this skill in what we checked.

• General craft, not your voice. Same limit as Anthropic’s /ux-copy until you bind house rules.
• Lives in a large pack. Powerful if you want routing across many skills; heavier than a single short file if you only need microcopy.

• Ship write and audit as two modes of the same system, not as two unrelated prompts someone has to remember.
• Treat translation and accessibility as part of the writing rules, not as a later ticket. Plural forms, expanding text, and screen-reader names are content decisions.
• Re-check at the end of a long agent run. If your only instruction was at the beginning, assume it has drifted.

One skill in an open toolkit of dozens of UX and product-management skills. This one focuses on the short words in the interface: button labels, errors, empty states, form labels, tooltips, notifications, and confirmations.

The lineage is the teaching point. The rules are compressed from Uxcel’s learning library — material written and reviewed by practitioners for teaching — rather than invented in one afternoon as a mega-prompt.

Public, under a licence that allows reuse. You can install the whole toolkit, install selected skills, or copy a single skill file into your agent. It works in coding agents and in places that load the same skill format, including some Figma agent surfaces.

Wherever you can load an agent skill. You ask for microcopy help, or invoke the skill by name, and the agent loads those rules for the turn.

It writes or improves microcopy — and it is blunt about the failure mode of default model writing: verbose, clever, or generic (“Oops!”, “Submit”, “Are you sure?”).

Good microcopy, in its framing, is plain, specific, and quietly helpful. Tone is treated as a choice you make for the brand and the moment, not a default setting of “friendly.”

The skill does not stop at “here is a draft.” The intended path looks like this:

1. Establish voice, audience, and tone before polishing wording. Expressive tone without that gate is how jokes land in the wrong moment.
2. Apply clarity, shortness, and action — what happened, what to do, what the button does.
3. Hand the result to companion review skills instead of declaring victory:
   • a microcopy audit across the flow
   • an accessibility look at the language
   • a dark-patterns check for confirmshaming, fake urgency, and dishonest persuasion

The design pattern is generate, then refuse to call it done until a review lens has run.interesting That is the same writer/checker separation you already teach elsewhere, packaged as a skill family with a clear handoff.

Uxcel’s taught standards, plus whatever brand and audience context the skill gathers at the start. It does not automatically know your glossary.

Revised microcopy, then audit findings if the handoff runs. The audits are where consistency across a flow gets checked — not only whether one button sounds nice.

None published as a labelled microcopy test set. “Distilled from a curriculum” is a claim about where the rules came from, not a score against human reviewers.

• Curriculum is not your product. Legal terms, regulated claims, and house names still need a local layer.
• If someone skips the audit handoff, they only get the writer. The system is only as strong as the habit of finishing the loop.

• Pair every write skill with a named review skill, and make the handoff part of the workflow description — not a polite suggestion at the bottom of a README.
• Name dishonest copy patterns out loud (guilt trips on cancel buttons, fake countdown urgency). If the review skill cannot say those words, it will miss them.
• Gate tone. Decide whether this moment should be warm, neutral, or firm before you ask for “better writing.”

A translation helper built for people who keep product strings in code. You run it locally or in your build pipeline; it finds strings, translates them, writes them back out, and checks the result.

It sits next to big localization platforms in spirit, but the doorway is a developer workflow rather than a translator’s workstation. The content-design interest is whether tone and placeholders survive — not whether it can move files around.

Commercial, with a public site. They say it detects common setups such as React, Next.js, Vue, Nuxt, and standard i18n file layouts, and that you can point it at custom paths when your repo is unusual.

On a laptop terminal, or as a step when code is pushed. It is not a Figma plugin and not a chat bot for rewriting English source copy.

A full pass can scan, extract, translate, export, and validate in one go. Brand-voice profiles steer how the translation should sound. Variables like {{name}} are supposed to stay untouched.

Their own cautionary example is familiar: a casual English line about being “ready to slay” gets mistranslated into something violent, and the placeholder gets renamed. The demo output keeps the placeholder and the intended tone.

Generic translation tools often see only the isolated string. LocIn’s pitch is that it also reads the component and comments around that string, so a word like “Book” can mean a reservation in one screen and a volume in another.

Teach the failure mode first, because it is the whole reason tools like this exist:

1. A model translates the words it can see.
2. It guesses tone from the sentence alone.
3. It “helpfully” translates placeholder names or breaks ICU-style plural forms.
4. The build still goes green, because nobody checked meaning — only that a file appeared.

LocIn tries to interrupt steps 2 and 3 by adding UI context and brand-voice profiles, then validating before you ship. How deep that context reading goes is described by the vendor; this card does not re-implement it.

Source strings, nearby code context, and whatever brand-voice profile you configure. It will not invent your empty-state strategy. It tries not to wreck the strategy you already wrote.

Updated translation files and validation results in the terminal or build log.

No independent public scorecard was verified for this card. Compare carefully with platforms that publish structured quality dimensions if you need audit-ready evidence.

• Younger than the big localization suites. Less public track record than Crowdin, Lokalise, Phrase, or Lingo.
• Translation quality is not content design. Clear Spanish of a confusing English empty state is still a confusing empty state.

• Never translate a UI string without its screen context. If your process exports a spreadsheet of keys with no screenshots and no component names, you have already lost.
• Put placeholder safety in the same gate as “did it translate.” A broken {{name}} is a product bug, not a linguistic quibble.
• Keep brand voice next to the translation step, not only in an English style guide nobody sends to the model.

• One team’s story — no public repo to take apart.
• Mode names are theirs. Rename them to match how your team already argues in critique.

• Name the review modes and make people pick one before the assistant runs.
• Put brand and legal constraints inside the mode definitions, not as a hope in a giant system prompt.

• The chat “agent” was configuration — which prompt modules, which knowledge tools, which model — not a program you could drop into Figma. Mirroring it meant skills, then checks that only passed if the guidelines were actually used.
• String-by-string review can approve a broken screen.interesting Early on, the plugin graded headline, body, and buttons each on their own. Together they still disagreed. The fix was treating the frame as one experience so title, body, and actions have to answer each other.

That second point is whole-screen review (Part 3), learned on the canvas.

• Prototype, not a reference implementation.
• Quality gap vs chat remained in early feedback — closing it needed more guidance and engineering time.

• Write checks that only pass if your guidelines were actually used.
• Grade the frame, not the string list.
• Modular skills over one giant prompt when products need different terminology or legal branches.

A local helper that plugs into coding agents and gives them design knowledge on demand: usability principles, UI patterns, design-system tokens, research methods — and a content layer with voice systems and patterns for errors, empty states, notifications, and form validation.

It is broader than UX writing. It belongs here because voice and content patterns are real tools the agent can call, and because its audits try to name the rule and quote the evidence.

Public. You add it to an agent with an install command; it runs on your machine through a package runner. Claude, Cursor, and other compatible agents can call its tools during a conversation.

Beside a coding agent while someone builds or reviews an interface. It can also help audit live pages and some native app screens against design rules.

For content design specifically, three capabilities matter:

• Voice systems you can fetch — including voices modelled on GOV.UK, Shopify Polaris, Atlassian, and a conversational product voice — plus general UX-writing principles.
• Content patterns for common surfaces (errors, empty states, notifications, form validation).
• Taste and voice audits that return clear verdicts (block, warn, or pass), with a rule name and a quoted snippet of the offending text.

You describe what you want. The agent chooses among Raven’s tools — fetch a principle, fetch a pattern, run an audit, and so on — the same way it might search a codebase.

For voice work, a useful path looks like this:

1. Calibrate what “good” means for this surface (how it should look and sound).
2. Bind that profile to the project so later audits reuse it.
3. Audit and read findings that say which rule failed and which phrase triggered it.

Their examples include blocking empty hype lines like “make every screen better” or “built for modern teams,” and asking for a concrete user and task instead. Whether or not you use Raven, that finding shape is worth copying: name the rule, quote the line, suggest the fix.interesting

Default voices are borrowed from well-known design systems. They are teaching wheels. Replace them with your own voice before you treat the audit as brand enforcement.

Bundled design knowledge on your machine, plus optional project taste profiles you save locally. Not your private brand portal, unless you add it.

Tool answers in the agent conversation: explanations, pattern checklists, and audit findings with rule identifiers and quoted evidence.

Site demos and before/after examples. No public microcopy benchmark tied to the content layer was verified here.

• Design-wide, not content-only. Easy for the writing signal to get lost among tokens and layout audits.
• Starter voices are not your voice. Same trap as any preset pack.

• Every content finding should name a rule and quote the line. “Feels off” is not actionable. “Voice: no hype — quoted phrase — say what the user can do” is.
• Calibrate voice per surface (docs site vs app vs marketing) before you audit. One global “be on brand” instruction is how everything starts sounding the same.
• Keep content patterns next to design patterns in whatever toolkit you build, so errors and empty states are not second-class citizens.

There is no licence file in the repo to back that up though, which is why GitHub reports no licence at all.

At the command line that looks like cd-agency agent run error-message-architect -i "API returns 503 during checkout". You can also pipe text in from another command.

Because the fields are declared up front, another program can read the answer without anyone having to parse prose.

For example, the agents can call the voice checker tool, which uses one of four voice presets and checks if your voice aligns with the selected preset.

Below that is the part the model reads. There is a system prompt, then a section that tells the agent what to work out before it writes anything, then worked examples showing an input and the ideal answer.

For example, the error-message agent has to establish who sees the error, which interface element displays it and therefore how many characters it has, whether the user can fix it themselves, how severe it is, which platform it is on, and whether it will be translated.

• Four voice presets — Material Design, Shopify Polaris, Atlassian and Apple HIG — each with tone descriptors, do and don't rules, sample content, character limits and a terminology glossary. These are four well-known design systems, so what ships enforces Apple's or Atlassian's standards rather than yours. Pointing it at your own voice means writing a preset in the same shape.
• A knowledge folder of 52 references, and each agent names the ones it draws on. The error-message agent lists plain language, cognitive load, usability heuristics, an error taxonomy and a Slack case study, among others.
• Worked examples inside every agent file.

• The voice it enforces is not yours until you write a preset of your own.
• It never sees your product. You describe the situation to it in a sentence, so it works from your description rather than from the screen or the code.
• Nobody appears to be using it. Four stars, five forks, and no commits since March 2026.

• Make the agent ask before it assumes. The error-message agent is told that if it does not know what actually went wrong it must ask, and specifically that it may not replace one vague message with a different vague message. If the person insists on an answer anyway, it has to state its assumptions out loud first.
• Write down what the agent should work out before it writes. Who reads this, which element shows it and how many characters that allows, whether the reader can fix the problem, and whether it will be translated. That list is the difference between a reviewer and a rewriter.
• Declare the inputs and outputs as named fields. It forces you to decide what a good answer actually contains, and it means another tool can use the result.
• Have each agent name the reference material it draws on, so you can see what is behind an answer and change it.
• Give each agent a list of related agents. A tool that knows when to hand the work on is more useful than one that tries to cover everything.

It lives in the same repository as the 17 content agents, but it does not use them. Everything this step runs is ordinary code, and no model is involved at any point.

• severity_threshold — the lowest severity worth reporting, written as error, warning or info. It defaults to warning.
• fail_on_error — whether a finding at error severity should fail the check and block the merge. It defaults to true.
• target_reading_grade — the reading level to aim at, as a school grade. It defaults to 8.

The others say what to look at: which files, by matching their names against patterns like **/*.json; which rules to switch on; and what kind of content this is, so that a button gets checked against button rules rather than general ones.

When it opens a file it reads all of it, not only the lines that changed. So if you edit one button label in a file holding two hundred strings, you get findings from all two hundred, including copy that was already there and that nobody in this pull request wrote. Those findings count towards the total, which means somebody else's old string can fail your check.

There is also an optional council, where several models score the same content and their answers are combined by weighted medianA way of combining several scores into one that ignores outliers. Unlike an average, a single model scoring wildly differently from the rest can't drag the result up or down. rather than by averaging. It needs at least two models to agree before it will return anything.interesting

The pass marks sit separately in a settings file — an overall score of 75 and a readability score of 65 — and either can be overridden for a particular agent.

• What it checks is generic. Reading level and rule matches are measures anyone could apply, so it will not catch a wrong product term or a sentence that is off-voice.
• It only sees files in the repository. Copy that lives in a translation service, a content system or a design file never reaches it.
• It reads each file as one block of text. It never looks at the structure of the code, so it cannot tell that a particular string is a button label or that it sits inside an empty state. The only way to tell it what it is looking at is a single setting that applies to the whole run, so every file in a pull request gets treated as the same kind of content.
• It reports on copy you did not touch. Because it reads whole files, a small change can surface a backlog of older problems, and you have to decide whether to fix them or raise the threshold.

• Let the checker be told what kind of content it is looking at. A checker that knows it has a button in front of it can hold button rules, like a character limit and an opening verb, without becoming a separate tool. cd-agency only lets you set this once for a whole run, which is too coarse to help much, so the version worth taking is one that carries the surface along with each string.
• Separate reporting from blocking. One setting decides what gets mentioned and a different one decides what stops the merge, so a team can turn the volume up without turning the gate up.
• Score with several models and combine by weighted median when a verdict matters enough to pay for the extra calls. It stops one model having a bad run and failing somebody's build.

They exist because documentation style drifts when many engineers edit it and nobody owns the long-form content. They were built for technical writing rather than product copy, so what transfers is the mechanics rather than the rules themselves.

• docs-write — drafts and edits docs. Starts from three questions: who is this for, what do they need, and what did you struggle with when you learned it.interesting
• docs-review — checks changes against the style guide, working through a checklist grouped by tone and voice, structure and clarity, links, formatting, code examples, and sentence construction.

• Both skills pull in the same file — @./../_shared/metabase-style-guide.md — so the rules live once and neither skill carries its own copy.
• The reviewer cannot edit anything, and that is a permission rather than an instruction. Its frontmatter declares allowed-tools: Read, Grep, Bash, Glob — no Write tool. docs-write gets Write; the reviewer does not.
• It is told to hold back. "Only flag issues worth mentioning — if it won't make a material difference to the reader, skip it."

The review checklist is specific enough to argue with. A sample of what it flags:

• "Users" instead of "people" or "companies".
• Telling readers something is cool instead of showing them.
• Tasks described as "easy" or "simple".
• Linking the word "here" instead of descriptive text.
• Headings that name the topic instead of conveying the point — "Set SAML before adding users", not "SAML configuration timing".
• Instructions that explain "why" before saying what to do.

• If it is — pull-request mode. Open a pending review, collect every issue first, post all comments in one batch, then submit as COMMENT rather than REQUEST_CHANGES so the review is non-blocking.
• If not — local mode. A numbered markdown list in the conversation.

Numbering is mandatory, and the skill says why: it "allows users to efficiently reference specific issues (e.g., 'fix issues 1, 3, and 5') and track which feedback has been addressed."

Each issue carries a short title, the line number, the problem, and a suggested fix.

• Long-form content, not UI strings. No component awareness, no character limits, no per-surface rules.
• No deterministic checker. The checklist is applied by the model, not enforced by a linter.
• No terminology source. The style guide carries voice and structure rules, not a product glossary.

• Take the write tool away from your reviewer. Metabase's review skill lists the tools it is allowed to use: read, search and run. Write is not among them, so the reviewer cannot change the file even when it decides it should, where an instruction not to edit would have left that up to the model.
• Ship writer and reviewer as a pair over one shared rules file, so the thing that drafts and the thing that checks can't disagree.
• Number the findings, so a person can reply "fix 1, 3 and 5" and track what's been handled.
• Let the output adapt to the surface. One skill, a batched non-blocking PR review where that is possible and a plain numbered list where it isn't.

Alongside it there is a public library of style guides that have already been converted into those rules, so you can install a set rather than writing your own from scratch.

• The command line — vale README.md.
• A build check, where a failing check can block a merge.
• A code editor, through vale-ls, so problems get underlined as you type.
• An agent, through the third-party Vale-MCP server.

1. Write a config file naming the style packages you want. This is a complete one:

StylesPath = styles
MinAlertLevel = suggestion
Packages = Microsoft

[*]
BasedOnStyles = Vale, Microsoft

2. Run vale sync, which downloads the named packages into that folder.

3. Run vale on your files.

Take one seven-word sentence:

Click here to utilize the new dashboard!

With the Microsoft package installed, three separate rules match it:

That is the whole output — a list of places a rule matched, with the rule that matched named.

Two of those three can fix themselves; one can't. Wordiness knows "utilize" becomes "use", so it can rewrite. UIVerbs cannot blindly swap "click" for "select", because "right-click" and "double-click" are correct — so its pattern carries explicit exceptions for them and it only flags.

There are four kinds, and seeing them is the fastest way to understand what this tool can and can't do.

A swap list — "use this word, not that one." From Microsoft's terms rule:

extends: substitution
message: "Prefer '%s' over '%s'."
level: warning
action:
  name: replace
swap:
  "(?:okay|all right|alright)": OK
  "chat bots?": chatbot(s)
  "24/7": every day

Because a swap has a known right answer, this type can auto-fix — that is what action: replace declares.

Something that shouldn't appear. The whole exclamation-mark rule is one pattern:

extends: existence
message: "Use exclamation points sparingly."
level: suggestion
tokens:
  - '\w!(?:\s|$)'

A count inside a scope. The sentence-length rule counts words per sentence:

extends: occurrence
message: "Try to keep sentences short
          (< 30 words)."
scope: sentence
max: 30

A formula. The reading-level rule is plain arithmetic, not a black box:

extends: metric
message: "Try to keep the Flesch–Kincaid grade
          level (%s) below 8."
formula: |
  (0.39 * (words / sentences))
  + (11.8 * (syllables / words)) - 15.59
condition: "> 8"

Change the 8 and you have changed the standard.

Every rule also carries a link: to the human style-guide page it came from, so a flag can point at the reason it exists.

• Style guides converted into rules — Google's developer documentation style guide, the Microsoft Writing Style Guide, Red Hat's, Elastic's, and OpenShift's. None of them are maintained by the companies whose guides they encode; each carries a notice saying so.
• General writing checks — proselint (4,565 stars) and write-good (5,084) for common problems, alex (5,100) and neighbor for insensitive or exclusionary language, and a Readability pack holding the standard reading-level formulas.
• Markup support — AsciiDoc, MDX and Hugo packages, which teach it the difference between text and syntax so it doesn't try to copy-edit a code block.

• Long-form content only. No component awareness, no character limits, no per-surface rules, no notion of a screen.
• It can only check what a pattern can catch. There is no judgment here — it will flag "alright" every time and will never notice that a paragraph is in the wrong order.
• The company packages are documentation guides. Neither Google's nor Microsoft's covers button labels or error messages at the level a UI needs.

• The four rule types are a useful sorting exercise for your own guide. Go through your rules and ask which are a swap, which are a banned pattern, which are a count, and which are a formula. Anything that fits none of the four needs a human or a model — and now you know which ones.interesting
• Put a link on every rule, pointing at the page that explains it. A writer who disagrees with a flag can then read the reasoning behind the rule rather than guessing at it, and can see for themselves whether it was applied correctly.

Point it at a folder of someone's articles and it learns their sentence rhythm and word choices.interesting Point it at a new draft and it tells you how far the draft sits from that voice.

The rules. Regex detectors defined in YAML — real ones, from the bundled anti-AI overlay:

• polish_vocab — a single regex matching about 60 words: delve, leverage, seamless, robust, tapestry, paradigm shift, and more.
• throat_clearing — catches "here's the thing," "let's dive in," "at the end of the day."
• generation_artifacts — catches a literal [INSERT...] placeholder left in by mistake, a ChatGPT tracking parameter, and "as an AI language model."
• significance_markers — catches "that's the part that gets me," and ships with its own instruction for the fix: "Delete the sentence that labels the moment as significant; repeat the concrete detail instead."

34 rules ship by default; the anti-AI overlay above is opt-in and adds to them rather than replacing them.

The profile. A score for how far the draft sits from a body of writing you nominated as the target.

• Without a profile it is a linter — the rules run and each finding names the rule that fired.
• Building a profile records a fingerprint, not a copy of the text: sentence-length statistics, a repeated-opening rate, readability scores, vocabulary diversity, and the top 20 content words. Numbers describing the corpus, not the corpus itself.

  writing-eval profile build acme \
    --from posts/acme
  > built profile 'acme': 30 sources,
  >   15742 words -> data/profiles/acme

• With a profile, a draft is scored against it across four dimensions, and the report says which one is off.

Their sizing rule: "at least 25 articles and prefer 40 or more"; at 40, they report coverage reaching 87.5%.

draft.md:1:1 [warn] metadiscourse_openers:
  Remove the metadiscourse opener and state
  the point directly. | span: In this article,
draft.md:1:21 [warn] polish_vocab:
  Replace overused polish vocabulary with
  specific language. | span: delve

Underneath the findings it prints a metrics block — word count, mean sentence length, sentence-length variance, and separately, marked "informational," Flesch reading ease and grade. Those informational numbers are not part of the score; they are there to read alongside it.

With a profile — a scored report. Real numbers from their documented example:

Article score (heuristic): 86/100
Moderate alignment

Clarity and directness   25/25
Readability               23/25
Rhythm and structure      13/25
Vocabulary and style      25/25
Total                     86/100

Issues to improve:
1. Sentence rhythm differs from
   the target profile.

Four sections, 25 points each. This draft lost most of its points on rhythm and structure — the report names which dimension is off, rather than only an overall number.

The report states its own limit: "This score measures detected style patterns and alignment with the target profile. It does not measure factual accuracy or overall content quality."

• Decision gates.
• A noise floor calculation — the smallest score difference that means anything.
• A system comparison script.
• Documented thresholds.
• A study of how profile quality varies with corpus size.

Whether the findings are acceptable is left to a separate wrapper script — the tool never fails a build on its own judgment of quality.

• Built for long-form content. The readability and rhythm metrics don't transfer to a four-word button.
• It needs a corpus. 25–40 pieces of authorized writing, which a product's shipped UI copy could supply — but nobody has tried.interesting
• It scores style, not correctness. Stated in its own report: nothing here measures whether the writing is accurate or any good.

• A corpus-derived profile as a voice oracle — the thing Windy Road concluded it needed and didn't build.
• Noise-floor discipline. State the smallest score difference that means anything, so nobody reads a two-point move as progress.
• Let the checker report, and let someone else decide what fails the build. Finding problems is a successful run, not a failure — so the question of whether those findings are bad enough to block a merge stays with the team, rather than the tool's idea of acceptable becoming everyone's policy without anyone deciding it.

There is no AI inside it. It matches patterns, so the same text always gets the same answer.interesting

The author's reason for building it that way: you can tell a model "don't write like that" in the prompt and the draft still comes back with the same tells, and for a rule like "no em dash," asking a model to check is slower and less certain than testing for the character. His words: "Stop asking AI to do the checks that do not require intelligence."

Four ways in: pip install, a git clone that works as a skill with no further setup, a zip upload to Claude, or attaching the single scanner file to a chat that can run Python.

• A command in your terminal.
• A build check that can fail a pull request.
• An agent skill, with two modes — Build before drafting, which hands the writer or model the rules up front, and Review after, which scans the finished draft.
• A chat that can run Python — attach the scanner file and your draft.

It is built for long-form content, not for UI strings. Pointing it at product copy is an extension of the tool, not a documented use. What transfers cleanly to content design is the shape of its rules, described below.

• Exact words and phrases — "delve," "In conclusion," and other stock openings. A plain list.
• Sentence shapes — 26 families of them, each a recognisable move rather than a fixed phrase. "Most teams struggle with…" and "Many organisations find…" are the same move with different words.
• Whole-document habits — things no single sentence reveals: how much sentence length varies, how many em dashes per thousand words, how often ideas arrive in threes.

• The rule, in words a person can follow: no authority without an authority. Don't write "research shows" unless you say whose research.
• The patterns that catch it: "research shows," "experts agree," "studies suggest." This is the part a computer runs.
• The fix to apply: name the source, or drop the appeal and make the claim yourself.

Splitting the rule this way means a writer can read it, a script can run it, and a reviewer knows what to do about a match — without any of the three needing the other two.

Two more of the 26, to show the range:

• Cataphoric evaluation — "here's why it matters," "the key insight is." Rule: don't announce that a point is important before you have made it. Lead with the point.interesting
• Endophoric command — "let that sink in." Rule: don't tell the reader how to react to your own text.

Three things narrow what it will flag:

• Evidence nearby clears a suspicion. The "research shows" flag switches off when a real citation appears in the same claim.
• It doesn't flag you for quoting other people. Code blocks, block quotes, and quoted phrases are hidden from the scan first.
• Silencing a rule is recorded. You can tell it to skip a line, and every skip appears in the report rather than vanishing from it.interesting

All the detection sits in one file — scanner.py, about 68 KB — with two thin wrappers pointing at it: an installed slop command for the terminal and the build check, and a 12-line script for people who don't install anything, which is how the agent skill calls it. One file behind two wrappers means the agent and the build check run the same code, so they can't reach different verdicts.

Its own sample output, trimmed and re-wrapped to fit:

examples/sample-slop.md
verdict: HEAVY SLOP
density: 390.41 hits / 1k words
high: 7   medium: 5   gate: FAIL

[high] manufactured-antithesis  line 3
  "not about wording, it's about"
  fix: Name who asserted X, or delete
       the denial and state Y as a
       positive claim.

[high] phantom-population  line 3
  "Most teams"
  fix: Cite the source and number,
       narrow to observed cases, or
       delete the claim.

[medium] benefit-cascade  line 5
  "foster engagement while empowering"
  fix: Replace the benefit stack with
       the mechanism.

So "Most teams" is flagged not because those words are banned, but because it claims what a population does without naming one. The fix says so.

The file-level verdict is one of four: CLEAN, MOSTLY CLEAN, SLOP PRESENT, HEAVY SLOP. Under 120 words it reports plain counts instead of a rate, because a density figure on two sentences is noise.

The gate line is for builds. You choose the severity that should fail a pull request, and the command exits 0 for pass or 1 for fail so a build system can read the answer.

Every finding carries its repair, so the report is a worklist rather than a verdict you have to interpret.

• An example it should catch.
• A near-miss it must not catch — an innocent sentence that looks similar.
• Tests, so a later change can't break the rule unnoticed.

The catalog also logs cases a human caught and the scanner missed — including one from the project's own launch post, where a sentence passed the scan but not the author's ear.

And every scan stamps the exact rule set it ran. Two scans are only comparable if that stamp matches, so tightening a rule can't be mistaken for the writing getting worse.

Nobody has written about using it, and the author publishes no accuracy figures. It is in this report for the shape of its rules, not for traction.

• It sees surface forms, not quality. It can't tell you whether the writing is good, true, or persuasive — or who wrote it.
• A match means the pattern is present, not that the sentence is guilty. A legitimate sentence can wear the same shape, and a paraphrase can slip past — which is why every finding shows the matched text for a person to judge.
• No accuracy figures. The author claims no precision or recall, and says so plainly.
• English long-form content only.

• The three-part rule shape — the rule in words, the pattern that catches it, the fix to apply — for your own recurring culprits.interesting
• Require a near miss with every rule — an innocent sentence that looks similar and must not be flagged. It is the test for false alarms, and writing one is what makes you find the edge of the rule.

This pack's rules all answer one question: does this Japanese text read as though a model wrote it?

It also runs as an agent tool server — npx textlint --mcp — which lets an agent call it directly.

• Mechanical bold-label list formatting.
• Emoji bullets.
• Hype vocabulary.
• Redundant bold emphasis.
• English-style colon-before-block constructions.
• General redundancy, passive voice, and over-abstraction.

Note what several of those are: formatting habits, not word choices. Bold labels and emoji bullets are treated as content defects because they are how generated text looks.

A real before/after from their own documentation:

Detected (bold-label bullets, emoji bullets):
- **Important**: this is an important item
- ✅ Completed item
- 🚀 Ready to start

Rewritten as natural:
- Important item: this is an important item
- Completed item
- Ready to start

• Rules run over a parsed syntax tree rather than regex over raw characters. For Japanese that isn't a nicety — it's what makes the rules possible, since the language has no spaces between words.
• Every rule is individually configurable, with allowlists.
• The agent-tools mode turns the linter into something the writing agent calls on its own draft, so the loop becomes generate → lint → revise inside one turn instead of a check that runs afterwards.

Flagged: "革命的な技術で業界を変えます。"
  (Revolutionary technology will change
  the industry.)
Message: "'Revolutionary' is potentially
  an overstated expression. Consider
  describing the specific improvement
  instead."

textlint ships alternative formatters for other destinations — json, junit, checkstyle, github — so the same run can report into a build check.

What nobody measures is whether the rules catch what they claim to, or how often they fire on writing that was fine.

• Japanese only. The rules are language-specific and don't transfer.
• No English equivalent exists at this level of detail.
• Written for documents, not interfaces. It checks articles, READMEs and docs pages. It has no idea what a button label or an error message is, so it can't apply a length limit or a per-component rule.

• Encode the tells of machine writing as patterns — formatting and vocabulary habits — so you can catch them without paying for a model call on every paragraph.
• Keep this as a scanner, not a stylist. It flags likely machine texture; it will not invent a better empty state.
• Ship language-specific packs. English AI-tells and Japanese AI-tells are not the same list; borrow the idea of a pack, not a universal regex.

• The URL points at a raw file in a separate repository.
• It is fetched over the web before each review.
• The rules — and even the output format — live in that fetched document, not in the skill.

So the installed artifact never goes stale. Vercel edits one markdown file in another repo and every one of ~46,800 installations picks up the change on its next run, with no reinstall, no version bump, and no marketplace update.interesting

What is actually in it:

• Planning rules. Every page starts from a five-section plan, and declares a content type — Tutorial, How-to, Reference, Conceptual, Troubleshooting, or Landing. "The type drives the shape; one page does one job."
• Voice rules with tests attached. For active voice: append "by monkeys" — if "the page will be updated by monkeys" parses, rewrite it. Use "you," never "the user." Target under 20 words a sentence. Contractions encouraged.
• Banned words, with the reason. easy, simple, quick — "they sound friendly but pressure the reader." Replace with something concrete: "one command", "default settings".
• Tone per content type. A tutorial is "warm, encouraging… walking a new colleague through their first deploy." A how-to is "terse, direct. The reader is mid-task. Get them out." Troubleshooting is "empathetic but not apologetic."
• Structure rules. Sentence case for page headings, title case for nav labels. Every page opens with a one-paragraph summary. Acronyms spelled out on first use. Three or more list-shaped items in a paragraph become a list.

The tone-per-content-type table is the part with no equivalent in any content-design tool here: five named document types, each with its own voice.

## content/docs/sandbox.mdx

sandbox.mdx:1   missing meta.contentType
sandbox.mdx:24  passive voice
                ("the sandbox is created…")
sandbox.mdx:31  banned word "easy"
sandbox.mdx:47  "..." → "…"
sandbox.mdx:102 H2 "Caveats" too generic
sandbox.mdx:118 em dash in prose, replace
                with colon/comma

No prose, no severity levels, no summary. A list you work down.

The format itself is defined in the fetched document, not in the skill — so Vercel can change how every installation reports findings by editing one remote file.

• Long-form documentation, not UI strings. No component awareness, no character limits, no per-surface rules.
• No deterministic checker. A model applies the handbook, so two runs over the same page can differ.
• The fetch-fresh trade has a cost. Useless offline, breaks if the URL moves, and no way to pin a version — a rule change lands on every user immediately whether they wanted it or not.

• Fetch the rules from a URL on every run, so the skill cannot drift away from the living style guide. A copied markdown file in the skill folder will rot the week after someone edits the real guide.
• Treat the skill as a reviewer of long-form, not of UI strings. Borrow the “always load the current guide” move; do not pretend the same checklist covers button labels and empty states.
• Make the source of truth obvious in the skill text — name the URL, say what happens if it fails to load, and refuse to invent house style from memory.

• As rules a program runs. Each rule is a small file saying what to look for and what to say about it, so a script can check a document and report where it breaks the guide.
• As the guide itself, in plain markdown at a URL, so anything can fetch and read the whole thing in one request.

• In the build, on every merge request.
• At the command line.
• In a code editor — VS Code, Neovim, or anything else that speaks the Language Server Protocol, through vale-ls. Violations appear as you type, the way a spelling mistake gets underlined.

What those rules actually catch, by what they are named:

• Sentences that are too long or too hard — SentenceLength, ReadingLevel, Wordy, Simplicity.
• Sentences a reader can misparse — UnclearAntecedent catches an "it" or "this" whose subject is ambiguous. MeaningfulLinkWords catches link text like "here" that says nothing out of context.
• House conventions — OxfordComma, FutureTense, LatinTerms (no "e.g." or "i.e."), BadPlurals, InclusiveLanguage.
• Plus word-swap lists and a spelling-exceptions file.

Separately, the guide is fetchable as markdown. Append /index.md to the docs URL and you get 94 KB of text/markdown — the whole current style guide in one request.

• The rules live in the repo under doc/.vale/gitlab_base/, driven by a root .vale.ini: MinAlertLevel = suggestion, applied to all markdown, with per-path overrides for API fragments and release notes.
• Their agent instructions name which model should write. Rather than the main agent drafting human-facing long-form content itself, it hands that work to a smaller, less capable model, briefs it with the facts and constraints, then checks the output for accuracy. Their stated reason: "high-capability models tend to produce dense, jargon-heavy prose."
• A style decision, not a cost-saving one. They picked a weaker model because it writes more plainly.interesting

What nobody measures is whether these are the right 53 rules, or whether the smaller-model instruction actually produces plainer prose.

• Scope: the Vale rules govern documentation, not UI strings.

• Publish your style guide at a URL that returns markdown, not only HTML. GitLab's docs hand back the whole guide as plain text if you add /index.md to the address, so an agent fetches it in one request instead of picking its way through a web page.
• Push pattern matching further into prose than it looks like it can go. A pattern can check things that sound like judgment calls: wordiness, reading level, sentence length, and sentences where it isn't clear what a word like "it" refers to.