rpiv-mono: one npm workspace for the rpiv Pi agent extensions

Fifteen packages, one workspace, twelve of them public

The unit of this repository is a workspace rather than a product. Fifteen packages sit under one npm workspace, the rpiv-pi pipeline, the Pi agent extensions it composes, and the internal packages holding them up. The README states that twelve publish to npm and three never leave the repository. The public set is the pipeline itself, rpiv-pi, plus eleven extensions, each installable on its own and each doing one thing: rpiv-args expands shell-style $1 and $ARGUMENTS placeholders inside skills, rpiv-ask-user-question lets the model put a structured questionnaire to the user, rpiv-todo keeps a live task overlay that survives /reload and compaction, rpiv-advisor escalates to a stronger reviewer model before the agent acts, and rpiv-web-tools gives the model web search and fetch with pluggable providers. The remaining published ones are rpiv-i18n, a small localization SDK that started as translations for ask-user-question, rpiv-workflow, rpiv-btw, rpiv-voice, rpiv-warp and the config library rpiv-config.

Installing the pipeline in three commands

The entry point for users is the rpiv-pi package, and the README gives the sequence plainly: install it from npm, restart Pi, then run the setup slash command. The restart matters, because the extension surface changes what Pi loads at startup.

pi install npm:@juicesharp/rpiv-pi

After the restart you run /rpiv-setup, and the key detail is that this command installs only the siblings the pipeline actually depends on, while the other extensions stay opt-in. The extension table in the README marks exactly which ones the setup command pulls in, and the pipeline entries are rpiv-args, rpiv-ask-user-question, rpiv-todo, rpiv-advisor, rpiv-web-tools, rpiv-i18n and rpiv-workflow, while rpiv-btw, rpiv-voice and rpiv-warp are left for you to choose. If you only want a single piece, the same install shape works per package, and each extension still asks for a Pi restart afterwards. The full narrative, the subagent map and the install walkthrough live on the separate site rpiv-pi.com, which is the documentation the README points to rather than a longer section here.

The extensions exist because of how the author works

Several of these packages are not abstractions, they are habits that got packaged. rpiv-btw is described as a side-conversation pattern the author got used to in Claude Code, and rpiv-warp integrates Pi with the Warp terminal notification system because that is where the author runs Pi. rpiv-voice is on-device dictation for when talking is easier than typing, using a /voice overlay and on-device Whisper. rpiv-todo is the more general version of the same idea, a live task overlay that survives /reload and compaction, which is the failure mode that makes long agent runs hard to follow. rpiv-advisor escalates to a stronger reviewer model before the agent acts, and rpiv-web-tools adds web search and fetch with pluggable providers, so the provider is a configuration choice rather than a hard dependency. Reading these as a set, the pattern is a set of small surfaces layered onto a base agent, which is also why the monorepo keeps them in one place: when the orchestration changes, these surfaces have to change with it.

rpiv-workflow is the piece with real machinery in it

Among the extensions, rpiv-workflow carries the most specific engineering description. It chains skills into typed multi-stage pipelines, and it does so with audited JSONL state, predicate routing and per-stage output validation, and it ships the /wf command that Pi calls to run a pipeline. Each of those three mechanisms addresses a failure that shows up when a multi-step agent run goes wrong. Audited JSONL state means the run leaves a record you can inspect afterwards, rather than living only in a context window. Predicate routing is what lets a later stage decide which branch to take, and per-stage output validation is the check that a stage produced the shape the next stage expects. The consequence for a reader is that this is not a wrapper around a single prompt template. It is a pipeline engine, and it is the component most likely to need real configuration before a team depends on it.

Three packages that never reach the npm registry

The workspace also contains packages you cannot pi install, and the README is precise about how each one is obtained. rpiv-telemetry wires Pi into MLflow, auto-instrumenting lifecycle events and sub-agent activity so runs are inspectable after the fact. It stays private: true and is loaded from a checkout, never the registry, and the README gives the command for pointing Pi at a local copy elsewhere.

pi install ./packages/rpiv-telemetry

The other two are support code. rpiv-site is the rpiv-pi.com site, a static Astro build, built from the repository with the site build script and deployed to GitHub Pages by CI. test-utils holds shared test fixtures under the @juicesharp/rpiv-test-utils name, is symlinked by npm workspaces and imported by the test suite only. rpiv-config is the odd one out, since it is published as a library, npm install @juicesharp/rpiv-config, and it registers nothing with Pi. It exists because it is the shared XDG-aware JSON config I/O that every sibling depends on, and the README notes that ten siblings already pull it in as a dependency. It is published only so those dependencies resolve, which is the sort of detail worth checking before you copy that pattern into your own workspace.

Version bumps and publishes run across every package

The scripts in package.json show how the lockstep promise is enforced. A version bump runs npm version for the given bump type across all workspaces, then a sync script, then removes node_modules, the per-package node_modules and package-lock.json, and reinstalls. Publishing runs the check script first, because prepublishOnly is wired to it, then publishes every workspace with public access. The check script itself is a chain: a check for host-provided dependencies, a check on TypeScript import specifiers, Biome with --write and --error-on-warnings, and a TypeScript compile check with no emit. Alongside it sit project specific checks, including a script that fails on decision codes, one that checks file sizes, one that checks host-provided dependencies and one that checks TypeScript import specifiers. Note that the Biome step writes changes back to the tree, so a failing check can modify your working copy before it fails. A husky prepare script installs the git hooks, and the README says the git hooks enforce the conventions.

The boundaries of a monorepo with no releases

Two facts frame any decision about this repository. The repository has no GitHub releases, so there is no published version history to point at, and the root package.json is itself private with version 0.0.0, since the root is a workspace holder rather than a shipped package. The last push was on 2026-10-17 and the repository is not archived. The other boundary is the dependency on the Pi agent itself, which comes from badlogic/pi-mono and appears in devDependencies alongside @biomejs/biome and @earendil-works/pi-ai. Every extension here is a Pi extension, so adopting rpiv-mono means adopting that model of extension points. The licence field on the repository says MIT, and the code is checked with Biome and TypeScript in strict mode through tsconfig.base.json, with tests run by Vitest and a codecov badge on the README. The remaining practical risk is not legal but operational: a lockstep monorepo means an unrelated change in one package can move the version of every other one you depend on.

Editorial conclusion

rpiv-mono makes sense for someone who wants the whole rpiv pipeline and intends to follow it as it changes, since the pipeline, the extensions and the shared config are versioned and published together, and for someone who only wants the workflow runner or the telemetry bridge and can work from a checkout. It is a poor fit if you want one extension to move on its own, because the package.json version scripts bump every workspace at once and the repository publishes no GitHub releases to track individual versions. Before you depend on it, read the /rpiv-setup list to see which siblings the pipeline actually installs, and check that the base configuration package resolves the way your setup expects, because rpiv-config is what ten siblings depend on.

Frequently asked questions

Official sources

1. Issues
2. juicesharp/rpiv-mono on GitHub
3. License: MIT
4. README