Shipping a devblog with Claude Code and Linear

Using Linear for a personal project sounds like overkill. It probably is, slightly — but the discipline it imposes turns out to be what makes the rest of the workflow actually work.

Here's how this site gets built.

The Linear forcing function

Before I open an editor or start a Claude session, I write the issue. That sounds simple, but the act of writing it does real work: it converts "add search" into "full-text search over post content, scoped to title and excerpt, no backend — client-side with Fuse.js, accessible from the nav." Thirty seconds of writing turns an ambiguous impulse into a bounded task.

The other thing Linear gives me is real closure. When an issue moves to Done, it's done. Not "I think I did this," not "it's in a branch somewhere." There's a milestone (Site 1.0), there's a backlog, and there's a clean before-and-after when something ships.

Superpowers skills as guardrails

Claude Code has a plugin system where skills — structured guides — load into the agent's context when a task matches their trigger. The ones that actually change my workflow are the discipline skills in the superpowers plugin.

Before any feature, the brainstorming skill fires: what's the edge case, what does the empty state look like, how does this interact with mobile layout, what are we explicitly not building. A few minutes of that before a single line of code tends to surface the thing that would have caused a rewrite at hour three.

The verification skill is the one I rely on most. Before Claude reports anything as done, it has to run actual checks — typecheck, lint, load the dev server, exercise the feature in the browser. Not "I believe this should work." Evidence first. The skill makes this non-negotiable, which is necessary because the agent's default is to say "done" when it thinks it's done, not when you can confirm it works.

Worktrees for parallel features

Features that don't touch each other — a new series page, an RSS fix, a sidebar widget — are candidates for parallel agents. Claude Code supports spawning agents in isolated git worktrees: separate directories, separate branches, same repo. They don't conflict because they're not sharing the working tree.

In practice: I describe two features in the same session, Claude dispatches them as separate worktree agents, I do something else. Both return with branches and a summary. The sequential version of this is finish one, wait, start the next. With worktrees it's closer to how a small team would actually work.

The constraint is that independent really has to mean independent — touching the same component or globals in parallel creates a merge that's more work than the sequential version. I've learned to scope issues with this in mind.

The loop

1. Write the Linear issue — scope it, not just name it
2. Reference the issue ID in Claude (Linear: STO-N at the start of the session)
3. Brainstorming skill runs; we agree on approach and what we're not doing
4. Claude enters a worktree and builds
5. Verification skill runs before Claude calls it done
6. PR review, merge, issue → Done

This post exists because of STO-10. The series landing page that will eventually host it is probably STO-11. The workflow is self-documenting.

Nothing here is novel tooling. The skills create structure where conversations would otherwise drift. Linear creates closure where a notes app stays perpetually open. The worktrees create independence where a shared branch would serialize everything. Together they give a one-person project a rhythm instead of a pile of intentions.