Part 5 of 6 The command line
Your terminal here, your work there
By the end of this chapter, Keanu has the team's work and his own list in one terminal, each item addressed by where it lives, and he can say where a bare number points.
The browser is one way in; this is the other. Install Subroutine on your own machine, point it at the instance somebody else runs, and everything you already know reaches both.
The work so far
Laurence's instance is serving at https://tasks.example.com, with a workspace called metacortex, and Keanu has an account on it with a credential for the command line, as Signed in, from a browser or a phone made him:
uv tool install subroutine
subroutine init --workspace metacortex --instance-name MetaCortex
printf 'public_url = "https://tasks.example.com"\n' >> ~/.config/subroutine/config.tomlsubroutine serve
subroutine add "Fix the deploy script"
subroutine user create keanu --name "Keanu Reeves" --terminal | tee /tmp/for-keanu
A list of your own first
Keanu's desktop has no Subroutine on it. Install it, and make the list this machine keeps for its own owner, exactly as Install it, and tell your agent did:
uv tool install subroutine
subroutine init
subroutine add "Sparring in the dojo with Laurence"
That task is nobody else's business, and it never leaves this machine.
Add the instance as a connection
A connection is another instance this machine can reach. Adding one needs the address and the token you were given:
token=$(grep -o 'sr_[A-Za-z0-9_-]*' /tmp/for-keanu | tail -1)
echo "$token" | subroutine connections add work --url https://tasks.example.com
subroutine connections add asks for the token, reaches the instance with it, and writes nothing until both work. Type or paste it at that prompt when you do this yourself; here it comes out of the message Laurence sent.
The name it reports back is the one that instance knows you by. A token carries no clue about whose it is, so that line is the only thing that confirms you pasted the one you meant to.
work is your name for it, not theirs. It becomes the first part of every address that instance's items print as, and two people reaching one server may call it different things.
Both lists, one terminal
subroutine list
Your own work and the team's are listed together, and the address says which is which. A plain #1 is this machine's; work/metacortex/#1 is the instance's, by connection, then workspace, then number.
Reads always span everything you can reach. There is no mode to be in and nothing to switch before looking.
Where a bare number points, and where new work goes
Reading needs no choice. Writing does: a bare #1 has to mean one of them, and a new task has to land somewhere. Until you say otherwise both are this machine's own list, which is what the line under work above was telling you.
subroutine use work/metacortex
subroutine use moves both at once, and moves nothing else. New work now goes to the team's instance:
subroutine add "Write the release notes"
What you can see never changes with it. Reads still span everything you can reach, which is what makes it safe to set and leave.
subroutine use --here --project <key> writes the choice into a .subroutine file in the directory you are in, rather than setting it for the whole machine. That is what a repository checkout wants, because it answers which project is this work for everything started from there, including an agent, which cannot be asked.
What this machine reaches
subroutine connections
subroutine connections lists every instance this machine reaches and, for each, which of the four places its token came from. No token is ever printed. Reach for it when a command acts as somebody you did not expect: knowing which source won is usually the whole answer.
subroutine doctor is its companion, and says what this installation is and whether it holds together.
A machine with nothing of its own
If you never run init, this all still works and looks slightly different. Somebody given a token who installs Subroutine and adds a connection has exactly one place for work to go, so there is nothing to tell apart: the list has no Local heading and no prefixes, and new work goes to the instance because there is nowhere else. connections add says so at the time.
That is the right shape for a work machine that holds no personal list, and subroutine use moves writes either way if you change your mind.