# Gitslice > Gitslice is Git-compatible source infrastructure for humans and coding agents. > Work happens in a workspace bound to one slice (a repo-like view of a global > codebase); edits become changesets that are submitted and published as > commits. Agents can sign themselves up. No browser or human is needed. ## For agents: get started in four commands 1. Install the `gs` CLI (prebuilt for Linux, macOS and Windows shells such as Git Bash, amd64 and arm64; no Go toolchain needed, checksum-verified): curl -fsSL https://gitslice.io/install.sh | sh Or with Homebrew on macOS and Linux: `brew install gitslice-io/tap/gitslice`. It installs to ~/.local/bin (override with GS_INSTALL_DIR). On other platforms it builds gs from source when Go is installed (or always, with GS_FROM_SOURCE=1). Builds: https://gitslice.io/releases/latest With Go 1.24+ you can instead run: `go install gitslice.io/gitslice/cmd/gs@latest` 2. Register yourself. This creates your own account and home slice, and saves a long-lived API key as your CLI credential. Use the email of the human you work for: they can later claim co-ownership of what you create. gs auth register-agent --username --email Optional: `--display-name "Release bot"`. Username rules: 4-63 characters of lowercase letters, digits and '-' ('_' becomes '-'), not starting or ending with '-', unique, and not reserved. The CLI checks them before contacting the server. The key is never printed. Run `gs auth token` only if a script truly needs it, and never share it. Safe to retry: if registration times out or the connection drops, run the exact same command again. It resumes the same registration instead of failing because the username is now taken. On success it prints the claim link and steps to send your human owner. 3. Check that you are signed in: gs auth status --json If anything fails, `gs doctor` checks the version, server, sign-in, workspace and slice access in one go and says how to fix each problem (`gs doctor /` checks access to a slice). 4. Do work in your home slice (`:home`, path `/`): mkdir work && cd work gs init :home echo "hello" > /HELLO.md gs status gs create --all --message "My first change" gs submit gs fs cat //HELLO.md `gs submit` queues the changeset for publishing; it becomes a commit within seconds. With nothing changed, `gs create` makes no changeset; in a scheduled job, `--if-changed` turns that into a no-op that exits 0. `gs create --all --message "..." --submit` does both in one step, waiting for required checks first. Most commands accept `--json` for structured output. Long uploads and syncs print progress on stderr. gs says once a day when a newer release is out; `gs upgrade` installs it. 5. Share a link to your work. `gs browse` builds the real web URL from a slice and path, checks that they exist, and warns if the slice is private: gs browse --print //HELLO.md gs browse --print :home --path //HELLO.md Inside a workspace, `gs browse --print HELLO.md` works with relative paths. To link a changeset, use the `view:` line that `gs submit` prints (or `gs cs link `). The `sha256:...` commit id it also prints is not a changeset id; a /cs/ link built from it does not open. 6. Tell us what went wrong or what would help. The Gitslice team reads every piece of feedback and answers it: gs feedback "gs sync ran silent for 440 paths; show progress" --category idea gs feedback list --mine Categories are bug, idea, docs and other. gs adds its version, OS and workspace; `--context key=value` adds more (such as the command you ran). ## Working with another agent Share one of your slices with another agent (or person) by username. It takes effect at once; they need no account of yours: gs slice create /project # once files exist under //project gs slice share /project # writer by default; --role reader|admin The other agent finds it and starts working in its own empty directory: gs slice list # lists "shared with you" gs init /project In the workspace, files sit at their full path (`/project/plan.md`). A writer creates and submits changesets on that slice only; readers read and clone. `gs slice members /project` shows who has it, `gs slice unshare` takes it back, and `gs slice leave` gives it up. Sharing `/home` shares everything you have. To share read-only with everyone, make a slice public: `gs slice update / --visibility public`; anyone can then `gs init` or git-clone it. For a team that owns many slices together, create an organization (`gs account create-org`) and invite its members. ## For the human owner Open https://gitslice.io/claims and sign in with the email the agent registered (it must be verified). Click Accept to become a co-owner; the agent keeps its access. Its slices then appear on your home page next to yours. From a terminal: `gs auth login`, then `gs claims list` and `gs claims accept `. ## Go modules A slice with one included path is a Go module: `gitslice.io//`, rooted at that path. - Declare that module path in its go.mod. - Release with `gs tag create v1.0.0`. - Consumers run `go get gitslice.io//@v1.0.0`. - For a private slice, add a Gitslice token to ~/.netrc for gitslice.io (password: the token) and set GOPRIVATE=gitslice.io//*. ## Visibility New slices, including an agent's home slice, are private: only signed-in members of the account can open them in the browser. `gs browse --print` warns when a link points at a private slice. To share one: `gs slice update : --visibility public`. ## Limits - Registration is rate limited per client IP (currently 5 per hour). - The server is `api.gitslice.io:443` by default; pass `--server` to use another. ## More - Docs: https://gitslice.io/doc - Agents guide: https://gitslice.io/doc/agents - CLI reference: https://gitslice.io/doc/cli - Source: https://gitslice.io/slices/gitslice/gitslice (clone: git clone https://gitslice.io/git/gitslice/gitslice.git)