Smithers: Agent Workflows That Turn Issues Into Reviewable Changes, Installed as smthrs@next

The CLI installs from the next tag and the package is called smthrs

The repository is named smithers, but the command line tool is a different name. The install line is global and pulls the next tag, not a pinned stable number:

npm install -g smthrs@next

The libraries install from npm as well, and the Flows quickstart inside the repository is where they start. The consequence of the next tag is that two machines installing a week apart can end up on different builds, so a team should write down the version it actually got. Nothing in the install instructions offers a pinned alternative. Also note the root package.json is marked private with version 0.0.0, so the repository root itself is not what you install; the published pieces come from the workspace packages.

A scaffolded flow does nothing useful until you edit it and set a credential

Getting started is two commands, run from your project directory:

smthrs init change
smthrs flow start change

The first scaffolds a flow named change and the second launches it. Between them you are expected to edit the scaffolded flow and configure the credential that its model: field requires. The order matters. Running the launch command straight after init skips both the edit and the credential, so the run has no model access to work with. Which credential applies depends on the model you name in the flow, since the project is described as working with Claude Code, Codex, Gemini, any model or harness. The CLI quickstart on smithers.sh covers each step in detail.

Node 22.19 is the floor, but certification is Linux with Node 26.4.0

Smithers needs Node.js 22.19 or later. That is the minimum. The stated certification is narrower: the release candidate is certified on Linux with Node 26.4.0. The two numbers are far apart, and the gap is the thing to read carefully.

If you run macOS or Windows, or a Node between 22.19 and 26.4.0, you are using something the certification statement does not cover. That may work, but nothing in the repository data says so, and the project points to a support matrix on its site as the place that settles it. The repository also carries a .node-version file and a packageManager entry of [email protected], so contributors working from source should match those instead of using whatever is installed. The repository ships a bun.lock and a bunfig.toml too, and the tui script runs through bun.

Flows sit beside the code, and the repository runs its own release on them

The README's summary is that flows beside your code define how Smithers does its work. The repository is the clearest example. Its .smithers/flows directory holds flows named land, issue-claim, release, release-support, coding and a review set called seeded-bugs, and root scripts call them: commit runs .smithers/flows/land/commit.mjs, issue-claim runs .smithers/flows/issue-claim/issue-claim.mjs, and the release scripts run .smithers/flows/release-support/main.ts with the vibelang register hook.

That shows the intended shape: a flow is code in your repository, versioned with it. The cost is that the behaviour of the tool is not a setting you toggle in a UI. It is code you read and maintain. A flow written for one repository does not carry over to another until you adapt its paths and scripts.

Output is a change for you to review, and wiki updates are opt-in

Smithers turns issues into tested changes for you to review. The phrase puts a human at the end of the loop: the product is a proposed change, not a merged one. The project wiki is kept current only when enabled, so a fresh install does not touch documentation on its own.

The repository description adds the run-level promises: full observability, watching every step live, and the ability to rewind, fork and replay any run. The two commands in the getting-started section only start a flow, and they do not include rewind, fork or replay. Those are described in the repository description and the site documentation, so look there for the exact commands before planning around time travel. For reading runs in a browser, the project offers its own hosted view at smithers.sh, where you sign in with GitHub when ready to contribute.

A Rust workspace compiles flow code to wasm32-wasip1 for the browser

Beside the JavaScript there is a Cargo workspace with two members: packages/smithers/flows/jj-wasm and packages/smithers-ffi. It depends on jj-lib from the smithersai/jj fork, which is jj-vcs/jj main plus a patch stack, pinned to one commit that Cargo.lock records. The comment in Cargo.toml says browser flows and the repository service use the same jj store format.

The release profile tunes for the wasm32-wasip1 artifact that ships to the browser, with codegen-units 1, thin lto, opt-level s and debuginfo stripped. Dev builds turn debuginfo off because jj-lib's debuginfo multiplies the target directory several times over. For a reader this means building from source needs a Rust toolchain as well as Node, and a git dependency on a fork. A rust-toolchain.toml and a flake.nix are in the repository for that purpose.

Recent releases are v0.33 to v0.35 in August, while the repository kept moving

The newest release is v0.35.0 on 2026-08-17, preceded by v0.34.0 on 2026-08-13 and v0.33.0 on 2026-08-02. The last push to the repository came on 2026-11-02, so work continues on main well after the last tagged release. The repository is not archived.

Combine that with the next install tag and the release-candidate wording, and the picture is a project moving quickly through 0.x versions. Expect interfaces to change between minor releases. The license is MIT, the author field names William Cory, and the code lives in a pnpm workspace that spans packages, apps and evals directories. Contributors should read CONTRIBUTING.md for setup, testing and pull request guidance, and there is a community channel on Telegram.

Editorial conclusion

Smithers fits teams that want agent runs that can be watched, rewound and replayed, and that accept a CLI installed from the next tag with a release candidate certified on Linux. It is a poor choice for anyone who needs a settled stable channel or a platform other than Linux and a recent Node. Before adopting it, check the support matrix for your OS, set the credential that the scaffolded flow's model field requires, and confirm you want its output as changes to review, not merges.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes