One sentence in.
A week of work out.

Ten stages, one sentence

Start with the thing that makes the rest worth building. A single instruction — make next week's shorts — hands off to a chain that does not ask another question until it has finished.

Ten stages. Only one of them generates media, and that one is the least interesting. The transferable part is the shape: a catalog decides what is worth making, selection picks from it, writing stages produce the words, assembly stages produce the artifact, and the last stage checks that the thing actually exists. Swap the artifact for a newsletter, a changelog, a set of product descriptions or a weekly report, and the chain is identical.

What the catalog does, and why it matters most

The stage everyone skips is the first one. A catalog file holds the inventory of things worth making — in this system, every published class, with enough metadata to decide which would make a good Short. Selection reads it, applies rules, and picks.

That is what makes the instruction short. “Make next week's shorts” works because the agent is not being asked what to make. It is being asked to run a decision it already has the inputs for. Every hour spent building the catalog buys back a sentence in every future instruction — and, more importantly, makes the output reproducible instead of dependent on how well you described things that morning.

What the agent knows when it wakes up

Every session starts from nothing. Whatever you explained yesterday is gone. The agent that runs your pipeline at 08:00 has never met you, and the only things it knows are the files it loads before it reads your instruction.

Which means agent behaviour is a filesystem problem, not a prompting problem. Almost every complaint that starts “it keeps doing X” is a fact that lives at the wrong level, or nowhere at all.

Where each kind of fact belongs

The section that earns its keep

Every memory file should carry a known traps section, and it should start empty. Each time the agent does something expensive and wrong, one line goes in. Not a description of the fix — a description of the trap, in the form of an instruction that would have prevented it.

## Known traps (already cost time — do not re-hit)

- Text transforms on this filesystem can strip carriage returns.
  Verify with the file reader, never by echoing the file back.
- A build tool's reported output size is not what the server sends.
  Measure the artifact over the wire.
- Deploy target IDs rot. Resolve at runtime by role, never paste an ID.

After a few months that section is the most valuable file in the project, and it is the reason a fresh session can be trusted with real work. It is also the cheapest thing in this entire class to start: open a file, write the heading, add the next thing that bites you.

Gates that refuse

A gate is a script that checks one thing and exits non-zero when it fails. A gate chain is a build that runs all of them and writes nothing at all unless every one passes. The difference between that and a linter is the refusal: a warning gets read once and ignored forever, and a non-zero exit stops the truck.

Five checks catch the great majority of what goes wrong when an agent is left alone. They are ordered, and the order matters — each one is cheaper than the next.

The two failures that make the case

And gates get things wrong too

A check written to ban a dangerous CSS property fired on the comment explaining why the property is banned. Fixed by stripping comments — then fired again on a later page that quoted the property in prose while teaching this exact lesson. The durable fix was to scope it: a text-matching gate scans only the region where the matched thing can do harm, which for a CSS property means stylesheets and nothing else.

The general rule is worth more than the specific fix. When a gate fires on content you believe is correct, the gate is a suspect. Repair the instrument. Never edit the work to make a check pass — that is how a document ends up accurate to its checker and wrong about the world.

Which check would have fired?

run twice, same answer both times

nothing collided, nothing spilled

the arithmetic was correct throughout

Work orders, not conversations

When work moves between two agents — or between you and an agent that will run while you sleep — a chat message is the wrong container. It cannot be audited, re-read, diffed or handed to a different model six weeks later. A numbered document can.

A work order has four parts, in this order, and the order is doing work:

The report comes back as a sibling file, WO-NN_NAME_REPORT.md, and gets audited by someone other than its author. A report that does not state what it could not verify is incomplete and goes back. That single rule changes agent behaviour more than any amount of prompt tuning.

This class was built through four of them

Not as an illustration — that is genuinely how the research underneath this page was produced. Each round caught something the round before it had missed.

Six claims from this build. Which hold?

Teaching it to write like you

Everything above gets an agent producing correct output. None of it stops the output sounding like an AI wrote it. For anything with your name on it — a newsletter, a script, a product description, a Short — that gap is the whole problem, and it is the one thing you cannot fix by prompting harder each time.

The fix is a file. Not a prompt you retype, but a written specification of how you write, loaded before the agent drafts anything, and revised every time the output is wrong.

Six steps, and the fifth is the one that works

1. Gather. Collect a corpus of your own prior writing. Not your best writing — your typical writing, because that is what has to be reproduced.
2. Extract. Have the agent analyse it for sentence length, punctuation habits, recurring constructions, and the words you never use. Machine analysis beats introspection here; almost nobody can accurately describe their own register.
3. Draft. Turn that into rules. Positive rules for what to do, and a banned list for the tells you want killed on sight.
4. Test. Give the agent a real task and read the output cold.
5. Revise against the failure. Every time something reads wrong, add the rule that would have prevented it. This is the entire system. The first draft is a guess; the revisions are the asset.
6. Wire it in. Put the file at the right level (module 01), and name it in the project file so every session loads it without being asked.

How you know it worked

This is the question most people skip, and skipping it is why most voice prompts drift. Judging output by reading it is fine for one draft and useless as a system — you will accept things at 23:00 that you would reject at 09:00.

The check that actually works is a negative one. Rather than asking “does this sound like me?”, ask the agent to run its own draft against the banned list and the rules, and report which rules it applied and which it could not. A rule the agent cannot apply is a rule that is vague, and a vague rule is the source of the drift. Tighten it, and the file gets better rather than longer.

The payoff, and why it goes at the end

The voice system is what makes module 00 possible. A ten-stage pipeline that runs unattended produces titles, hooks, scripts and descriptions with nobody watching. Without a written voice spec, all of that arrives in the flat, hedged, faintly enthusiastic register that gives the game away instantly.

The voice file is not a nicety bolted onto the automation. It is the thing that makes unattended output publishable at all.

Seventeen days dark

On 8 August 2026 the pipeline rendered three Shorts. It then produced nothing until 25 August. Seventeen days, no output, no alarm.

Nothing had crashed. No credential had expired. Every call the pipeline made returned a success. It was authenticating perfectly — against the wrong account.

The cause was one number

Signing into a browser-based service, the account you get is determined by an index — a position in the list of accounts signed into that browser profile. That index had been established once, correctly, and written into a config as a constant.

The index is a property of the profile, not of the account. The same account sits at a different position in a different browser profile. When the value was carried from one profile into another it kept authenticating, kept succeeding, and kept operating on somebody else's workspace.

what was written      an index, copied from a working profile
what it means         "the Nth account signed into THIS browser profile"
what was assumed      "the account"
result                every call succeeds, against the wrong target, for 17 days

This is the same failure as a hardcoded deployment target, wearing different clothes. In the same ecosystem, four separate files still name a deployment target that turns out to be a testing environment, and one build document instructs promotion to a target that has been dead for months. Every one of those was correct the day it was written.

The fix, and the general form of it

The account resolver now throws rather than proceeding. It refuses on a wrong account, on an unexpected host, and on an authentication challenge. Before it asserted nothing; now it cannot continue while an assumption is unverified.

The rule that generalises, and the one worth taking away from this whole class:

Trace the failure yourself

The pipeline between 2026-08-08 and 2026-08-25HTTP responses?Authentication?Error logs?Rendered output?The config value?The fix?

What should have caught it

Not a better model, and not a more careful prompt. Three cheap things, none of which existed:

1. An assertion at the resolver. One check, comparing the resolved account against the expected one, refusing on mismatch. Now present.
2. An output counter outside the pipeline. Anything that knows how many artifacts should exist by Friday and says so when they do not. Still absent — it is the top backlog item, and it is the same gap that lets the manifest and the renders disagree today.
3. A note in a memory file. “This index is per-profile, never copy it.” One line, written the first time the value was set, would have made the second use impossible.

Seventeen days is what it costs to skip all three. The class ends with the projects that build them.

Build it yourself — seven projects

Each one is a working version of something in the system above, reduced to what a person can build alone against a target they already own. They ladder: project 1 is an evening, project 7 is a weekend and assumes the rest.

Project 1, in full

The first four steps of the first project, exactly as you would type them. The pattern holds for all seven: a prompt, a thing to look for, and a gate before moving on.

1.  Create the project folder and connect it as a workspace.

2.  Create AGENTS.md at the root: your name, your constraints, and an
    empty "Known traps" heading you will fill in as you go.

3.  Create the project file with your deploy target, API version, and
    file conventions.

4.  Prompt, verbatim:
    "Create a preflight script that runs 3 checks before deployment:
     [check 1 - your syntax trap], [check 2 - your naming convention],
     [check 3 - your config validity]. Exit 1 if any fail, 0 if all pass."

    ✓ you should see:  a script that exits non-zero on bad input
    ✗ if it warns and continues, it is a linter, not a gate — say so and
      ask for the exit code
    GATE: do not continue until you have run it against a deliberately
    broken file and watched it refuse.

Which project fixes which failure?

four files still carry the stale ID today

17 days, zero errors logged

stale on one surface for five releases

both defects still live

caught at audit, not by tooling

the reason unattended output is publishable

The gauntlet, one more time

Four claims an agent might hand you at the end of an unattended run. Run each through the five checks from module 02 and see where it stops.

Build your own work order

Fill in four fields. The output is a work-order template you can hand to any agent, in any tool, with the four parts in the order that makes them work.

What we would change tomorrow

1. An output counter outside the pipeline. The top backlog item. Something that knows how many artifacts should exist and says so when they do not. Its absence is why seventeen days passed unnoticed and why the manifest still disagrees with the renders.
2. Resolve every remaining hardcoded identifier. Four files still name a testing target as though it were production. Each was correct when written.
3. Comment-stripping as a shared function. Every text-matching gate should get its input through one place that removes documentation first, instead of each gate rediscovering the problem.
4. Write the traps down at the moment they bite. The known-traps section is the cheapest thing here and the most often skipped.