rigsmith

A Go monorepo housing a family of convention-first, zero-runtime-dependency CLI tools and the shared engine they're built on:

One Go module — github.com/rigsmith/rigsmith — with the binaries under cmd/ and the shared engine under core/:

Path	Binary	What it is
core/	—	github.com/rigsmith/rigsmith/core — the shared engine: semver, changeset parsing, the release planner (cascade + grouping), the plugin contract, the built-in ecosystem adapters (.NET, Node, Go, Rust), and pathmap (cross-OS path resolution). No external dependencies.
cmd/rig/	rig	The convention-first dev launcher (run/build/test/format across .NET, Node, Go, Rust), plus parallel worktrees and stackspaces (rig stack) — your app and the repos you have forked, fused into one history. Export a portable seed with rig stack seed ../rigstack-acme. Successor to the .NET/Node rig.
cmd/changerig/	changerig	The lean changeset tool: the lifecycle (init → add → status → version) isolated from release orchestration. Its commands package (under internal/changerig) is reused by shiprig. Aliased changeset.
cmd/shiprig/	shiprig	The release front door: everything changeRig does, plus publish/tag/pre orchestration. Successor to net-changesets.
cmd/clauderig/	clauderig	Sync your Claude Code setup (config, skills, session history) across machines via a private git repo, with cross-OS path correction, complete staged-text secret scanning, Git byte preservation, and transcript chunking (on for new configurations). Restore checks that recreated memory links resolve inside the selected folder and skips links pointing outside it. See docs/CLAUDERIG-DESIGN.md.
cmd/codexrig/	codexrig	The same idea for the Codex CLI: sync config.toml, AGENTS.md, skills, prompts and rules across machines via a private git repo, with cross-OS path correction (including the absolute paths Codex writes as TOML table KEYS), TOML-aware field-level redaction, and several Codex logins side by side, each in its own CODEX_HOME. Session rollouts are opt-in and are never rewritten. See docs/CODEXRIG-DESIGN.md.
cmd/brewrig/	brewrig	Keep several machines on the same Homebrew software — and the same versions of it. Each machine publishes what it deliberately installed (installed_on_request, not the dependency closure) to a private git repo; the union is installed everywhere. It never uninstalls to make machines match: the one exception is a package you deliberately removed elsewhere, offered one prompt at a time. darwin/linux only — Homebrew has no Windows. See docs/BREWRIG-DESIGN.md.

These binaries are single, statically-linked Go executables — the north-star property: no .NET runtime, no Node, installable via curl | sh / Homebrew / winget / Scoop on any machine John roams onto. Every release builds the tools for macOS, Linux, and Windows, on x86-64 and Arm64 alike — except brewrig, which is macOS and Linux only because Homebrew does not run on Windows.

Status

At parity — ported 2026-06-11/12. The shared engine, both CLIs, and the release orchestrator are built and tested at functional parity with the two .NET source projects (see docs/FEATURE-PARITY.md for the feature audit and test-parity.md for per-suite test coverage). Behavior is pinned by a cross-implementation golden corpus (core/testdata/parity/, 22 scenarios verified against live Node @changesets and the live C# binary). claude-questions.md records the decisions made along the way.

What works today

# in any polyglot monorepo (.NET / Node / Go / Rust):
changerig init                              # create .changeset/
changerig add -t feat -p my/pkg -m "…"      # write a changeset (interactive without flags)
changerig status --verbose                  # show the pending release plan
changerig status --since main               # only what this branch adds (its changesets and commits)
changerig version                           # bump versions + write CHANGELOG.md, with dependency cascade
changerig version --changelog --since main  # preview this branch's changelog entries; writes nothing
changerig version --ignore pkg              # leave a package out of this run (as changeset version --ignore)
changerig version --only pkg                # version only this release group; the rest wait for a later run
changerig version --yes --release-as pkg=2.0.0   # release a package at an exact version (CI)
changerig ui                                # interactive bubbletea menu
shiprig publish                             # registries + tags (idempotent, confirm-gated on a TTY)
shiprig release                             # the configurable step pipeline (.changeset/release.jsonc)

rig info                                    # what rig discovered
rig build / test / run / format             # the right native command for the detected ecosystem
rig verify [--stale-only]                   # build+test+run, then prove the artifacts were built together
rig coverage --min 80 / kill / doctor / cd  # the dev-loop verbs (see cli/README.md for all)
rig copy ../snapshot [--git]                 # detached copy of the tree (skips node_modules/.git; --git keeps history)
rig worktree new feat/x                     # sibling checkout for working on a branch alongside

# your app and its forked libraries fused into one history, each still leaving as itself (private repos: just `gh auth login`):
rig stack setup                             # a fresh clone of a stackspace: engine, members, overlay
rig stack init                              # scaffold rig.stack.jsonc; run again to import
rig stack status / pull [repo]              # what upstream did, where each topic's PR is, and taking it
rig stack propose some-lib read-timeout        # ALL of some-lib's changes → stack/read-timeout, PR-ready
rig stack propose some-lib read-timeout --from read-timeout   # ...or one topic's tree — root it on the import, or it carries its parent's fixes too
rig stack push my-app                       # → your own repo, fast-forwarded, history intact
rig stack pack some-lib                     # its packages, built here where siblings resolve from source
rig stack propose some-lib read-timeout --dry-run   # what would go to your fork, touching nothing
rig stack push my-app --dry-run             # what would go — target, branch, commits — touching no remote

The release engine — changeset parsing, the dependency cascade (a dependent is patch-bumped when its dependency releases), linked/fixed/lockstep grouping, version bumping, and changelog rendering — is a faithful port of net-changesets and is exercised end-to-end by changerig version across all four ecosystems (examples/demo is a ready-made polyglot repo to try it on).

Changelog generators are pluggable: the built-in renderer dogfoods the same JSON contract external plugins speak; examples/plugins/changeset-changelog-changelogen is a Node reference plugin producing changelogen-style output. Set "changelog": "<plugin>" in config to swap it in.

Design

• docs/ARCHITECTURE.md — module layout, the shared-core boundary, how rig and shiprig relate.
• docs/PLUGIN-PROTOCOL.md — the one extension mechanism (subprocess + versioned JSON) for both ecosystem adapters and changelog generators, and why built-ins dogfood it.
• docs/FEATURE-PARITY.md — exhaustive feature-by-feature parity audit of rigsmith against net-changesets and rig (.NET + Node).
• docs/GITHUB-ACTIONS.md — the two composite Actions: release (the version-PR/publish loop) and require-changeset (the per-PR gate — comment + block, no hosted bot). Built (.github/actions/). For releasing, rigsmith/shiprig-action is the recommended successor, and what rigsmith itself uses.
• docs/BEST-PRACTICES.md — a field guide in three parts: the engineering patterns this codebase embodies, how to contribute (worktree/PR discipline, commits, releases), and how to get the most out of the tools.

Building

go build ./...          # single module (github.com/rigsmith/rigsmith)
go test ./...           # core has full unit tests
go build -o bin/shiprig ./cmd/shiprig
go build -o bin/rig ./cmd/rig

Installing the stable binaries from source

To build the real, named binaries (rig, clauderig, shiprig, changerig) from the working tree and put them on your PATH — so the tools resolve each other the same way a released install does:

rig source-install      # or: go run ./scripts/source-install

This installs to ${RIGSMITH_INSTALL:-$HOME/.local}/bin (the same prefix as the curl | sh release installer). Tools are discovered from cmd/, so a new cmd/<tool> installs automatically. Use this when you want stable binaries; use <tool>-dev (below) when you want them to recompile on every run. On Windows, the installer requests administrator access only when the chosen destination is protected.

Running a dev build alongside the installed binaries

To dogfood the tools from source without disturbing a globally installed rig/shiprig/etc., install <tool>-dev launchers — they run the working tree via go run and coexist with the stable binaries:

rig dev-install         # or: rig run dev-install, or: go run ./scripts/dev-install

This writes rig-dev, shiprig-dev, clauderig-dev, … to ~/.local/bin (sh wrappers on macOS/Linux, .cmd on Windows). Each recompiles the current source on every run, so edits take effect with no reinstall. The launchers are discovered from cmd/, so a new cmd/<tool> gets one automatically. On Windows, the installer requests administrator access only when the chosen launcher directory is protected.

rig dev-install works because rig surfaces helper main packages committed under scripts/ (e.g. dev-install, source-install) as bare rig <name> verbs — the Go counterpart to how it exposes a Node repo's package.json scripts. (In a multi-module workspace it also surfaces scripts/- or cmd/-located mains listed in go.work.) These verbs are exact-match only (excluded from prefix-matching) and never shadow a built-in.

Credits

Two projects worked out how to run several Claude accounts from one machine before rigsmith did. clauderig account and clauderig desktop are independent Go implementations, but the ideas — and several of the hard-won details — are theirs:

• claude-swap by realiti4 (MIT) — the multi-account model for the Claude Code CLI, and its safety mechanisms: process detection before a swap, security -i writes that keep secrets out of argv, and the round-trip backup of the displaced credential. Later work of theirs we adopted deliberately, and credit inline at the code: cooperating with Claude Code's own OAuth refresh locks (their PR #167), refusing to capture from inside an isolated session profile (#190, #205), and writing through a symlinked ~/.claude.json rather than over it (#201). docs/CLAUDE-SWAP-REVIEW.md is our full review of that project — what we took, what clauderig already covered, and what we chose not to build.
• guise by siddhjagani — the per-profile model behind clauderig desktop: rather than move a Claude Desktop session between accounts, give each account its own permanent --user-data-dir and launch the app against it. Including the macOS launch mechanism (open -n -a Claude.app --args --user-data-dir=…), which detaches the app from the calling terminal. clauderig adds Windows support and the integration with its account store; the reasoning is in docs/CLAUDERIG-DESKTOP-PROFILES.md.

Independently: the release engine is a faithful port of net-changesets, which is itself a .NET port of changesets.