last verified · 2026-07-16
The CLI
Lumis has two layers of commands, and the split is deliberate.
lumis <verb>— the deterministic layer. Plain scripts: same input, same output, no AI involved. Safe to run anytime, from any folder./lumis:<command>— the judgment layer. These run inside an agent session: the agent reads the current state, makes a decision under the platform’s rules, and finishes by recording what it did.
Rule of thumb: if it needs to think, it’s a slash command. If it just needs to run, it’s a verb.
Deterministic verbs
lumis status
lumis status <project>project: <project>
open: 12 in progress: 3 in review: 2 done (30d): 8One line, current funnel, no interpretation added.
| Command | What it does |
|---|---|
lumis install [--check|--force] | bind this machine to the platform (see Set up a machine) |
lumis uninstall [--check|--purge] | remove what was installed on this machine |
lumis doctor [--fix] | what this machine has connected — repos, commands, agent CLIs — and repair what it safely can |
lumis whereami | which project the current folder belongs to |
lumis check | run the platform’s own consistency checks |
lumis lint | check the platform’s rules and records for consistency issues |
lumis metrics <project> | a KPI snapshot: tickets, defects, code, cost |
lumis registry | print every project this platform knows about |
lumis status <project> | a one-line ticket funnel for a project |
Judgment commands
Installed once when you set up your machine, so they work from any repository — each command resolves the right platform and project on its own.
/lumis:nextPicked <PREFIX>-142 "add plus-tag routing to inbox intake" (Ready for Build).
Reading spec... running... 4 files changed, tests passing.
Stopped: no gate reached. Ticket moved to In Review.
Event recorded.| Command | Use it to… |
|---|---|
/lumis:status | get the current state of a project, or the whole platform |
/lumis:plan <topic> | turn an idea into a spec and a set of tickets |
/lumis:next | run the next ready ticket through one full cycle |
/lumis:auto | run several cycles unattended — still stops at every gate |
/lumis:intake | triage incoming requests into tickets or answers |
/lumis:bug | turn a bug report into a reproduced, ticketed defect |
/lumis:ask | ask a question with the full history of the project behind the answer |
/lumis:decide | record a decision, with the options considered and the ruling |
/lumis:onboard | connect a new or existing project (see Add a project) |
/lumis:resume | pick up exactly where the last session left off |
/lumis:close | end a session cleanly: handoff notes, metrics, final commit |
/lumis:help | explain any command or rule |
Smart resolution
Both layers are forgiving about arguments:
- Where you are counts. Run
lumis status(or/lumis:plan,/lumis:next, …) from inside a project’s repository and it already knows which project you mean. - Prefixes work.
lumis status woresolves to the one project starting with “wo” — if more than one matches, you get a list instead of a guess. - Tab-completion for verbs and project names is installed automatically when you set up your machine.
The contract every command honors
Whichever layer it runs in, every command follows the same rules:
- Pull first, announce presence. A session registers itself before it starts, so two people — or two agents — working at once can see each other.
- Path-scoped writes. Each ticket declares which paths it’s allowed to touch; a command can’t write outside that scope.
- No event, no cycle. Every run ends with a recorded event — what changed, which model, tokens, cost — so there’s always a receipt. This is what the loop is built on.
- Gates always stop. Deploys, spend, secrets, destructive changes, and locked decisions wait for a person, every time — even inside an unattended run.