My Technical Writing System, Eight Months Later

Years ago, I launched my portfolio on WordPress with a set of knowledge base articles I wrote by hand to showcase my technical writing skills. Later I moved off WordPress and dove into docs as code. These days, I haven't written a first draft of documentation at work in a long time. Instead, I build, maintain, and run the system that does.

In My First Week with Claude Code, I said I'd build that system brick by brick.

How the System Fits Together

Claude Code is the harness I use today, the infrastructure that connects the model to my files and other tools. Everything lives in one local repository:

• A CLAUDE.md file that tells each session how we work
• Agent skills and scripts for the repeatable tasks
• Context files: A local Markdown copy of our knowledge base articles, my style guide, and audience personas (which vertical or internal stakeholders we're writing for, and what they do all day)
• MCP connections to the tools around it

Not every prompt became a skill. Some are still standalone prompts that skills invoke, with a lot of stitching between the pieces.

A session starts when I speak a prompt into speech-to-text, something like "let's work on XYZ," with the context already preloaded. My mechanical keyboard has taken this personally. Sometimes the work is an issue from our issue tracker, sometimes a project already underway, and for a large new project I seed the session with more context. Release notes are built from the ticket list in the audience persona's voice, and they're fully automated now.

The details belong to my employer, so I'm sharing the shape of the workflow and keeping the specifics out.

Many Arms, One Writer

I keep several sessions open at once and guide each one like a junior technical writer. I give feedback in one window, jump to the next, and circle back when the first one finishes. It reminds me of Doc Ock with his mechanical arms, or Kamaji in Spirited Away, with all those arms working on different jobs at once. Doc Ock needed an inhibitor chip to keep his arms in line. I have a style guide.

The system speeds up every stage of the documentation development life cycle, from information gathering to first draft to editorial review to handoff for SME review. The payoff is a shorter time to SME handoff and releases covered on time, even when releases are frequent. Add several sessions running at once, and I can handle five or more projects on a good day. That's a small team's throughput from a solo writer. The tradeoff is focus, though a big project that has cooked enough lets me juggle more documents at once. I also pick the model for the job, using a more capable one for work that needs more context and careful planning and a lighter one for routine tasks.

What I Check Every Time

The first draft isn't ready for SME review. My review has three parts:

• Style: Proofreading agents check the draft against my style guide.
• Duplication: Nothing should say the same thing twice.
• Accuracy: Every claim maps one to one to a source, usually a ticket or another source of truth. If I ask "where did you source that?" and there's no answer, the claim comes out.

The accuracy check is my guard against the "docs theatre" Fabrizio Ferri Benedetti warns about, which I wrote about in The Soul of the Technical Writer.

Where the Human Still Shows Up

Specs and product requirements only tell you so much. Once I have a build, I walk through the feature as a real user with the testing checklist, narrating each action and sharing UI screenshots. When the LLM is missing context, it fills the gap with something plausible that isn't always correct. My narration closes those gaps.

Walking through a feature in an actual user's shoes gives me a perspective that's easy to miss. It sometimes turns up edge cases on paths nobody had thought to try, and I'm usually the one clicking the weird thing. Then I mark up the first draft with a figurative red pen. Editing turned out to be a different skill than drafting, and I think that's where this role is heading.

Improving the System

While I'm directing that small team, I'm also improving the tooling. When I spot a pattern or a mistake, I talk it through with the model: what went wrong, what did it learn, and how do we do better on the next run. The fix goes where the weakness was found, whether that's an agent, CLAUDE.md, a skill, or a script.

Harnesses and models will keep changing, and the system will change with them. I'll be here with my red pen and my many arms 🐙