# textlint-rule-preset-ai-writing: linting Japanese prose for the shape AI gives it

> A textlint preset that flags bold-and-emoji list items, hype phrasing and colon-then-block structures in Japanese writing, built on the argument that structure is what gives machine prose away.

**textlint-ja/textlint-rule-preset-ai-writing** — A textlint preset: a rule set that detects AI-sounding writing patterns and encourages more natural Japanese expression.

- Repository: https://github.com/textlint-ja/textlint-rule-preset-ai-writing
- Website: https://textlint-ja.github.io/textlint-rule-preset-ai-writing/
- Stars: 1,154 · Forks: 23
- Language: TypeScript
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/textlint-ja-textlint-rule-preset-ai-writing

## The premise: constrain structure, not vocabulary

The README states the design principle before it lists anything else, and it is the part worth agreeing or disagreeing with. Rather than restricting expression, the preset aims to constrain structure so that more natural expression becomes possible. That is a deliberate choice, and it is the reason the rules look the way they do.

A word blacklist cannot work well on Japanese, where a single word carries a lot of meaning and where the same term can be natural in one register and inflated in another. Structural patterns are more mechanical: a list item that starts with bold text and ends with a colon, an emoji as a list bullet, a sentence ending in a verb immediately followed by a code block. Those have shapes you can match.

The package is MIT licensed, TypeScript, with `src/` for the rules, `test/` for the suite and an `example/` directory holding a working `.textlintrc.json`. Latest release is v1.7.0 from 2026-05-13, and the last push was 2026-06-16, so the code on main is ahead of the published package by about a month.

What the preset does not do is decide whether a text was written by AI. It has no authorship detection and no model. It flags shapes that correlate with generated prose, which is a linting judgement about style rather than a claim about origin.

## Installing it and turning it on

The install is one npm command, and the README lists it as an indented block rather than a fenced one:

```
npm install @textlint-ja/textlint-rule-preset-ai-writing
```

Activation goes in `.textlintrc`, and the README recommends this route:

```json
{
    "rules": {
        "@textlint-ja/preset-ai-writing": true
    }
}
```

There is a naming wrinkle here that will cost you an afternoon if you hit it cold. The package you install from npm is `@textlint-ja/textlint-rule-preset-ai-writing`, matching the repository name. The key you put in the config is `@textlint-ja/preset-ai-writing`, without `textlint-rule`. The two forms appear in the same README, and the config example is what the project ships in its own `example/.textlintrc.json`, so the shorter key is the working one even though it does not match the package name.

The preset also runs as an MCP server, which is the reason it exists in this shape. The README describes a feedback loop where an AI tool writes text, the textlint MCP server checks it, and the tool revises based on the findings:

```bash
npx textlint --mcp
```

That is the intended integration for Claude Code and VS Code Copilot, and the README is candid that the rule set was designed around this loop rather than around a human reading a terminal report.

## Four pattern rules and one suggestion rule

The preset ships five rules, and they split cleanly into four that report errors and one that reports suggestions.

`no-ai-list-formatting` catches list items that read as mechanically generated: bold leading labels followed by a colon, hyphen-separated labels, and emoji bullets. Each of those has its own kill switch, `disableBoldListItems` and `disableEmojiListItems`, plus an `allows` option taking either a literal string or a regex. `no-ai-hype-expressions` targets inflated claims, and the README's own before-and-after pairs make the intended standard concrete: claims of world-first, complete solutions and ultimate performance get replaced with claims of effectiveness, new solutions and high performance. Its three switches are `disableAbsolutenessPatterns`, `disableAbstractPatterns` and `disabledPredictivePatterns`, and the last of those has an inconsistent name, missing the `disable` prefix its siblings share.

`no-ai-emphasis-patterns` catches bold inside sentences, bold after a note prefix, and bold inside headings. `no-ai-colon-continuation` is the most interesting of the four, because it is the only one that does real analysis rather than pattern matching. It uses morphological analysis through a library called kuromojin to decide whether the text before a colon ended in a predicate, so a heading that ends in a noun is left alone and only a sentence ending in a verb or auxiliary is flagged.

The fifth rule, `ai-tech-writing-guideline`, works differently. It reads technical writing guidelines from `docs/tech-writing-guidelines.md` and offers suggestions on conciseness, active voice, specificity, terminology consistency and sentence structure. Because it advises rather than errors, its `severity` option can be set to `"info"` to treat its output as suggestions.

## The versioning policy is unusual and worth reading before you upgrade

Most packages version on API shape. This one versions on what changes for you as a user, and the README spells out all three cases.

A patch release is for rule fixes: better error messages, improved detection accuracy on existing rules, and bug fixes. A minor release is for new rules and new options. A major release is for removing existing rules or making breaking changes. So adding a rule can never break your build, while removing one will.

The consequence follows directly. The README notes that a patch release can increase the number of errors, because a detection fix can surface cases that were previously missed, and it counts those as patch. It then recommends pinning your lockfile, naming `package-lock.json` and `yarn.lock` specifically. If you adopt this preset in CI, that advice is not optional.

The versioning convention is also self-documenting for review: when a pull request changes error counts, the expected release type is already determined by which category the change falls into.

## Where it sits against Vale, prose-lint and a human editor

The comparison that matters is not with other AI detectors, because this is not one. It is with general prose linters.

Vale is the closest in ambition: a markup-agnostic prose linter with a rule ecosystem, so you write your own rules and it applies them. That is more work up front and more ceiling later. This preset gives you a specific, opinionated rule set about one thing, Japanese prose shaped like generated text, and no way to add your own rules beyond the per-rule `allows` exceptions and switches.

Against a human editor, the honest framing is that it is a first pass, not a replacement. It catches the mechanical tells reliably because they are mechanical. It cannot tell you whether a sentence is unclear or whether an argument holds. And because the preset's own principles are about encouraging more natural expression rather than forbidding words, treating its output as authoritative will make prose worse if you let it.

The recommended combination is instructive: the README recommends running this alongside `textlint-rule-preset-ja-technical-writing`, with the guideline rule downgraded to info. Fix certain problems with the technical-writing preset, then take improvement suggestions from this one. That ordering, certain problems first and suggestions second, is a reasonable template for any team adding a linter like this.

Two limits to name. This is Japanese only, and there is no English equivalent shipped here. And the README's requirement section gives two different textlint versions: 15.1.0 as the stated floor, and 14.8.0 as the version from which MCP server use is available.

## Conclusion

This preset is a good fit if you publish Japanese documentation or articles through a git repository and want a mechanical check for the structural habits language models bring with them. It is a poor fit if you are writing English, if you want it to detect authorship, or if you need it to be quiet: the README itself warns that a patch release can raise the error count, so budget for that churn rather than treating a new warning as a regression. Two facts to settle before you wire it into CI. The README names both textlint 15.1.0 as the floor and textlint 14.8.0 as the version where MCP support arrived, and it configures the preset under the key `@textlint-ja/preset-ai-writing` while the npm package installs as `@textlint-ja/textlint-rule-preset-ai-writing`. The last push was 2026-06-16 with v1.7.0 released 2026-05-13. Start with the four-line `.textlintrc.json` and one real file before adding the severity suggestion rule.

## FAQ

### How can someone tell if a text is AI?

This preset does not detect authorship and makes no attempt to. It matches structural patterns that correlate with generated Japanese prose, such as bold labels at the start of list items, emoji bullets, inflated claims about completeness or world-first status, and sentences ending in a verb immediately followed by a colon and a code block. Treat its output as a style signal about shape, not a judgement about who wrote the text.

### How do I configure textlint-rule-preset-ai-writing in .textlintrc.json?

Add the preset to your rules object. The key is `@textlint-ja/preset-ai-writing`, which is shorter than the npm package name `@textlint-ja/textlint-rule-preset-ai-writing`; the repository ships this shorter form in its own example configuration. Set it to true to enable all rules, or to an object to pass per-rule options.

### Can textlint-rule-preset-ai-writing run as an MCP server?

Yes. Run the server with `npx textlint --mcp`, which requires textlint 14.8.0 or higher per the README. The preset is built around the resulting loop where an AI tool writes text, the MCP server reports findings, and the tool revises. Configuration details for editors such as Claude Code and VS Code Copilot are on the textlint MCP documentation site.

### Will upgrading the preset add new lint errors to my project?

Yes, and the README says so explicitly. A patch release covers rule fixes and improved detection accuracy, which can increase the number of reported errors, and the project counts that as a patch rather than a minor release. The recommended response is to pin your lockfile, since `package-lock.json` and `yarn.lock` are both named in the versioning section.

### Which other textlint rules should I combine with this preset?

The README recommends `textlint-rule-preset-ja-technical-writing`, with `ai-tech-writing-guideline` downgraded to info severity. That configuration fixes certain problems with the technical-writing preset first, then treats this preset's output as suggestions for further improvement.

## Sources

- [License: MIT](https://github.com/textlint-ja/textlint-rule-preset-ai-writing/blob/main/LICENSE)
- [Project website](https://textlint-ja.github.io/textlint-rule-preset-ai-writing/)
- [README](https://github.com/textlint-ja/textlint-rule-preset-ai-writing/blob/main/README.md)
- [Releases](https://github.com/textlint-ja/textlint-rule-preset-ai-writing/releases)
- [textlint-ja/textlint-rule-preset-ai-writing on GitHub](https://github.com/textlint-ja/textlint-rule-preset-ai-writing)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/textlint-ja-textlint-rule-preset-ai-writing