What to sayAsk for what you want, in plain words
The exact words don't matter. Your Claude reads your intent. These are the common requests.
Seeing where things stand
Connect my calendar.You do this one yourself, in the app: Settings → Account → Calendar, one button through Google's own permission page. You then tick which of your calendars appear — all of them, not just the primary — and set the life area each one falls under. Your meetings arrive as tasks on the Day. If the button says the instance isn't registered with Google yet, that one-time registration is your Claude's job; the deployment manual has it.
Set up a LifeOps for someone else.One LifeOps holds one person, so a second person means a second deployment. Your Claude follows the deployment procedure it keeps, and the new instance starts empty with its own address, its own login, and no access to yours.
My name is spelled wrong. / Change the email on my account.The name and email are backend account fields, set when it was provisioned, and the app has no screen for them. Your Claude corrects them on the backend and the app shows the fix on its next load.
Make this task repeat every Tuesday and Thursday.Your Claude sets the task to repeat, and a fresh one appears on each day you named. Daily, weekly, monthly on the same day of the month, and named weekdays like Tuesday and Thursday are the whole vocabulary today, so there is no every-other-week. The app itself has no control for this yet.
What changed recently?It reads the changelog and tells you in plain language.
What are you working on? What's on the board?It reads the board, the tracked list every task is on, and tells you what's claimed, what's queued, and what's waiting on you.
Is everything healthy?This reaches a toolchain check, which confirms the machine your Claude works on has every tool installed. It runs no tests and never opens your live app, so it answers a narrower question than it sounds like. Run the tests gets the suite, and open the live app and check it gets the page you would open yourself.
Directing the work
I want the app to do X.It files the idea as an issue on the board, in your words, where it stays until it ships.
Review the board and tell me the plan.It rereads every open issue, answers your comments, sets priorities, and presents the plan. Building waits for its own authorization, the phrase underneath.
Work through everything you can.Saying it authorizes the work: your Claude works the board in priority order and stops only when everything left is waiting on you or parked.
Your apps
Redeploy the web app. / It looks broken, roll it back.It deploys or reverts, then checks the result is live.
Build me a new version of the phone app.It produces an installable build through the store channels. That is the slow path: about fifteen minutes to build, then Apple’s processing, then you tapping Update in TestFlight.
Push today’s changes to my phone.Most changes are JavaScript, and those reach the app already on your phone in about a minute, with no build and no store. The app picks the update up the next time you open it, so the open that downloads it still shows the old version. Anything native still needs a full build, and no build on your phone can take an update until one carrying the updater ships. Releases and upgrades has the split.
I want to try the app on my phone right now.It runs the newest version straight to your phone, with nothing to install. Your phone has to reach your Claude's computer, so both need to be on the same network.
Change my web password.You can do this one yourself, in the app: Settings → Account → Change password. Asking your Claude works too. Either way it takes effect right away, and devices already signed in stay signed in.
Log every device out.It rotates the session secret on the backend, and every signed-in device everywhere is signed out at once.
Quality and checks
Run the tests. / Run the end-to-end tests against my real app.It runs the suite locally, and runs the full end-to-end tests against your live app when you ask.
Run a parity check.It compares the phone app and the web app screen by screen, following the written parity checklist, and reports any difference. One script does part of it by machine: the two apps deliberately keep fifteen files identical, among them the Day layout, the clock, the swipe rules and the API contract, and it fails if any pair has drifted. The rest of the checklist is read by hand.
Staying current
Is there a new version? What's in it?Your LifeOps is a fork of a maintained base, and every change to the base is in its plain-language changelog. Numbered releases are the designed way updates arrive. None has been cut yet.
Upgrade us to the newest version.It reads the notes, applies the update, re-runs every check, and can roll back cleanly. The design leaves your data untouched. The procedure is written and first runs once a release exists to pull.
Ending your day — the closeout
That's it for tonight. / Gotta run.You don't ask for cleanup. Say you're done in any words and the closeout runs: loose ends filed, the board tidied, checks green, background processes stopped, and a summary written. If a session ends abruptly, a closed laptop or a dropped connection, the next one finishes the closeout before doing anything else. The Working in Claude Code guide covers it.
When something's wrong
The app won't load. / I can't log in. / This looks wrong on my phone.Describe it as you would to a person. Your Claude investigates, fixes, tests, and tells you what happened. Every fix ships with a test that catches that bug, so it stays fixed.
I think I lost data.It investigates before changing anything, then checks the backend's nightly database backups, which cover the past several weeks, and the offsite copies when offsite storage is configured. It tells you exactly what it found. Restoring is hand work your Claude does on those backup files rather than a tool it runs.
Changing rulesAny rule here is yours to change
You change any behavior in this guide the same way: say what you want, your Claude writes it into the rulebook, and it holds in every future session, not just the chat you said it in.
Disable the automatic parity check.It edits the rulebook so the check stops, and records that you turned it off and when.
I want deploys to happen automatically when code changes.It changes the deploy policy, writes down the new one, and adjusts its own routine to match.
Stop asking me about X. / Always ask before Y.The rule changes in writing, so it holds everywhere.
When your Claude behaves in a way you don't like, tell it to change the rule instead of working around it.
Your loginYou choose the username and password that open the app
One account opens this deployment. It is stored on your own backend, scrambled so that even someone reading the database cannot recover it, and changing it takes effect straight away with nothing to redeploy.
You set it yourself, in the app. A fresh deployment's login page asks you to choose the username and password, and saving them claims the account. Changing the password later is in Settings › Account. Pick something long: twelve characters is the minimum, and a short phrase you can remember beats a short scramble you cannot.
- A new deployment has no login at all
- There is no way to sign in until you set one. A system holding your journal must never ship with a default password that someone else already knows.
- Changing it does not sign you out
- Sessions already open stay open. After a lost laptop or a shared computer, say "Log every device out". Your Claude rotates the session secret, and every device everywhere is signed out at once.
- Wrong guesses get blocked
- After five failures the login locks for fifteen minutes. If you lock yourself out, wait it out or ask your Claude to set a new password, which clears the lock.
A forgotten password takes one sentence to fix. There is no reset email and no recovery question — you are the only person here to send one to. Ask your Claude to set a new one. It reaches the backend directly and never needs the old password.