Workflow
Updated August 2026
Whenever possible, I try to work directly in Lovable. Yes, we’re increasingly using Lovable to build and improve itself.
Trippy, I know.
Most of my hands-on work happens through external AI coding agents. 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 works.
The desk
I work in parallel. One repo checkout stays read-only, running the 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.
cmux is the console: a sidebar group for each workstream and a row for every running session. That means I can brief an agent, step away, and come back to a decision. Each worktree runs a thin service slice that relies on shared machinery started once, and every branch gets a readable local URL, so reviewing a change is as simple as opening a page. That 15-second review loop is load-bearing. More on that below.
The lifecycle
The feature lifecycle is encoded as skills: versioned prompt programs 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 any edits are made. Before and after shots are eventually added to the PR, so it’s important to capture this now. Tiny visual papercuts can take a shorter path, but only through an explicit gate that allows them to skip the middle phases entirely.
Explore
When the direction is unresolved, two 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 decision records. Credit to Matt Pocock!
- /paper-prototype produces three to five structurally distinct directions on a Paper canvas. The variants must disagree about structure, hierarchy, or flow.
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 drives the preview in a real browser. Any check that could not run is recorded as “not run”, never inferred 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 documented, 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 re-verifies the reviewed state hasn’t drifted, runs the quality and policy checks, and launches an adversarial review by the other model. Codex reviews Claude’s work, or vice versa, deliberately kept 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 actually 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 config via symlinks, alongside 16 shared skills and a handful of scripts. A sync script generates the host-specific projections, while a doctor script enforces parity and fails loudly when it detects drift. Both run automatically at the start and end of each session. 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 only when it recurs, not simply because I said it once.
The stack
Claude Code and Codex are the two harnesses. cmux is the desk. Paper is the design canvas, Retune handles in-browser visual tweaks and translates them back to source without rounding my values, and Playwright captures the evidence. Graphite manages stacked PRs, Linear handles tracking, and a Nix devenv runs the local services.
The tools will change. The framework is what endures.