patina: a pattern-based AI-writing humanizer for Korean, English, Chinese and Japanese

What patina solves, and who it is written for

The problem is not that AI-assisted drafts are wrong. It is that they arrive wrapped. Filler openers, hedged transitions, three-item lists that could be one clause, and a closing paragraph that repeats the opening. The README's own illustrative email edit shows the shape of it: a sentence that begins "I'm writing to let you know that" becomes a sentence that begins "The launch review is Friday at 2 p.m." The claim, the date and the two open pricing questions survive. The packaging does not.

That framing matters because it sets the boundary of the tool. The README states patina is "built for allowed AI-assisted drafting, not for evading detectors," and the project repeats the point in its facts table: scores are editing signals, not authorship proof. If your goal is to get text past a commercial detector, this is the wrong tool and the maintainers say so.

The audience is narrower than "anyone who writes with an LLM." It is people drafting in Korean, English, Chinese or Japanese who want a repeatable edit rather than a one-off prompt. The 184 patterns are distributed as 46 per language, split into 37 rewrite-capable patterns and 9 score-only viral-hook patterns. That split is worth understanding before you install anything: 9 of the 46 patterns per language can flag a problem but will not fix it.

Named patterns, three axes, and a diff you can read

patina is deterministic and pattern-based. The README contrasts this with a black box: every edit is driven by one of 184 named patterns, and `--diff` prints what changed and why. That is the central design decision, and it is the reason the tool is auditable in a way a rewrite prompt is not. When patina shortens a sentence, there is a pattern ID behind the decision.

Three axes are kept independent. Document Type owns genre, purpose, structural conventions and pattern policy. Persona owns a reusable voice fingerprint: vocabulary, rhythm, explanation habits. Register owns casual or professional delivery. The README is explicit that patina "does not infer one axis from another" and that an explicit value never fills an omitted axis. Omit Persona and Register and the source voice and register are preserved. This is a deliberate constraint, and it is the opposite of how most rewriting tools behave, where a style hint bleeds into tone and structure at the same time.

Meaning preservation sits outside all three as an outer guard. On the web playground, each rewrite passes MPS and fidelity floors that reject drift. On the CLI, `--verify` adds the same kind of check after a rewrite, and `/patina --strict` does it inside the agent skill. The README describes the goal as rewriting "without changing the claim, numbers, polarity, or causation." Whether the floors catch every drift is a separate question, and the project publishes a pre-registered study that documents where rewriting fails alongside where it works.

Installing patina and running a first rewrite

There are three surfaces: an agent skill, a Node CLI, and a hosted browser playground. The browser route needs no install at all. Open the playground URL, paste text, and the rewrite runs server-side behind the MPS and fidelity gates. In API mode the playground forwards your own key per request, and the README states that key is never stored or logged.

The CLI requires Node 18 or later. The README gives these two commands as the starting point:

npx patina-cli --lang en input.txt          # rewrite
npx patina-cli doctor                       # check backends and keys

The first line rewrites `input.txt` as English. The second checks which backends and keys resolve on your machine, which is the command to run before anything else if you are unsure whether you have a working provider. If you have a logged-in `codex`, `claude` or `gemini` CLI, the README states you need no API key: add `--backend codex-cli`.

For an agent skill, the README gives a single line to paste into Claude Code, Codex CLI, Cursor or another agent:

Install patina by following https://raw.githubusercontent.com/devswha/patina/main/INSTALLATION.md

After installation the skill is invoked with `/patina --lang en` followed by the text. The repository also ships a Dockerfile with a `patina` entrypoint and a default `--help` command, and an `install.sh` at the top level, though the README's quick start points at INSTALLATION.md for the full option set.

Project configuration lives in `.patina.yaml`. The README shows this shape:

version: "8.7.0"
language: ko              # ko | en | zh | ja
document-type: default    # genre/purpose + pattern policy
persona:                  # optional reusable voice; omit to preserve source
register:                 # casual | professional; omit to preserve source

The comments in that snippet are the important part. Leaving `persona` and `register` empty is not a missing value; it is the instruction to preserve the source voice and register.

The CI gate, and why the offline flag matters

The command list includes a mode that is genuinely different from the others:

patina --score --offline --exit-on 30 input.txt

The README labels this a "deterministic CI gate, no API key." Three properties follow from that. It scores rather than rewrites, so it will not silently alter a document in a pipeline. It runs offline, so it needs no provider and no key. And it exits non-zero at a threshold you set, which makes it usable as a build step. A companion GitHub Action exists at devswha/patina-action, and the repository carries `.pre-commit-hooks.yaml` plus a `patina-score` binary entry pointing at `scripts/precommit-score.mjs`.

The threshold is the part to think about. `--exit-on 30` is the README's example, not a recommendation, and the score is described as an editing signal rather than a verdict. Choosing a number means deciding how much AI-shaped phrasing your project tolerates in committed prose. That is a policy decision, and patina does not make it for you.

Other modes cover the rest of the loop: `--audit` detects patterns without rewriting, `--diff` shows pattern-by-pattern changes, `--verify` rewrites and then checks the MPS and fidelity floors, and `--batch docs/*.md --outdir cleaned/` processes a directory. Personas can be learned from samples with `patina persona new my-voice --from-sample past-posts.txt` and then applied with `--persona my-voice`.

Where patina fails, by its own account

The repository ships a matched set of example files, `examples/01-success-01.md` through `examples/13`, each paired with a failure counterpart. That pairing is unusual and it is the most useful thing to read before trusting the tool on your own text. The project also publishes a pre-registered study at `docs/research/2026-rewrite-efficacy-study1.md` that reports where rewriting fails alongside where it works.

The structural limitation is in the pattern count. Nine of the 46 patterns per language are score-only viral-hook patterns. They can flag a construction but they will not rewrite it. So a document can score above your threshold with no available rewrite for part of what pushed it there. If your workflow assumes every flag has a corresponding fix, that assumption is wrong.

The second limitation is scope. patina edits packaging, not substance. It will not repair a weak argument, a missing citation or a claim that does not follow from its evidence. A draft that is thin will still be thin after a rewrite, and the README's own example edit only removes framing and tightens a sentence.

The third is the detector question. The README states plainly that scores are editing signals, not authorship proof. Anyone who needs a defensible statement that a given text was or was not machine-written will not get it here, and the project does not pretend otherwise.

There is also a maintenance surface that has shrunk. The README states that the VS Code, Obsidian and Gmail preview clients are retired, with a historical record at `docs/integrations/editors.md`. Native Aside desktop acceptance is listed as not planned. If you were planning to work inside an editor, the current answer is the agent skill or the CLI.

How patina differs from a generic rewrite prompt

The obvious alternative is asking a model to rewrite the text in your own voice. The difference in approach is not quality; it is where the decision lives. A prompt-based rewrite produces prose and no record. patina produces prose plus a named pattern behind each change, and `--diff` prints them. If you need to explain an edit to a reviewer, a co-author or a compliance process, that record is the whole point.

A second alternative is a commercial AI detector used as a gate. These answer a different question: they estimate whether text looks machine-written. patina answers whether specific constructions are present and removes them. The README draws the line itself, saying patina is for allowed AI-assisted drafting rather than detector evasion. Using a detector as your gate also means accepting a probabilistic verdict with no named cause, which is the opposite of what `--diff` gives you.

The third alternative is a linter such as Vale, which also uses named rules and also runs offline in CI. The resemblance is real, and the difference is in the rule content. Vale rules are hand-written style and terminology checks for a team. patina's patterns target AI-shaped phrasing specifically, and its three axes (Document Type, Persona, Register) have no equivalent in a prose linter. If your problem is house style, a linter is the better fit. If your problem is that drafts read like drafts, patina is aimed at that.

One more comparison the README makes implicitly: the browser playground runs the same MPS and fidelity gates as the CLI, so the hosted path is not a reduced demo. The trade-off is that server-side rewriting means your text leaves your machine, while the CLI keeps it local.

Licence, maintenance and upgrade cost

patina is MIT licensed, and the repository carries a NOTICE file alongside LICENSE. MIT is permissive: it allows commercial and closed-source use with attribution and no warranty. That is the shape of the licence, not legal advice for your situation.

The repository is not archived, and the last push was on 2026-09-15. The most recent release is v8.7.0, published the same day, with v8.3.0 and v8.2.1 earlier in September. The README notes that npm publication has resumed and that the registry serves 8.7.0 for both `patina-cli` and `patina-humanizer`, with release channels documented at `docs/integrations/release.md`. If you pinned an earlier version, that note is the one to read before upgrading.

Upgrade cost is dominated by two things. First, the pattern catalog: 184 patterns across four languages means a version bump can change which constructions are flagged and rewritten, so a threshold that worked at one version may not hold at the next. Rerunning `--score --offline` on a fixed sample set after each upgrade is the cheap way to see that. Second, provider defaults: `.env.example` lists preset providers including openai, gemini, groq, kimi, moonshot, together, minimax and minimax-cn, with `PATINA_API_KEY` taking precedence over provider-specific variables. That precedence rule is worth knowing before you set two keys and wonder which one won.

Editorial conclusion

Adopt patina if you draft in Korean, English, Chinese or Japanese and want the edit to be inspectable: the 184 named patterns, the --diff output and the --score --offline gate are the reasons to pick it over a generic rewrite prompt. Do not adopt it if you need a guarantee that text passes a commercial AI detector, or if your source text is a single sentence with no rhetorical packaging to remove. Before rolling it into a pipeline, run npx patina-cli doctor to confirm which backend resolves, then run --score --offline --exit-on 30 on a sample of your own documents to see where your material actually lands against the threshold.

Frequently asked questions

Official sources

1. devswha/patina on GitHub
2. License: MIT
3. Project website
4. README
5. Releases