I have been working on a serial fiction project called Applied Yarns (the site is not up yet as of this writing but I wanted to post here about how I’m setting up some aspects of it) where I want to publish some fictional works. The first world I plan to explore there is Vvell, which soon I hope you’ll read about on the appliedyarns site.

I have lots of ideas but I don’t really have time right now to publish daily or even weekly updates and for me, the biggest hurdle is time spent doing editing. I find it possible to generate a block of about 1000 words within the world in a relatively short session but I don’t have time to polish and edit it during the same day given my work and family obligations.

I’m not entirely sure it’s a good idea to use an LLM as an editor or to get the story closer to a polished state, but I wanted to try it out. At the same time, I don’t think readers are really trusting of people who use AI to write, so I’m also publishing the exact freewriting raw material which the LLM uses to help polish the story together.

There are times that I don’t really like the phrasing or choice of metaphor used by the editor agent, so I’ll do an editorial pass of my own after it has had its turn. With this I think it will be possible for me to publish small “dispatches” once a week, which I think is a fine goal for someone like me trying to get a foot in the door of serial fiction.

When you’re freewriting you certainly end up being messy, contradicting yourself, and I even messed up character names. You also sometimes don’t just focus on the story and instead start writing about the world itself. The editor agent can take all of this and do a first pass at sorting the raw material into buckets that are much easier to do your own polish on than working straight from 1000 word chunks.

So I had a problem that is basically an editorial problem: take a pile of raw freewrites and turn them into a consistent published archive without losing the raw material and without the world’s canon drifting out from under me. So far it seems like a problem an LLM can help with, as long as you are careful about which parts you hand over. This post is about the pipeline I am building with Claude Code and the lessons so far that might transfer to anyone doing creative work with an LLM in the loop.

The rule I’m testing: use the LLM as an editor and an archivist, never as the author, and enforce that boundary with a hard approval gate.

The shape of the pipeline

The whole thing is a directory convention plus a skill (a markdown file of instructions the agent reads before doing anything). The flow looks like this:

  1. I drop raw freewrites into freewrites/inbox/, a directory that lives outside the Hugo content/ directory so nothing raw ever gets published by accident.
  2. I tell the agent to process the inbox. It reads every inbox file, the world canon file (WORLD.md), and a few recent published entries from each section it might write into (so it can match voice and check for overlap).
  3. It writes a proposal to freewrites/inbox/PROPOSAL.md and stops. Completely stops. At this point it has not touched a single other file.
  4. I read the proposal, adjust it or approve it.
  5. Only after approval does it update the canon, write the polished entries, archive the raw freewrites verbatim, and clean up after itself.

Steps 2 and 3 are the analyze phase and step 5 is the write phase. The gap between them is the important part.

The approval gate is the whole trick

The first version of any “LLM processes my writing” workflow that people reach for is one shot: here is my raw text, go update the site. I think this is a mistake for creative work even when the model does a decent job, because you lose the moment where you get to exercise judgement over your own world.

The proposal document forces that moment to exist. For each freewrite the agent has to lay out:

  • Canon additions — every new proper noun, place, fact, or custom, with the exact sentence it wants to add to WORLD.md and which category it lands under.
  • Canon conflicts — anything in the freewrite that contradicts existing canon, quoting both sides. The skill instructions say NEVER silently resolve a conflict. I choose whether to revise canon, treat the new material as apocrypha, or drop it.
  • Planned entries — for each entry it wants to write: the target section, a working title, a one line pitch, and which freewrites it draws from. It is also allowed to propose that part of a freewrite yields nothing yet, which is a surprisingly important permission to grant. Not every session needs to become content.

Reading a proposal takes me a few minutes. Writing the polished entries myself would take hours. That’s the trade: the LLM does the labor and I keep the authorship decisions.

One practical detail: because the proposal is a file and not just chat output, the pipeline is resumable. The skill starts with a resume check — if PROPOSAL.md exists from a previous session, present it and ask whether to proceed, revise, or discard. Sessions get interrupted, usage limits reset, life happens. Making the intermediate state a file means none of that loses work.

Canon is a file, and conflicts surface loudly

WORLD.md is the single source of truth for the world. Every proper noun that appears in a published entry has to exist there first, which the skill enforces as an explicit rule. This sounds bureaucratic but it is the thing that keeps a fictional world coherent when it’s being assembled from stream-of-consciousness sessions written weeks apart.

The conflict surfacing has caught real contradictions I generated and might have caught on my own, but maybe not. When your freewrite from Tuesday disagrees with canon you wrote three weeks ago, you want that decision put in front of you with both quotes side by side, not smoothed over by a model that is trained to produce agreeable, consistent-sounding text. But as you go on with serial fiction you get less leeway like this so it’s good to have an editor say, “hey guy what are we doing here.”

Archive the raw material byte-for-byte

After approval, each raw freewrite gets moved into a published freewrites section with frontmatter added, but the body is copied byte-for-byte verbatim. No typo fixes, no reformatting. The skill says exactly that, in those words, because an LLM’s natural instinct is to helpfully clean things up.

I wanted this for two reasons. First, the raw sessions are honest in a way the polished entries aren’t, and readers who care can see the B-roll. Second, every polished entry carries a sources list in its frontmatter pointing back at the freewrite slugs it was drawn from, so there is full provenance from published dispatch back to the raw session it came from. A small Hugo build check at the end of the pipeline verifies none of those source links are dangling.

It’s still entirely possible that some (or most) readers will just hate the idea that a model was used in the process, but I’d be interested to hear those opinions directly.

When the agent misbehaves, fix the skill, not the output

I’m using my new project cassette, a TUI for freewriting, to do the freewriting. Early on I wanted a way to write things during a freewrite that were off the record (notes to myself, ideas I wasn’t committing to, or just to pause and do the freewrite thing of “no idea no idea no idea…”). So I added a “B-sides” feature to the TUI. This just lets me write whatever then return to the A side once I get momentum back. The agent kept incorporating B-side material into proposals despite instructions not to.

The right fix is to open the skill file and add the rule: everything from a “B side” heading to the next H2 is off the record, excluded from canon and entries, but still archived verbatim with the rest of the session. One edit, and the behavior is fixed for every future session instead of just this one.

The skill also grew an Editorial notes section at the bottom that I maintain by hand and that explicitly overrides the defaults above it. This is where standing creative guidance lives: dispatches are the primary story mechanism, they are written in third person close on the main character, I prefer short character names so flag long ones in the proposal. When my taste changes, I edit that section and the pipeline changes with it. It’s the same feedback loop as maintaining a CLAUDE.md for a codebase, just pointed at editorial judgement instead of code style.

The consistency sweep, an underrated superpower

A side benefit of having canon in a file and all content in a repo: renames become cheap. I renamed a character partway through (long names kept bothering me) and a faction too. Doing a rename sweep across every published entry, checking each occurrence against the nomenclature in WORLD.md, is exactly the kind of tedious, mechanical, judgement-light work an LLM does quickly and, so far in my experience, well. This is the “archivist” half of the job and the part I’m most comfortable handing over.

What I’d tell someone building their own

  • Put the raw material somewhere the publish step can’t see. An inbox directory outside content/ costs nothing and prevents the worst accident.
  • Make the LLM produce a proposal artifact and make approval a hard gate. The gate is what keeps the work yours.
  • Keep canon in one file and require everything published to trace back to it.
  • Archive raw input verbatim with provenance links. You will want the paper trail.
  • When the agent does something you don’t like twice, encode the correction in the process doc instead of correcting the output again.

The thing I was worried about going in was that putting an LLM in the middle of a creative project would flatten the writing into generic LLM prose. I think being straightforward about how you use an LLM in the process of creation and providing a view of the raw material is the way to engage with audiences. And I also think such a process will lead to prose that doesn’t just sound like any other generated text (which definitely has its own style). Nonetheless the jury really still is out if “good” work can be made this way.