Sepia Moves the AI-Writing Fight to the Narrative Layer, Then Ships No Evidence It Won

A 39-hour-old agent skill argues that every humanizer on GitHub is editing the wrong layer. The argument is strong. The skill has never been tested.

Every tool built to make AI writing sound human edits the same layer: word choice and sentence rhythm. Strike the em-dashes, ban the tired verbs, vary the paragraph lengths, ship it.

There is a paper that says this barely moves the needle. Russell et al., 2026 built a corpus of 61,608 stories from 10,272 prompts, written by humans and five frontier models, and trained a classifier on narrative features alone. No vocabulary. No syntax. Just how the story is built: whose head you are in, whether scenes have consequences, how conflict resolves. That classifier reports 93.2% macro-F1 separating human from AI. The paper reports that models including stylistic cues retain a little over 97% of the performance you get without them.

Which means the entire humanizer genre has been sanding the visible 3%.

Nanako0129/sepia is the first widely noticed project to take that finding and build the tool it implies. It appeared on August 28, 2026, and by the following afternoon had around 594 stars against 17 commits from one author. Its own one-line pitch: "De-AI writing at the layer that actually gives AI away."

I think the argument is right and I would not yet trust the implementation. Both halves of that matter.

What it is, mechanically

Sepia is 27 files, and none of them execute. There is no linter, no scorer, no regex pass, no Node dependency, no test suite, no CI. The product is skills/sepia/SKILL.md plus seven reference markdown files, distributed as a portable Agent Skill for Claude Code, Codex, Grok Build, and Antigravity. MIT licensed, version 0.2.0, single author, and if you install it you are installing a prompt.

That is not a criticism by itself. The bet a markdown skill makes is that the model already knows how to write and needs a discipline rather than a function.

The discipline has a shape. Four operations, and the distinction is sharper than most editing tools bother with: review ("Diagnose only, no edits"), refactor (minimal in-place revision preserving structure and voice), recreate (full rewrite), and write (new content). For fiction it runs three passes in fixed order: narrative architecture, then discourse flow, then surface style. The skill's own rule is "structure is fixed before style, always."

The best idea in the repo is a two-stage protocol it makes mandatory for editing work. You produce a defect list before you touch a sentence. The stated reason is the interesting part: "paraphrasing without a defect list makes AI fingerprints more visible, not less." Rewrite blindly and you replace one machine signature with another. Sepia even publishes the edit ratio it targets, 74% replace, 18% delete, 8% insert, which tells the model that deletion is a real move rather than a failure to think of something.

It caps itself at three to five moves per story, on the principle "calibrate to the human distribution, don't invert the AI one." Apply every rule and you have built a new fingerprint. I have watched people do exactly this by hand for a year.

The venue rules are the part I would actually use

The fiction side is where the research lives. The professional side is where the daily value is, and it holds up better than I expected.

Five venues get their own file: release notes, developer replies, postmortems, tickets, and technical articles. They share one professional-pass.md with a ten-check slop list and, sensibly, a false-positive whitelist so that changelog categories, issue templates, and RFC sections do not get flagged as formulaic when they are formulaic on purpose.

The rules genuinely differ by venue. Article-like documents get weighted on relevance, density, stance, and coherence. Short answers get weighted on factuality, specificity, and templatedness. That is the right split, and it is the split most style tools refuse to make.

Read the postmortem file and you will find the line the whole thing turns on: "Blameless toward people, merciless toward mechanisms." Its sharpest check is what it calls agentless fog, where the tell is a sentence like "mistakes were made" or "the change was deployed" with no actor anywhere in it. The fix is stated in four words: "Blameless ≠ agentless." Another rule says an action item is "a change with an owner and a date." A third notes that a postmortem admitting no wrong judgment anywhere has not been written yet.

The developer-replies file leads with "Answer first," flags the praise opener and the sign-off, requires citing artifacts by file.py:214 or commit SHA, and catches something I have never seen a writing tool catch: promising work in the reply instead of doing it.

Both files tell the model to sample the venue's own recent artifacts before editing, because "the venue corpus, not this skill, defines the target voice." That instruction is worth more than most of the rules it precedes.

Put this into practice

If you want to try it, the lowest-friction path is one command and one document.

Install it into whichever agent you already use. For Claude Code that is claude plugin marketplace add Nanako0129/sepia; Codex takes the same form; the host-neutral route is npx skills add Nanako0129/sepia -g. Nothing compiles and nothing runs, so uninstalling is deleting a folder.

Then start with review on something you already shipped. Not a draft you are attached to. Point it at a postmortem or a PR reply you wrote three weeks ago and ask for diagnosis only. You will get a defect list rather than a rewrite, and the value of the whole exercise is in reading that list and disagreeing with a third of it. If you jump to refactor on a live draft you will learn nothing about whether the rules are right, only whether the model is fluent, and it is always fluent.

The second move, if you write in a consistent venue, is to read professional-pass.md and the domain file for your venue and lift the checks into your own house style. They are plain markdown. Whether or not you keep the skill installed, the postmortem checks are a better review rubric than most teams write for themselves.

Skip the fiction passes unless you write fiction. That is where the detector-feature tables live, and it is a different project with a different purpose sharing a repo.

Honest limitations

Sepia publishes no evaluation of itself. None. Zero before-and-after examples, no n, no task set, no judge model, no test corpus. Every number in the README belongs to somebody else's paper. The repo's open PR #8 is titled "Add a bounded operation evaluation pack," which confirms the eval does not currently exist and the author knows it.

So the honest description is that this is a well-argued hypothesis with a citation attached to the premise and nothing attached to the conclusion. The paper says narrative features carry the signal. Sepia asserts that its particular rules move a piece of writing along that axis. Nobody has measured the second claim, including its author.

The borrowed numbers also need care. The 93.2% macro-F1 and the 61,608-story corpus check out against the paper's abstract. The README's "95.5% → 93.9%" pair does not appear in the abstract, and sepia's own research file gives one of those figures as 96.0%, so the repo contradicts itself. If you cite anything from this, cite the 93.2% and the paper's own "over 97% retention" phrasing, and leave the other pair alone.

Open PR #7 is titled "Separate research evidence from Sepia inference." That is the author telling you, in a still-unmerged pull request, that measured findings and personal extrapolation are currently mixed together in the shipped files.

The footprint deserves saying out loud. Created August 28, 2026 at 05:56 UTC, tagged v0.2.0 twenty-two seconds later, 17 commits, one contributor, zero external contributions, zero real issues. Around 594 stars in thirty-nine hours. The attention is running well ahead of the engineering.

And there is a framing split the README does not acknowledge. For professional prose, sepia states plainly that "the goal is not 'fool a detector'", and that what matters is text carrying information and holding a stance. For fiction, the narrative pass reverse-engineers a classifier's feature set and steers output toward the human band, marking which feature groups no existing humanizer covers. Those are two different projects with two different ethics, and only one of them is stated.

One more. The repo contains a full competitive survey naming blader/humanizer, mshumer/unslop, sam-paech/antislop-sampler and others, along with which methods sepia borrowed from each. It is in research/ecosystem.md, and it is in Chinese. The README's competitive claim, that "every popular humanizer edits word choice and syntax," is left unattributed while the file substantiating it sits untranslated one directory down. That same file admits something the README omits: vocabulary-level tells expire with model generations, and fixing that layer is worth about 1.6 percentage points.

What I would take from it

The layer argument is the contribution, and it survives every complaint above. If AI writing is detectable primarily by how it builds a story or an argument rather than by which adjectives it reaches for, then the whole "banned words list" approach to writing with a model is a tidiness ritual. I say that as someone who maintains a banned words list.

Use sepia as a rubric before you use it as a rewriter. Read the postmortem file tonight; it will improve your next incident review whether or not you ever run the skill. Then check back in a month to see whether PR #8 landed, because the day this project publishes an evaluation of its own rules is the day it stops being an argument and starts being a tool.

Sources: Nanako0129/sepia; Russell et al., 2026, arXiv:2604.03136.