StyleOps

Documentation optimization and drafting for developers, technical writers, and AI-powered workflows.

Pricing Order StyleOps Customer agreement

Overview

A clear standard for every developer doc

Review existing documentation and draft new compliant guides and API reference docs from code, specs, and notes. StyleOps verifies compliance with built-in or custom documentation standards and returns findings with rule citations, explanations, and suggested fixes. Your technical writers and engineers decide what to publish.

Each release ships the guide as flat Markdown for AI chat, JSON rules and a word list for your tooling, document templates, a Vale configuration for the mechanical checks, and a Claude Code plugin. It runs on your own systems: model calls go directly to Anthropic on your own API key, nothing is hosted, and your documents never reach Developer Experience. StyleOps is licensed per organization for a flat annual fee.

What's included

Review, draft, gate, and customize

Everything in a StyleOps release, in the order a team meets it. The style guide gets its own section further down the page.

Two commands

Install

Two commands add the plugin to Claude Code: terminal, IDE extensions, and the desktop app. For build systems, pip installs the same tools, pinned by tag.
Your systems

Run it on your own key

Runs on your systems. Model calls go directly to Anthropic on your own API key, with no resale, markup, or meter. Claude Opus by default, with a deep-review option.
Optimize

Review what you have

A Vale pattern pass, a model review, and an independent verification pass. Every finding cites a rule ID, severity, fix, and rationale. Nothing is rewritten or dropped silently.
Generate

Draft what's missing

Drafts a developer guide, API reference, or quickstart from code, specs, and notes. Unsupported claims are marked [?]. Each draft ships with a compliance report and a navigation entry for Starlight, Docusaurus, MkDocs, or Mintlify.
Build pipeline

Gate pull requests

The same command runs unattended in any build system that acts on an exit code. Gate on severity or unchecked terms, with inline GitHub pull-request annotations. Every report names the guide, inputs, model, and prompt versions.
Customize

Add your own rules

Project style, product vocabulary, your templates, and a custom guide live in one directory in your repository. Project style wins over the guide, and updates never touch the directory.
Updates and license

Stay current

One tagged release at a time, with a changelog. One flat annual price per organization, unlimited repositories, every update included. You keep the last release if you don't renew.

Cleaner drafts

Significantly fewer style guide violations than the same model drafting without StyleOps, on identical inputs.

[?]

On every drafted claim the inputs don't support. Plain model drafts stated each one as fact.

Checks per review: a pattern pass, a model review, and a verification pass.

Docs platforms with navigation converters: Starlight, Docusaurus, MkDocs, and Mintlify.

Use cases and results

Content comparison

The following example compares the opening of the same topic, RDK S100: Set up third-party drivers, as produced by multiple sources. The excerpts show how documentation quality compares when it is written by an engineer, standard AI, StyleOps, and StyleOps with a technical writer.

Ideally, StyleOps can review or create your initial documentation drafts, a technical writer should develop the final content, and a subject matter expert should check it for accuracy. By using this type of workflow, StyleOps allows your documentation lifecycle to keep up with AI development workflows, while ensuring that humans verify all content before publishing.

Engineer draft

An engineer writes it

The engineer who did the work writes it up from memory for the next engineer. Every fact is right, and almost none of it reaches a reader who wasn't there.

wiki.example.com/robotics/S100P_OOT_Module_Procedure

Robotics eng wiki

S100P OOT Module Build/Sign Procedure (mt7921au, PCAN etc)

So the DR kernel (6.1.112-rt43-DR-4.0.4 as of 4/3) is built w/ CONFIG_MODULE_SIG_FORCE=y which means insmod/modprobe will EKEYREJECTED any .ko that isn't signed w/ the certs/module_signature.pem keypair from the headers pkg, i.e. the kernel is basically a bouncer checking IDs at the door & the apt repo doesn't carry mt76/mt7921 or the peak-linux stuff anyway (jammy ports modules target 5.15 so don't bother). Long story short you have to roll your own: make prepare in the headers dir, build the vendor tree (gen4m for the Panda, see below), then modules_install does sign+install+depmod in one shot. The GCC mismatch warning (11.4.0 vs 11.3.1) is a red herring, IGNORE IT.

NB if apt upgrade pulls a new kernel your modules are toast until you rebuild (learned this the hard way when 4.0.3 to 4.0.4 landed mid-session) so apt-mark hold the headers+image or you WILL get bitten. Rebuild script attached above, ping me on Slack if it blows up.

$ sudo make -C /lib/modules/$(uname -r)/build prepare
$ make -f Makefile.x86 MTK_COMBO_CHIP=MT7961 hif=usb
$ sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install # signs+depmod

Problems in this excerpt

Complex and internal jargon

OOT, EKEYREJECTED, DR kernel, gen4m, and the keypair path arrive undefined, and w/ and NB stand in for words.
Metaphors

A bouncer checking IDs, modules that are toast, a red herring, and a script that blows up, none of which translate or search well.
Opens with details

The first sentence is a kernel configuration flag. Nothing says what a third-party driver is, or that the goal is to make a device work.
Not scannable

One heading, two dense paragraphs, commands buried mid-sentence, and pointers such as see below and attached above that assume the whole page is read in order.
No globalization or accessibility standards

A slash date, ampersands, i.e., capitals for emphasis, directional references, and an idiom in every other sentence.

AI draft without StyleOps

AI writes it without StyleOps

The same notes, handed to a model with no style guide. The result is fluent and confident, and it carries the habits of everything the model was trained on, including claims nobody made.

docs.example.com/guides/unlocking-third-party-drivers

Docs

Guides Unlocking Third-Party Driver Support

Unlocking Third-Party Driver Support on the RDK S100P: A Complete Guide

Welcome! In this comprehensive guide, we'll walk you through everything you need to know about building, signing, and installing out-of-tree kernel modules on the D-Robotics RDK S100P — from prerequisites to production-ready deployment. Whether you're integrating a USB Wi-Fi adapter, a CAN bus controller, or a custom sensor, this guide has you covered.

🚀 Why This Matters

The RDK S100P ships with a curated, battle-tested kernel — but no kernel can include every driver under the sun. Out-of-tree modules bridge that gap seamlessly, robustly, and securely, giving you the flexibility of a stock Ubuntu system with the reliability of an embedded platform. Best of all, the entire process takes under five minutes and works on every RDK kernel version — past and future.

📋 Step 1: Prerequisites

N.B. you'll need root access. Simply run the following → the built-in auto-sign flag handles the rest:

bash

sudo apt install -y build-essential flex bison
sudo rdk-driver-tool --auto-sign --target=all   # ✅ signs & installs in one go

On this page

Problems in this excerpt

Non-standardized documentation structure

A Title Case heading with a subtitle after a colon, a Why This Matters section, numbered Step headings, and an emoji in front of each one.
Machine language

Welcome, in this comprehensive guide, everything you need to know, this guide has you covered, and best of all.
Previously trained jargon

Battle-tested, production-ready, bridge that gap, and seamlessly, robustly, and securely.
Fictitious claims and overconfidence

Under five minutes, every kernel version past and future, and a signing flag on a tool that doesn't exist.
Symbols from other industries

N.B. from academic writing, an arrow for then, emoji as bullets, and a check mark in a code comment.
Overuse of parallel structures

Whether you're X, Y, or Z; the flexibility of one with the reliability of the other; three adverbs in a row.
Em dashes everywhere

Three on the first screen, each splicing two thoughts the guide would set as separate sentences.
Few globalization or accessibility standards

Every driver under the sun, simply run, and emoji that screen readers announce by name.

StyleOps draft

StyleOps drafts it

The same notes and the rebuild script, through Generate with the developer guide template. The draft follows the guide, keeps to what the inputs support, and flags what it couldn't verify for a person to check.

localhost:4321/robot-build/rdk-s100-drivers/

Developer Experience Docs

Robot build Set up Set up third-party drivers

Set up third-party drivers on the RDK S100

Set up a driver that the RDK S100 doesn't include, such as a USB Wi-Fi adapter or a CAN bus controller, by building it from source, signing it, and installing it as an out-of-tree kernel module. This guide is for developers who are comfortable running commands in a terminal on the board.

Before you begin

Access to the RDK S100 as a user with sudo privileges.
The driver's source code from the vendor or a repository. The source must target Linux kernel 6.1 [?].
The kernel headers package, linux-headers-6.1.112-rt43 [?], installed on the board.

How driver setup works

The S100 kernel loads only signed modules. The kernel's modules_install target signs the module, copies it to the module directory, and registers it, in one step [?]. A kernel update invalidates every module you built, so this guide also pins the kernel.

rdk-s100-drivers.compliance.json

"sections": { "written": 7, "dropped": 0, "added": 0 },
"unverified_claims": 3,
"rules_applied": ["head-005", "list-003", "proc-005", "punct-028", "word-001"],
"guide": "dx-style-guide", "model": "claude-opus-5", "prompt": "generate_doc_v1"

On this page

What changed

A draft, not a finished page

Three claims carry a [?] marker and wait for a person, and the compliance report beside the draft counts them.
Better than either previous draft

Leads with the outcome and the audience, with no filler, no metaphors, and sentence-case task headings.
Less drift

The sections follow the template. Nothing is invented, and the tone doesn't change from one paragraph to the next.
Traceable claims and references

The kernel version, the headers package name, and the modules_install behavior are marked because the notes didn't state them. The report records the rules applied and the model used.
Enforced standards and terminology

Driver in prose and module for the file, no em dashes, consistent list punctuation, and a prerequisite list that says what is required and nothing else.
Standardized structure

Before you begin, how it works, one task per section, and a verification section, in the order a reader needs them.

StyleOps with a technical writer

A technical writer finishes it

The writer starts from the StyleOps draft and the report instead of a blank page, resolves the marked claims on the board, and spends the review on the reader's path rather than on punctuation. This is the published topic.

docs.developerexperience.com/robot-build/rdk-s100-drivers/

Developer Experience Docs

Robot build Set up Set up third-party drivers

RDK S100: Set up third-party drivers

The D-Robotics RDK S100 includes drivers for a limited set of devices. This guide covers how to set up drivers that aren't included (out-of-tree kernel modules), including building, signing, installing, and automating the process with a script. For example, our initial setup used a USB Wi-Fi adapter that is Linux compatible but not recognized, because the system didn't include a driver for it.

Background

The RDK S100 comes with Ubuntu preinstalled, but it runs on a custom Linux kernel (6.1.112-rt43) that includes a limited set of prebuilt drivers, also referred to as kernel modules. Devices that use an included driver are plug-and-play. For other devices, you set up the driver as an out-of-tree kernel module.

Prerequisites

Before you begin, run the following commands on the S100 to install the build dependencies and verify that the kernel headers are installed:

Terminal

sudo apt install -y build-essential flex bison
ls /lib/modules/$(uname -r)/build/Makefile

On this page

Read the published topic in the docs

What the writer added

Highest and fastest style guide compliance

The draft arrived compliant, so the review went to the marked claims and the structure. The final pass through Optimize reported no findings at the must level.
Human verification

Each [?] was checked on the board. The kernel version and the headers package were confirmed, and the modules_install claim was rewritten from the kernel documentation.
Fewer human mistakes

The pattern checks and the verification pass catch what a writer skims past: a stray would, a Title Case heading, or a term that isn't in the word list.
Highest quality documentation

A concrete example in the introduction, a background section for readers who don't know what a kernel module is, troubleshooting inline where it applies, and one term per concept throughout.

Documentation standards

The Developer Experience style guide

StyleOps enforces the Developer Experience style guide, a style guide for developer documentation written by technical writers for an age of machine drafting. StyleOps includes a style guide schema and a version of the guide that is optimized for LLM processing and for your own custom tooling.

The style guide

Sections

Introduction, audience (including the AI-language rules), grammar, punctuation, text formatting, organization and navigation, multimedia, code, trust and accuracy, API reference documentation, and terms.
Severity per rule

Must, should, or may. The severity in the guide overrides the model's judgment in every finding.

must, should, may
Content surface per rule

Main, API, marketing, or blog, so a review applies only the rules that fit the page type.

4 surfaces
Precedence chain

Your project style first, then the guide, then Chicago and Merriam-Webster for open points.
Standard English is not a violation

The guide flags style decisions, not ordinary English, so every finding is one a writer would act on.
Online reference

The full guide is published on the docs site, free to read and searchable, and every finding links to its rule there.

Formats for models and tools

JSON format

The source format for the style guide, for efficient LLM and tool processing.

JSON
Compact Markdown

A flattened version of the style guide for lighter workloads in AI chat.

Markdown
Stable rule IDs

Rules are assigned numbered stable IDs for easy tracking and processing. An ID is never reused, so a citation stays valid across releases.
Model and Vale

Rules that resist a pattern are judged by the language model. Mechanical rules run in Vale.
Character-set safety

UTF-8 end to end. Chinese, Japanese, and Korean text is preserved and never translated.

UTF-8
Release cadence

The guide is updated on a release cadence, and every update is included in the license.

Read the style guide online

Custom style guides and templates

Run your own guide through the same toolchain

The supplied style guide schema and tooling let you create and use custom style guides and documentation templates with StyleOps. After you add a schema-compliant style guide, you use the provided tooling to generate the additional style guide formats and Vale configuration that StyleOps requires.

A custom guide replaces the shipped guide for a run, and a project style file layers your standing rules on top of either one. Updates to StyleOps never touch your directory.

Your rules

Write your guide in the schema shape

A manifest with your own guide ID and version, a rule index, a term list, and a taxonomy. Give rules IDs with your own prefix so a citation is never mistaken for one of ours.
Provided tooling

Generate the derived formats

One command renders the formats StyleOps reads from your core files, and another validates the directory against the schema and warns about stale files.
Your document types

Add your templates

A template is a Markdown file whose headings are the sections and whose body text is the authoring instruction. Copy a shipped template and edit it, or write one for any document type.
One flag

Point every surface at your directory

Keep the guide, the templates, your project style, and your vocabulary in one directory at the root of your documentation repository. One flag reads it, the Claude Code commands find it, and every run names the guide in force.

Data transmission

Your documents go to Anthropic, and nowhere else

StyleOps runs on your own systems. When it calls a language model, your documentation content goes directly from your systems to Anthropic, using your own API key and your own agreement with Anthropic. It never passes through Developer Experience or any other third party on the way to Anthropic, and we don't resell or mark up your Anthropic API calls.

Get StyleOps

License StyleOps for your organization

One flat annual price, and every update included. Read the pricing and the customer agreement, then request an order.

Pricing Order StyleOps Customer agreement

StyleOps

A clear standard for every developer doc

Review, draft, gate, and customize

Install

Run it on your own key

Review what you have

Draft what's missing

Gate pull requests

Add your own rules

Stay current

Content comparison

An engineer writes it

S100P OOT Module Build/Sign Procedure (mt7921au, PCAN etc)

AI writes it without StyleOps

Unlocking Third-Party Driver Support on the RDK S100P: A Complete Guide

StyleOps drafts it

Set up third-party drivers on the RDK S100

A technical writer finishes it

RDK S100: Set up third-party drivers

The Developer Experience style guide

Run your own guide through the same toolchain

Write your guide in the schema shape

Generate the derived formats

Add your templates

Point every surface at your directory

Your documents go to Anthropic, and nowhere else

License StyleOps for your organization