Prose linters

A prose linter applies the linter idea to writing. Most rules are word and pattern lists, not grammar: flag “utilize” and suggest “use”, flag “obviously”, flag passive voice or a heading in the wrong case. Vale, an open-source one run by teams at AWS, Microsoft, GitLab and Red Hat, parses Markdown, AsciiDoc, reStructuredText and HTML first, so a rule can target headings or table cells and skip code blocks and URLs; it also lints comments and docstrings inside source files and the prose in commit messages or OpenAPI descriptions. Its rules are YAML files grouped into styles, so a team can publish its house style (Microsoft’s and Google’s guides exist as packages) and fail CI on it like any other check.

Three families of checks recur. Style and terminology rules enforce a guide. Inclusive-language rules, as in alex, flag gendered, ableist or condescending wording and suggest alternatives. Readability formulas such as Flesch-Kincaid, Gunning Fog and SMOG turn sentence and word length into a school grade level; Vale has a readability check, and Readable.com sells those scores and many more through a web API.

A newer target is the register of LLM-written text: puffery (“thrilled to announce”), inflated words (“leveraging”, “robust”), hedges and “In conclusion” endings. Vale’s Voices package (2026) turns the instructions people put in prompts into rules, so a coding agent can be made to rewrite a draft until it passes. The “slop” label is also used for checkers that read code, such as antislop’s hedging-comment and stub rules or the anti-slop Oxlint rules; those belong with linters. All prose linters share the limits of pattern matching: they catch phrasing, not whether the text is right, and large word lists bring false positives that teams tune with exceptions and inline disable comments.