Workflow
Updated August 2026
Not long ago, Figma was my primary work surface. Today, most of my hands-on work happens through AI coding agents, with Lovable increasingly becoming part of the process too. Yes, we’re using Lovable to build and improve itself.
Trippy, I know.
The tools matter less than the framework around them: what agents can do, what they need to prove, and what remains my responsibility. That framework lives in a private Git repo shared by all my agents. This page explains how it all works.
tldr;
Every feature gets its own worktree, agent session, and PR. The lifecycle is encoded in versioned skills with explicit gates: adversarial reviews surround every build, a second model reviews the work before a PR opens, and the two decisions that matter most, local review and merge, remain mine.
Claude Code and Codex are the two harnesses. cmux is the console. Paper is the design canvas, and Playwright captures the evidence. Graphite manages stacked PRs, Linear handles tracking, and a Nix devenv runs the local services.
The console
I work in parallel. One repo checkout stays read-only, running shared local services and hosting planning sessions. Every feature gets its own Git worktree, branch, agent session, and, eventually, pull request.
One feature equals one worktree equals one PR. The main checkout reads, while worktrees write. This is enforced mechanically, not from memory. Guard hooks block edits and commits in the main checkout and direct the agent back to /start.
cmux is the console: a sidebar group for each workstream and a row for every running session. I can brief an agent, step away, and return when a decision is ready. Each worktree runs a thin service slice built on shared machinery that starts once, and every branch gets a readable local URL. Reviewing a change is as simple as opening a page.
That 15-second review loop is what makes the workflow viable. More on that below.
The lifecycle
The feature lifecycle is encoded as skills: versioned prompt programmes with explicit gates, not vibes. The spine:
Start
/start bootstraps a worktree from trunk, reads the workstream’s memory log, and captures “before” screenshots of the affected UI before the first edit. A fresh worktree still serves trunk, so this is the actual before state. Before and after screenshots are eventually added to the PR, which makes capturing them at this stage important.
Tiny visual papercuts can take a shorter path, but only through an explicit gate that allows them to skip the middle phases.
/start --from riffs on an existing branch instead of trunk: it picks up a colleague’s branch or PR and stacks a design pass on top. Committing directly to their branch happens only by invitation.
Explore
When the direction is unresolved, three tools are available, chosen according to the question:
/grill-with-docs is an interview that stress-tests a plan against the project’s domain language and recorded decisions. Terminology is settled in a glossary, while hard-to-reverse decisions become one-paragraph records. Credit to Matt Pocock.
/paper-prototype produces two or three structurally distinct directions on a Paper canvas. The variants must disagree about structure, hierarchy, or flow.
/prototype trades fidelity for speed: five throwaway, single-file HTML implementations in a side-by-side gallery. It identifies a quiet favourite but never chooses a winner.
Build
/build is implementation bracketed by two reviews. An adversarial pre-build review must return Go before any code is written. Blockers are routed back to the stage that owns them.
A read-only post-build review then runs the checks and opens the preview in a real browser. Any check that cannot run is recorded as “not run”, never assumed to have passed.
When the context runs long, /handoff compacts the unfinished work into a document that any future session can resume from. Every decision is recorded, so speculation cannot masquerade as something settled.
My review
This is the first of two human gates. I inspect the change running locally before a PR exists.
Ship
/ship verifies that the reviewed state has not changed, runs the quality and policy checks, and launches an adversarial review by the other model. Codex reviews Claude’s work, or vice versa, while remaining blind to the session’s reasoning. A reviewer who has been told why an approach is right cannot properly question whether it is.
Every finding must be fixed or rebutted with evidence before the PR opens. Before and after screenshots at 2x are included with the PR, and a babysitter loop drives it through CI and review comments.
The merge button is the second human gate, and it is always mine.
Wrap up
/wrapup runs after the merge. It verifies that the deployment rolled out, tears down the worktree, and retros the workstream’s log.
The meta-layer
All of this lives in one private Git repo: a single, harness-neutral instruction file that serves as both Claude Code’s and Codex’s global configuration through symlinks, alongside 20 shared skills and a handful of scripts.
A sync script generates the host-specific projections and runs automatically at the start and end of every session. A doctor script enforces parity after configuration changes and fails loudly when it detects drift. Genuine host differences are quarantined in a single directory.
The point is that the workflow itself is under version control. When a retro promotes a lesson, it becomes a diff to a skill, not a note I hope to remember.
What stays mine
Design judgement, taste, and the two human gates remain mine. Agents propose, verify, and prove. They never reduce a set of options to a single winner, approve their own work, or merge anything.
The retro loop follows the same discipline: a correction becomes a standing rule when it recurs, not simply because I said it once.