Field notes: how I run five side projects with Claude Code

Since late May I’ve shipped five personal projects: an interactive novel, an authoring tool for interactive fiction, a local-first second brain, a wedding app that became a product, and a skincare intelligence app. All of them were built with Claude Code, nights and weekends, next to a full-time job as a level designer. This series of field notes is about how.

The honest answer is not “AI writes the code and I watch.” It’s a process, and the process is the interesting part.

Spec first, then plan, then code

Every feature in every project starts the same way: a brainstorm that ends in a written design spec, then an implementation plan with checkbox tasks, then execution. The specs and plans are committed to each repo under docs/superpowers/. Jubileus has 64 of them. Loom has 33 pairs for a tool that took three days. It feels like ceremony until you watch an agent execute a plan task-by-task without wandering off, or until you come back two weeks later and can read exactly why a thing is shaped the way it is.

Skills are where the time goes back in

Each project grows its own slash commands. Perpetūra has an editorial council that reviews prose through five lenses. SkinAtlas has a resumable batch pipeline that can pick up a half-finished ingestion job after the session that started it is long gone. The pattern: any workflow I do twice gets written down as a skill, with its rules, its stop conditions, and the mistakes I don’t want repeated. The skill file becomes the institutional memory of a one-person team.

The same guardrails everywhere

All five repos call one shared GitHub Actions workflow from a repo named security-workflows: gitleaks for secrets, npm audit, semgrep. Set up once, reused everywhere. On top of that I run periodic audits where several read-only agents hunt for vulnerabilities in parallel and every finding gets verified by hand before it’s believed. They’ve caught real things: an SSRF hole, a rate-limit race, a command-gate bypass.

One hard boundary

Personal projects run on a personal git identity, a personal GitHub account, and a deny-guard baked into my tooling that refuses to touch anything work-related. That rule is enforced in code, not by discipline.

The rest of this series goes project by project: what each one is, what broke, and what I’d keep.