On September 24, 2026, I showed a small group of coworkers how I use Claude to assist in my blog post writing. On September 25, I decided to formalize what I had been doing ad hoc. And on September 30, I wrote this blog post. What's interesting to me is not that I wrote this post, or that I formalized how I work with Claude to do the writing. What I find most interesting is how this blog post was written. Read on to find out how.
Building 3pitor to formalize my writing process
3pitor (pronounced “three-pitor”) is, at its core, a markdown editor with AI integration. This isn’t very interesting, in my mind. There’s plenty of AI-enabled editors, like Plannotator, AFFiNE, and Yank Note, among many others. But I wanted to build this app for a few reasons, not the least of which was to hone some of my AI integration skills via an SDK that supports more than just one LLM.
What came out of this effort is an open source project I built in four working days — starting on September 25, then the 28th through the 30th, 2026 — almost entirely by typing short prompts into Claude Code.
The numbers still surprise me a little. 210 commits. 17 pull requests. Something like 134 prompts across 39 sessions. That's not a lot of typing for four days of work, and that's the real story, here: the method that got this built didn't live in clever prompts, a lot of hand-written code, or carefully following every line that Claude wrote for me. It lived in a small set of reusable skills, and in one job — reorganizing the codebase — that I ended up doing three times before I noticed I should turn it into a skill of its own.
The skills I used are from Han, a Claude Code plugin I built, here at Test Double. I didn't build these skills for this blog post, though. I use them for my day to day work both within Test Double and at clients. I also used them here, because Han’s entire existence is centered around building apps.
The loop, in short
Most features in 3pitor went through the same six steps, while building it out:
- Describe the feature to the planning skill, in plain language.
- Answer its numbered questions — usually just "recommended."
- Get back a written plan and a decision log.
- Run the test-first skill against that plan, on a new branch.
- Look at the result in the browser, ask for visual fixes.
- Say "commit and push."
Along the way, the skills sent out 131 specialist reviewer agents: architects, readability editors, a "junior developer" whose whole job is to poke holes in plans, a test engineer, a UX designer for UI work. I never talked to most of them directly. They report to the skill, the skill reports to me.
An important note about the work done here: Claude, not me, ran the overwhelming majority of the commits - something like 176 of them, roughly 90% of the non-merge commits in the repo - almost always triggered by that one phrase, "commit and push." Only 55 commits carry a "Co-Authored-By: Claude" trailer, so if you read the git log on its own, you'd think I wrote most of this by hand. I didn't.
Day one: picking a stack, and catching a mistake
The very first prompt of the project wasn't a feature request. It was a research question: how do you build an AI-backed markdown editor, and what library should handle the AI side? From there the early decisions came fast and one-line at a time: "ok, let's go with Hono" picked the web framework, and "i also want to use Vercel's ai-sdk rather than claude's sdk directly" to pick the AI library.
Later that same day I ran the architecture-analysis skill twice, once on the server and once on the UI, splitting both into per-feature files. That's the first time this particular job — reorganize the code — shows up. It won't be the last.
A few hours in, I noticed something off: make build was copying an entire claude binary into the build output. I asked why, and that question turned into a plan to call the Anthropic API directly instead of shelling out to the CLI. The claude dependency came out of the build.
There was a smaller catch too — a missing API key was producing a wall of stack trace instead of a clear message, so I asked for a plain explanation in its place.
And somewhere in there, the project got its name. A brainstorm for "a list of random star wars characters" turned into "riff on c3po, blog, editor," and "aiditor" became 3pitor before the day was out.
Days two and three: the loop, running
This is where the six-step loop above stopped being an abstraction and became the actual rhythm of the work. A feature started as a paragraph of plain intent — one began, "when i have a file open, and i send a request to the AI, the AI should automatically be told which file i'm currently working in" — and the planning skill came back with a few numbered questions. My answers were usually short: "recommended," "go with recommendation," "looks good." Sometimes the answer carried the real decision, like when I told it to keep a change's scope as small and tight as possible and specified exactly what should and shouldn't move.
Not every answer was "go ahead," though. Scope got cut, too: "drop commands. the entire point of this project is to be a blog post editor. we're not writing code with it."
The second time I reorganized the code, I didn't use a skill at all. I wrote one long instruction — what Claude Code calls a /goal, an instruction it keeps working against until the goal is met — telling it to reorganize the code by package, feature, and component. I ended the instruction with "i'll be stepping away from my computer, so i need you to make the decisions around this and justify every decision you made. keep a running log of all changes," and then I stepped away. That run became pull request 5. Same job as day one's two skill runs, done a completely different way: not a tool I invoked, but an instruction I trusted to run unattended.
September 29 had its own rhythm, mostly visual. I'd look at the running app and send feedback like "works great, looks terrible," with screenshots attached, and ask for it to look like the other buttons and menus. Icons, colors, alignment — that kind of feedback, over and over, as I used the thing I was building.
Things went wrong that day too. A copied-in research skill didn't work well on open-ended topics, and rather than fix it properly I told Claude, "if the current working solution is 'good enough' to generally limit things, let's just roll with that" — a real trade-off, not a triumph. Two smaller bugs came with it: highlights in the editor vanished entirely while Claude was mid-reply to an open question, and later I asked it to "fix the typescript errors" after a change broke the build.
Day four: the third time, and the pattern finally clicks
On the last day, I took the exact same long /goal instruction from day two and handed it to a different skill — the one that writes skills — and asked for "a skill called 'update-code-structure' within this repository." That's the third time I'd done this job: once by hand with a skill, once with a one-off instruction, and now as something permanent.
The skill that came out isn't a copy of the instruction. It runs the same four skills in sequence: analysis, planning, refactor, test-first — and commits as it goes, logging every decision without asking me anything. But it dropped something the original instruction had: branching, pushing, and opening a pull request. That came out of a short exchange about git safety, where I said, "good point about git commits and rollbacks. have the skill run git commits as it goes, directly on the current branch." The skill-writing skill made that call, and it stuck.
Then I ran it the same way I'd run the /goal instruction two days earlier — "on a new branch, and open a draft PR when you're done" — which meant giving my own instruction back to a skill that, by default, no longer did that. The run's own decision log records it: taking my instruction over the skill's own rule. That run became pull request 16.
The same day had another example of steering the process after it was built, smaller but real. I partly reversed the day-one decision to drop the claude CLI, building an adapter that can talk to Claude through either the API or the installed CLI on a subscription. Partway through planning it, I added two requirements myself: a shared interface over both modes, and a type-check step in make test. And, with the same skills I had been using, Claude implemented the changes and I had a working blog post writing app.
The takeaway
The short prompts worked because the skills were carrying the method: the numbered planning questions, the reviewer agents, the test-first discipline, the habit of committing as you go. That's not an argument for terse prompting on its own. Without the skills behind them, "go with recommended" doesn't mean anything.
Some of this process was more than a small change needed — not every feature justified a full plan, a decision log, and a squad of reviewer agents. I don't have a record of how closely I read the actual diffs versus judging the app by using it in the browser, and I'd rather say that plainly than imply I reviewed every line.
None of that changes what the loop was for, though: not speed, and not a clever prompt. It was a skill — and I only noticed that because I did the same job three times before I made it explicit. The next time you catch yourself retyping the same long instruction to an agent, that's the tell. Turn it into a skill, run it, and then — like I did with that one line about commits and rollbacks — keep improving it once it exists.
One last loop worth closing
“That’s my secret, Cap. I’m writing in 3pitor itself.” — the Credible Hulk (or something like that)
Everything about this post, from the analysis of my Claude sessions, to the outline to make sure this post is what I want, the first draft, and almost all of the editing after that, was done in 3pitor directly.
The research it's built on came from 3pitor's own research skill, reading the very session history it describes. I had Claude write the outline in 3pitor, using a simple “write an outline that …” prompt. I had Claude draft the post in 3pitor, with another prompt. And I ran this post through 3pitor's proofread and collaborative-editing skills, answering the same numbered questions and reviewing the same highlighted passages the app hands any writer.
Said another way: the app I just built wrote the report about how it was built, then helped me write the post about that report.
River Lynn Bailey is a Senior Software Consultant at Test Double, and has experience in AI coding tools and delivery.
