ESLint for content: make editorial rules loadable
Make editorial standards machine-readable without pretending every prose judgment is a lint error. See where rules stop and review memory starts.
A technical-writing team can have a style guide, docs templates, review comments, and engineers who are trying to help. Then AI-generated API docs, READMEs, and wiki pages start arriving from everywhere. In one technical-writing discussion, the team was two people supporting more than 50 engineers, and the drafts were useful but inconsistent in tone, structure, depth, and usefulness.
That team doesn’t need a lecture about quality. The rule already exists. The problem is that the next draft doesn’t load it.
ESLint for content means known editorial standards become machine-readable rules and review artifacts that future drafts, reviewers, agents, or checks can load. It doesn’t mean every prose judgment becomes an automated lint error.
The useful split is simple: known checks consume known rules. Review creates the next rule.
Start with known checks
Software teams already know the first half of this move. ESLint rules and configuration let teams move JavaScript expectations into rules, options, plugins, and config files that a workflow can run repeatedly.
Content teams have rule-shaped standards, too. Product-name capitalization can be a rule. Required frontmatter can be a rule. Banned phrases, citation fields, link policy, heading order, and stale CTA language can all become checks when the standard is already known.
That layer is not imaginary. Vale’s prose-linting documentation describes a command-line tool for code-like linting of prose with custom rules and styles. markdownlint’s static-analysis rules cover Markdown and CommonMark structure. Write the Docs’ docs-as-code guide describes documentation work that uses issue trackers, Git, plain-text markup, code reviews, and automated tests. GitHub Actions workflow docs show how repository workflows can run jobs on events, schedules, or manual triggers.
Use those tools where they fit. They keep known standards out of one person’s memory.
But a workflow runner doesn’t supply editorial judgment. A Markdown linter can catch a skipped heading level. It can’t decide whether a comparison is fair, whether a source supports a claim, whether a risk caveat is required, or whether a CTA has been earned.
Review creates the next rule
New editorial judgment is not born as a deterministic check.
When a reviewer rejects a claim, they are often making several decisions at once. The source may not support the sentence. The product promise may be too broad. The phrasing may violate a claims policy. The comparison may be directionally true but unfair at the level of detail in the draft.
If that decision dies in a comment, the next draft starts cold.
The smallest useful artifact is more specific than a comment:
- content version
- block location
- finding
- source or provenance context
- decision
- rationale
- rule candidate
- rulepack or schema-versioned export path
Now the workflow has something to load. The next reviewer can see why the claim was rejected. A future agent can inspect the rule candidate before drafting. A rulepack or export can carry the decision without pretending the original human judgment was a syntax error.
That is the part “ESLint for content” usually misses. The rule file matters, but the reason behind the rule matters more.
A rule file is not the operating state
AI workflow builders run into this in a different stack. Standards live in CLAUDE.md, hooks, memory, prompt files, style docs, and context windows. Later work can still behave like the last decision never happened.
Content teams see the same pattern with different artifacts. The style guide is in one place, the draft is in another, approval happens in a thread, and the next draft treats the last review as folklore.
Machine-readable cannot only mean “written down somewhere.” A style guide documents intent. A structured review record carries operating state: what was found, what was decided, why it was decided, where it applies, and whether it should become a rule.
That distinction keeps the analogy honest. Known rules can be checked directly. New judgment needs a finding and a decision before it becomes rule material.
What a review decision can become
Imagine a docs draft says an API parameter is optional because an older example omitted it. A reviewer checks the current source truth and rejects the sentence.
The reusable record is not “fix this.” It is the exact claim block, the source context, the finding, the decision, and the rationale. If the issue repeats, the rule candidate might be simple: API capability claims must match the current source-of-truth file before publication.
That is not automatic quality. It is a reusable editorial decision.
Once a decision has durable form, it can become context for the next human reviewer, an external agent, a rulepack, or a schema-versioned export. The workflow is no longer guessing which comments mattered and which rules are active.
Where Typescape fits
Typescape should not replace ESLint, Vale, markdownlint, GitHub Actions, docs-as-code, editors, or human judgment. Those tools and people already do useful work.
Typescape fits at the review-record layer. A review anchors the draft version. A finding marks the issue on a specific block. A decision records what happened and why. A repeated or important decision can become a rule, join a rulepack, or move through a schema-versioned JSON export that another workflow can consume.
The review remains human-owned or external-agent-owned. The artifact becomes loadable.
That is why this page is narrower than Content QA-as-Code and less technical than rules to rulepacks. The broader framework matters, and the rule lifecycle matters, but the first distinction is smaller: deterministic checks handle known standards; structured review memory preserves new judgment. If anchoring or comment shape is the harder problem, start with block-level anchoring, structured feedback instead of loose comments, or content approval versus content review.
When a review decision needs to outlive the current draft, start with one structured review in Typescape Free. The Free tier includes 15 review sessions a month with no credit card required.