Part 5 of 6 The command line
Everything is reachable from here
By the end of this chapter you can find the command you want without looking anything up, because Subroutine will tell you, and you will know which shape of command you are looking for.
Every operation is reachable from the command line. Not most, and not the common ones: the browser and your agent's tools are clients of the same HTTP API this is a client of, so anything either of them can do, you can do here. That matters for the times a graphical page is the wrong tool: a script, a machine with no browser, a pipeline, or simply preferring to type.
The work so far
The commands of Install it, and tell your agent: Subroutine installed and a project to put work in.
uv tool install subroutine
subroutine init
subroutine project create web "Website rebuild"
Two names for one command
subroutine --version
subr is the same command with less typing, and this guide writes subroutine throughout because it reads better on a page. Use whichever you like.
Typed with nothing after it, you get the agenda rather than a help screen, because that is the thing you most often want:
subr
Ask the program, not the internet
Subroutine explains itself, and those explanations come from the copy you have installed rather than from a page somebody wrote once:
subroutine explain
subroutine explain with a topic prints that topic. The two worth reading on your first day are the capture line, which is how a task is written as a sentence, and dates:
subroutine explain capture
Because they are built into the program, they describe what your copy actually accepts. A page on a website can go stale between releases; this cannot.
The shape of it
Commands come in two shapes, and knowing which you are looking for is most of finding it.
The ones you use constantly are at the top level, with no group in front of them: add, list, show, done, agenda, claim, comment, link. These are the verbs of working, and they take an item's number.
Everything else is under a group named after the thing it acts on: project, agent, document, login, config, connections, db, instance, calendar. If you are looking for something that acts on a kind of thing rather than on a task, the group is its name.
subroutine --help
So a command you have not met is usually a guess away: something about agents is subroutine agent …, something about the database is subroutine db …. And if the guess is wrong, --help after any group lists what is actually there:
subroutine project --help
When something does not work
One command answers is this installation healthy, and where does it keep things:
subroutine doctor
subroutine doctor says where this installation keeps each of its parts and whether anything needs attention. When a page here says something should work and it does not, run this first.
Your work is the file subroutine.db in the folder data names, and the folders are the ones your computer uses for such things. local names the account your commands act as. exposure says whether anything outside this computer can reach it, and until you serve it deliberately, nothing can.
Who you are acting as
Every command carries a name, and it is worth knowing which:
subroutine whoami
This matters more than it looks. The same command run by your coding agent's shell can act as a different account, which is the point of giving an agent one. If work is appearing under your name that you did not do, this is the command that shows you why.
The reference, for when you want the exhaustive answer
This chapter teaches the shape. It deliberately does not list the options of anything, because a guide that lists options is a worse copy of a reference that is generated from the code and cannot be wrong.
The command line reference has every command, every group and every option, generated by running the release this page was checked against. When you know what you want and need the exact flag, that is where it is.
The next chapter is the command line doing the thing most people reach for first: keeping your own work, rather than a project's.