Owner's guide
Building LifeOps with Claude Code
Your app gets built through a process you can watch. It runs in three parts: a board of issues that records the work, hands-on sessions in Claude Code that do it, and releases that ship it to your instance. You run none of it. Knowing how it works lets you trust it, and catch it when something goes wrong.
You build by telling your Claude what you want
You start a session and say what you want, in plain words. Your Claude does the rest: it picks up the next piece of work, writes the code and the tests, and ships it.
Work gets tracked, done, then shipped
The build runs in three parts, in that order. Open the one that matches your question. Each page stands on its own.
1 · GitHub issue process
How work is tracked: issues and the umbrella issues that group them, the board where the assignee is the state, dependencies, and how you plan it or execute it.
Open →2 · Working in Claude Code
What a hands-on session looks like: how it orients at the start, the commands and gates it runs, and how it closes out.
Open →3 · Releases and upgrades
How finished work ships: a version gets cut, and your fork pulls it in without losing your own changes or your data.
Open →All three run through the board: a session moves work across it, and a release ships what the session finished. Read the issue process first: the board is where you see the whole system. The other two pages are for checking the work, whenever you want.
A skipped rule becomes a gate
When a written rule gets skipped, it becomes a gate instead of a sterner reminder. A reminder needs someone to remember. A gate refuses the mistake mechanically. Each failure becomes a check, the same way a bug fix ships with a test that catches it.
This is deliberate. It makes the system safe to hand to a less-experienced Claude later. The reliability is in the tooling, not in how sharp any one session is.
Two rules still run on discipline alone. A push lands even while the build is red, so your Claude has to watch each run and fix or revert before pushing again. And the look at a changed page happens after the deploy, on the live site, with the deploy script printing the command and nothing checking that anyone ran it. The guide voice check is mechanical, but only on the ship path, so a plain push walks past it. The gates in Working in Claude Code say where each check runs today.
The work stays where you can check it
In one line
Everything important is on the board, in the code, and in the record, where you can check it.
Your Claude does the work, and you can always see what it did.