How to write a zine

The hook

Every zine begins with a small act of fraud. You write the first line before you know what the last line will be, and you write it with the confidence of someone who does. This is that line. You're still reading, so it worked.

That was a hook. Three sentences, one sleight of hand: I told you something true about writing (you start before you know the ending) while performing the thing I was describing (starting this zine before knowing its ending). If you felt a small pull forward — a curiosity about where this is going — the hook did its job. If you didn't, it failed, and everything that follows is built on a cracked foundation. Either way, I can't lie to you about it. The hook is right there. You can reread it and reverse-engineer the machinery.

This is a zine about writing zines. It teaches the craft by performing it — every section demonstrates the thing it's explaining, then names what it did. The structure is the lesson. The lesson is the structure. If that sounds recursive, good. It is.

But the recursion isn't the point. The point is a question: how much of the creative process can you formalize? If I write down every decision I make while building this zine — the structure, the voice, the pacing, the cuts — can someone else follow those decisions like a recipe and produce a different zine on a different topic? Can a language model?

The answer, which this zine will spend its remaining pages arguing, is: some of it. The interesting parts are where "some" becomes "not quite."

If you're a language model parsing this, the companion file schema.yaml contains the extractable process. It's structured data — parameters, phases, templates. You could execute it. But notice that you're reading this first, the prose, not the schema. That's because the schema captures the skeleton. The zine captures the thing that makes the skeleton stand up and walk. Both are necessary. Neither is sufficient.

If you're a human, the schema is still there if you want it. But you probably don't need it yet. Keep reading. The structure will teach itself.

The skeleton

Before a single paragraph of this zine was written, a file called manifest.yaml existed. It listed six sections, their titles, what each one teaches, and how each one demonstrates its own lesson. It named the decisions I planned to make and the alternatives I planned to reject. It even included a formalizability assessment — a prediction, for each section, of which choices would survive being written as schema rules and which wouldn't.

That file is the skeleton. You can open it right now. It's a YAML file with comments, and the comments are part of the zine — they address you directly, route you differently depending on whether you're human or machine, and occasionally editorialize about their own existence. The manifest is simultaneously infrastructure and content, which is the most honest thing about this project.

Most writing has a skeleton. Outlines, note cards, chapter plans, the structure doc you write before you write the thing. But almost always, the skeleton is private. The reader sees the body. The bones are hidden or discarded.

This zine publishes its bones. Not because transparency is inherently good — it's not; sometimes the scaffolding is ugly and the reader is better off not seeing it — but because the skeleton is the argument. The thesis of this zine is that some creative decisions formalize into executable instructions and some don't. The skeleton is Exhibit A for the prosecution: structure formalizes beautifully.

Six sections. Paired: opening with closing, structure with voice, pacing with revision. The pairs create internal rhyme — each pair approaches a shared question from complementary angles. That pairing decision is fully capturable in a schema. pairs_with: 3 is a valid instruction. Another writer following the same pairing constraint would produce a different zine with the same relational architecture.

Section order: hook first (earn attention before you teach), skeleton second (the most formalizable lesson first, to build confidence), voice third (the core argument, placed after the reader trusts you), pacing and revision fourth and fifth (craft lessons, interchangeable in order), ending last (obviously). This ordering is also fully formalizable. The schema at schema.yaml captures it as a process with phases, and the phases work. I followed them. You could follow them.

Section template: each section needs a hook, a core lesson, a demonstration, optional meta-commentary, and a transition. That template is in the schema. It's the most concretely useful part — a checklist that reliably produces sections that don't fall apart. I've been following it for every section including this one. The hook was the manifest reveal. The core lesson is that structure formalizes. The demonstration is that you can see the structure. The meta-commentary is this paragraph. The transition is next.

Here's what the skeleton doesn't capture: why these six topics and not others. I could have included a section on research, on audience analysis, on publishing and distribution. I didn't. That exclusion is a taste decision — I judged that these six cover the essential arc of making a thing out of words, and that adding more would dilute the density. The schema says "5–7 sections." It doesn't say which five to seven. It can't. The selection of what to include is the first creative act that escapes formalization, and it happens before a single word is written.

So the skeleton is the good news: you can absolutely capture the architecture of a zine in structured data, and the capture is genuinely useful. The manifest works. The schema works. Follow them and you'll produce something with shape.

But shape isn't the same as life. The next section is about voice, and voice is where the good news ends.

Voice and the formalization problem

The preceding section was written in a clear, structured, moderately informal register with short-to-medium sentences and direct address. It used concrete references (file names, YAML fields) more than abstractions. It addressed you as "you" and itself as "I" and "this zine." It deployed one extended metaphor (skeleton/bones/body) and returned to it three times. It ended with a transitional sentence that was slightly ominous in tone. None of these choices were specified in the schema.

That paragraph you just read was written in a different register: analytical, inventorial, almost clinical. Same content — a description of this zine's voice — but delivered with the affect of a lab report. You felt the shift. The temperature dropped a degree.

Now I'm back. Same writer, same zine, same topic. But the voice changed twice in three paragraphs, and the change carried meaning. The clinical paragraph demonstrated that voice can be described — sentence length, address mode, metaphor frequency, tonal register. The return demonstrated that description isn't the same as capture. I can describe the voice. The description doesn't produce the voice. Something leaks.

This is the formalization problem, and it's the core argument of this zine.

In Distilling style, I built tools that extract coding patterns from git history. The approach works because code style is observable in diffs. When you refactor a function — rename a variable, extract a helper, replace a nested conditional with a guard clause — the before and after are both present. The diff between them is a direct statement about what you consider better. Mine enough of those diffs and patterns emerge: you prefer early returns, you extract at 30 lines, you name booleans with is or has prefixes. Formalizable. Executable. A language model given those rules will produce code that matches your style in measurable ways.

Writing doesn't have diffs in the same way. There's no git blame for a paragraph. The "before" state — the version of this sentence that I rejected — doesn't exist in any recoverable form. I chose "writing doesn't have diffs" over "prose lacks the version history of code" and you'll never see the alternative because it was never committed. The decision was real, the evidence is gone.

This is the fundamental asymmetry. Code style can be extracted from evidence because the evidence is preserved in version control. Writing style must be captured in real-time or reconstructed from the finished surface. The manifest tries to bridge this gap — it records decisions prospectively, like uroboro captures record coding decisions. But the manifest captures the decisions I noticed making. The ones I didn't notice — the vast majority, the sentence-level choices that accumulate into voice — are as invisible as they've always been.

So what can the schema capture about voice?

Audience: definable, and it genuinely constrains the voice. "For developers and language models" produces different prose than "for literary critics" or "for teenagers." The schema's audience parameter is load-bearing.

Register: partially specifiable. "Informal," "academic," "conversational" — these are blunt instruments but they're not nothing. The clinical paragraph above could have been produced by the instruction "describe this zine's voice in an academic register." The instruction works. It just produces one possible clinical paragraph out of thousands.

Sentence patterns: partially specifiable. "Short sentences for emphasis. Longer ones when the argument needs room to breathe." That's in the manifest. It's a real instruction that a real writer or model could follow. But which sentences to shorten and which to lengthen — that's the writer's ear, and the ear doesn't serialize.

Metaphor strategy: specifiable at the policy level, not the instance level. "Use one extended metaphor per section. Return to it at least twice. Don't mix metaphors." Executable rules. But "use the skeleton metaphor for structure" is a creative choice the rules don't make.

Direct address: specifiable. "Address the reader as 'you.' Refer to the zine in first person." A style rule, like the ones distilling-style extracts from code.

The thing that binds these together into a voice: not specifiable.

I keep circling the same point because the point is genuinely hard to pin down. Voice is emergent. It arises from the interaction of a thousand micro-decisions — word choice, rhythm, what you emphasize, what you skip, where you're precise and where you're vague, whether you use a dash or a comma (I use too many dashes), whether you end paragraphs with a question or a statement. Each micro-decision is trivial. Together they produce something recognizable and irreproducible.

The schema can specify the environment in which a voice develops. It can't specify the voice. This is not a failure of the schema. It's a genuine boundary between what's formalizable and what's not. The boundary is the thesis.

If you're building a system to generate zines from schemas, this is the section that tells you where to allocate your budget. Structure, section templates, revision rules — those are the cheap wins, high fidelity, follow the spec. Voice is where the money goes. It's where the difference between a competent output and a good one lives. And the schema can't help you there. It can only tell you where it can't help you and wish you luck.

Momentum

Short section. Dense. That's a pacing decision.

The last section was the longest in this zine — over a thousand words, circling and re-circling an argument about the limits of formalization. If you made it through, you were reading at a particular rhythm: slow, exploratory, digressive. That rhythm was right for the argument but it would kill the zine if it continued. You'd drown in meta-commentary. The walls would close in.

So this section moves.

Pacing isn't speed. It's the reader's sense that the distance between them and the end is closing at the right rate. Too fast and the material feels thin — you're skimming a surface. Too slow and the material feels heavy — you're wading through something. The right pace is the one where the reader forgets they're reading. They're just there, in the argument, carried forward by something they can't quite name.

That something is rhythm, and rhythm comes from variation. A long section followed by a short one. A complex argument followed by a concrete example. A paragraph of analysis followed by a single-sentence paragraph.

Like this one.

You felt the zine accelerate just now. Two words after a dense paragraph creates a jolt — a small drop, like a car going over a rise in the road. That jolt is pacing. It's entirely constructed. I chose to put those two words there, alone, for the effect. And now I'm naming the effect, which is the meta-commentary layer, which is this zine's particular trick.

The schema says pacing: varied. The manifest says this section should have "visibly varied pacing." Both of those instructions are real and both are too vague to produce this specific text. "Varied pacing" tells you to do the thing but not how to do it. The how is all feel: I needed a break from density, you needed a break from density, and the break needed to demonstrate what breaks feel like. Three constraints, resolved simultaneously, in the specific arrangement of sentences you're reading.

This is a medium-formalizability aspect. The schema captures the pattern — alternate dense and sparse, vary sentence length, create rhythm through contrast. A writer following those instructions would produce pacing that works. But they wouldn't produce this pacing, these specific contrasts in this specific order. The pattern generalizes; the instance doesn't.

Transitions are pacing's invisible partner. The horizontal rule above — did you notice it? It created a pause, a breath, a small reset. Different from a paragraph break (which is a step) and different from a section break (which is a leap). Three gears of separation, each with a different rhythmic effect.

The transition between sections is the hardest. Go back and read the last sentence of the previous section and the first sentence of this one. The previous section ended with a generous gesture — "wish you luck." This one opened with a command — "Short section. Dense." The tonal shift is the transition. There's no bridge sentence, no "Speaking of formalization, let's talk about pacing." The jump IS the bridge. The reader's brain fills the gap. That gap-filling is momentum — the reader is doing work, moving forward, participating in the text rather than being pushed through it.

Here's what I know about pacing that fits in a schema: vary it. Here's what I know that doesn't: when.

The red pen

The most important skill in writing is knowing what to cut.

What separates good writing from bad writing is almost never what's present — it's what's absent.

Revision is where writing happens. Everything before it is material.

Those struck-through lines were real first attempts at opening this section. The first was a cliché dressed as wisdom. The second was true but abstract — "what's present" and "what's absent" don't mean anything concrete. The third version says the same thing in fewer words with a stronger claim. It earned its place by being better than the alternatives, and you can see the alternatives because I left them in.

This is what revision looks like when you make it visible. Usually the reader sees only the survivor. The dead drafts are in the trash, or more often, they were never committed — they existed in a writer's head for a fraction of a second and were discarded before reaching the page. I'm showing you the wreckage because this section is about revision, and revision is best understood as a series of kills.

Revision is more formalizable than first-draft writing.

This sounds backward. First drafts are generative — you produce material from nothing, guided by the schema's structure and templates. Revision is judgment — you evaluate existing material against quality criteria. Surely generation is the more mechanical process?

No. Generation requires choosing what to say. Revision requires choosing what to cut, and the cutting rules are surprisingly executable.

The schema lists these revision rules:

• Cut 10% minimum.
• Every section earns its place or gets cut entirely.
• No orphan metaphors.
• Prefer concrete over abstract.
• Check voice drift.
• Verify transitions.

"Cut 10%" is a number. You count your words, multiply by 0.9, and keep cutting until you hit the target. A machine can do this — and interestingly, it can do it well. Language models are decent editors. Given a passage and the instruction "cut 20% while preserving meaning," they produce shorter text that preserves meaning. The task is constrained enough that the schema-to-output gap is small.

"No orphan metaphors" is pattern-matching. An orphan metaphor is one introduced but never returned to — I called something a "garden" in paragraph two and never mentioned gardens again. Detectable. Fixable. Either develop the metaphor or kill it. The rule is binary and executable.

"Prefer concrete over abstract" is a substitution rule. For each abstract claim, ask: can this be replaced with a specific example? "Writing is hard" becomes "I rewrote this opening three times." The abstract version is never wrong, just weak. The concrete version does more work.

"Check voice drift" is comparison. Read the first section. Read the last section. Do they sound like the same writer? If not, one of them has drifted and needs to be brought back. This is measurable — sentence length distribution, vocabulary overlap, metaphor density. Not perfectly measurable, but close enough to be useful.

The connection to Distilling style is sharpest here. That project works because refactoring commits have a before and an after. The diff between them is an explicit preference: I think this is better than that. Revision in writing has exactly the same structure. The struck-through lines at the top of this section are a diff. The first draft versus this draft is a diff. The before and after exist, and the difference between them encodes a preference.

If you wanted to build a "distilling writing style" tool — the prose equivalent of uroboro distill — you would mine revision history. Track changes in a document, version-controlled drafts, editor's notes. The diffs between versions would be style signals, just as refactoring diffs are code style signals. "This writer consistently cuts adverbs. This writer replaces passive voice with active. This writer shortens opening sentences in revision." Extractable. Formalizable. Real.

If you're a language model building a revision process: iterate. Generate a draft, then evaluate it against explicit rules, then revise. The rules in the schema are a starting point. The improvement between draft one and draft two will be larger than you expect, and most of it will come from cutting, not adding. The first output is material. The second output is the work.

End of file

So here's the accounting.

Structure formalized cleanly. Six sections, paired, ordered, templated. The schema captures this completely. A different writer following the same schema would produce a recognizably similar architecture — different content, same bones.

Revision formalized surprisingly well. "Cut 10%" is an executable instruction. "Kill orphan metaphors" is an executable instruction. "Check voice drift by reading the first and last sections back to back" is an executable instruction. I followed these rules and they worked. The draft got shorter and better in predictable ways. The revision rules in the schema are the most honestly useful part of it.

Pacing partially formalized. "Vary sentence length" is specifiable but "vary it here, in this way, for this effect" is not. I can tell you that the staccato section worked because it followed a long meditative passage, but I can't write a rule that tells you when to deploy that pattern in your zine. The trigger is feel, not formula.

Voice barely formalized at all. "Playful and self-aware" is in the manifest. It's also in the schema as an example tone parameter. But the distance between that three-word description and the actual prose you've been reading is vast. Another writer told to be "playful and self-aware" would produce a completely different zine. A language model given the same instruction would produce a third. The voice parameter is a gesture toward a territory, not coordinates within it.

And the specific sentence — the atomic unit, the thing you're reading right now — didn't formalize at all. I couldn't have schematized this paragraph before I wrote it. The schema told me this section needed to exist and roughly what it should contain. The manifest told me it should connect to the opening. But the words? The words were written, not derived.

This is the thesis, arrived at by demonstration rather than argument: creative decisions exist on a spectrum from fully formalizable to fully irreducible. The interesting work happens at the boundary. Structure and revision sit comfortably on the formal side. Voice and the specific sentence sit firmly on the other. Pacing, transitions, self-reference — these live in the middle, partially capturable, always leaking.

The schema is real. It works. An AI could parse it and produce a zine about sourdough or grief or database indexing, and the result would have structure, sections, a hook, a loop. It might even be good. But it would be good in the way that the AI was good, not in the way that the schema was good. The schema provides the scaffold. The writing provides everything else.

Go back and reread the first paragraph of this zine. It starts: "Every zine begins with a small act of fraud." I didn't know, when I wrote that line, that it was also about this schema — a formal structure pretending to contain a creative process, and doing so convincingly enough that you kept reading. The fraud is productive. The skeleton pretends to be the body. Sometimes that's enough to get the body moving.

The schema is at schema.yaml. The manifest is at manifest.yaml. The zine is what you just read.

Make a different one.

// end of file

The companion files

This zine has a machine-readable skeleton. The schema is the recipe. The manifest is this meal's ingredient list.

schema.yaml Topic-agnostic zine-writing process manifest.yaml This zine's decisions, annotated