RSIH: versioning an agent harness with Genomes on top of Pi

The problem RSIH targets: a harness is not a file

An agent's behaviour comes from more than a system prompt. Tool sets, skills, MCP servers, extensions, runtime policies, memory, keybindings and themes all shape what the agent does, and in most setups those live in scattered config directories that are hard to copy to a second machine and harder to review in a pull request. RSIH's answer is to call that whole bundle a Genome: "a complete, self-contained, deliverable harness configuration", per the README. Switching contexts is switching Genomes, which means a paper-experiment setup and a code-review setup are two directories rather than two mental modes.

The intended audience is narrow and specific. RSIH is built on the Pi coding agent, so it assumes you already use Pi or are willing to. It is a TypeScript project, private in package.json at version 0.1.0, and it ships two Genomes: paperlab, described as a paper-experiment harness distilled from real experiment workflows, and harness-rsi, which the README calls "the harness that builds harnesses". If your agent configuration is already tidy, or you do not use Pi, the value proposition largely evaporates.

How a Genome layers onto Pi without forking it

The mechanism is deliberately thin. RSIH does not reimplement the agent. Once installed, the README states that "rsih is pi, zero difference": every flag, subcommand and slash command works unchanged, and launched without a Genome it behaves exactly like pi, with a test guarding that invariant. The only baseline change is the config directory, which becomes ~/.rsih.

Everything else comes from naming a Genome at launch. Four spellings are equivalent: --genome paperlab, the colon shorthand :paperlab, ::paperlab, or +paperlab. The README explains the restriction that only the first argument counts: Pi treats positional arguments as the message and most options take a value, so a genome marker anywhere else would swallow a message word or an option value. The parenthesis form is deliberately not offered because it is a shell metacharacter.

Inside a Genome, components are declared individually and anything undeclared inherits the Pi default. The README's component-by-component table for paperlab is the clearest illustration. It appends a paper-experiment operating mode to instructions; adds three file-backed skills (research-experiment-scout, experiment-bootstrap, experiment-run-ops); adds a read-only /run-status command; and sets resources with isolate: true, which turns off Pi's automatic discovery of skills, prompt templates and themes so the prompt carries only what the Genome declares. AGENTS.md and CLAUDE.md are explicitly untouched. The other eight components (tools, model, runtime, policies, integrations, appearance, settings, keybindings) are not declared at all, which is why rsih :paperlab runs on whatever model you already configured. That inheritance model is the design's main virtue and its main trap: a Genome that declares nothing about the model will silently follow local configuration, so two people sharing one Genome can get different results.

Installing RSIH from a clone and running a first Genome

The README gives a clone-and-run path rather than an npm install. Node 22.19+ is required, and the install script checks dependencies, builds, installs into ~/.local/bin, and then asks you to pick an install mode. The --copy mode moves the binary and all its assets out of the repo for good; --link symlinks to the build output for hacking on RSIH itself. With bun installed it compiles a single-file binary; without it, it falls back to a node wrapper.

git clone https://github.com/CosmosMind-ai/RSI-Harness.git && cd RSI-Harness
./install.sh

After that, plain rsih is pi. The commands below are the ones the README lists for ordinary use, including the persistent --run-id flag that appends every call carrying the same id to the same conversation, with the Genome stated once on the first call and restored automatically afterwards.

rsih
rsih --resume
rsih --fork <session>
rsih -p "Review the current workspace"

To actually exercise the Genome layer, name one at launch and inspect it first. genome list shows what is installed, what shipped and what is outdated; genome show resolves a Genome and prints the settings patch it would write, without writing it.

rsih genome list
rsih genome show paperlab
rsih genome validate ./my-genome
rsih genome install paperlab

One operational detail worth reading twice: piped stdin joins the prompt, so a -p call in a non-TTY context waits for stdin to close. When spawning rsih -p from another process, close the stdin pipe or redirect it from /dev/null, or the call will hang rather than fail.

GEE and the honest limit of generating a Genome from history

GEE, the Genome Expression Engine, is a one-word command that launches the harness-rsi Genome: gee is equivalent to rsih :harness-rsi and to rsih --genome harness-rsi. Its premise is that you should not be asked to describe the system prompt you want. Instead it reads what you actually did. It asks one conversational question, what the Genome is for, then asks which session stores to analyze. RSIH's own store is included by default; Pi's ~/.pi/agent/sessions and Claude Code's ~/.claude/projects can be added. It groups history by working directory, then aggregates tool-call histograms, frequent bash commands, hot files and repeated corrections.

That aggregation-first approach is a reasonable privacy stance, and it is also the source of the sharpest limitation. A Genome inferred from history encodes your habits, including the bad ones: if you routinely work around a missing check by pasting the same command, that workaround is exactly the kind of pattern an aggregation over frequent bash commands will surface as signal. The README describes what GEE reads, not how it decides what to keep or discard, so treat generated Genomes as drafts and read them before sharing them. There is also no rollback story documented for an install that overwrites a local Genome; genome install paperlab is described as restoring the factory version, which implies it replaces what is there. The README does not document a backup or revert step, so keep your own copy before you run it.

Where RSIH is the wrong tool

The first boundary is the agent itself. RSIH is Pi plus a configuration layer, not a portable harness format. If your team runs a different agent, or several, nothing here transfers; the Genome concept is tied to Pi's component names and its config directory.

The second boundary is release discipline. package.json marks the package private and version 0.1.0, and no releases were retrieved. The repository is not archived and the last push was on 2026-09-09, but there is no tagged release line to pin against, so anyone who needs a versioned dependency with a changelog should wait.

Third, the licence is unknown. The repository does not state one. For a tool whose whole pitch is sharing configurations between people and machines, an unstated licence is a real blocker for anything beyond personal use, and it is not something to resolve by assumption.

Fourth, isolation cuts both ways. resources: isolate: true is what makes a Genome self-contained, and it also means skills, prompt templates and themes you installed globally stop being discovered when that Genome is active. That is the intended trade, but it surprises people who expect their existing setup to keep contributing.

How RSIH differs from dotfiles and from prompt-template managers

The obvious alternative is a dotfiles repository plus a symlink script. That approach shares files; it does not resolve them. RSIH's genome show prints the resolved Genome together with the settings patch it would write, and genome validate checks a Genome before it is installed. A dotfiles repo gives you no equivalent of either, because there is no schema to validate against and no defined inheritance from a default. The cost of that structure is that a Genome only means something inside RSIH.

A second alternative is a prompt-template or system-prompt manager. Those typically cover one component, the instructions, and leave tools, MCP servers and runtime policies to whatever the agent already does. RSIH treats all of them as one deliverable, which is more complete and also more coupled: adopting it means adopting Pi's component model wholesale. There is no partial adoption path described in the README. The related searches for this project, "Rsi harness price" and "Rsi harness cost", have no answer in the README: it describes a git clone and an install script, and states no pricing.

Maintenance, upgrade cost and the licence question

The last push was on 2026-09-09, which is recent, and the repository is not archived. That is the whole of what can be said about activity from the available facts; there are no retrieved releases to indicate a cadence. The dependency surface is small but pinned exactly: @earendil-works/pi-agent-core, pi-ai, pi-coding-agent and pi-tui all at 0.84.3, plus @modelcontextprotocol/sdk at 1.30.0, with TypeScript 5.9.3 and @types/node 22.19.19 in devDependencies. Because RSIH's promise is that rsih is pi with zero difference, upstream Pi changes are the main upgrade risk, and the pi-surface test file in the test directory is the mechanism the project uses to keep that surface honest.

Upgrading means rebuilding from source, since the install script builds and the package is private. There is no published artifact to pull. On licensing, the repository states no licence, so no permissions can be inferred; if you plan to redistribute a Genome or embed RSIH in a product, that is a question for the repository owner, not something the README answers.

Editorial conclusion

Adopt RSIH if you already run the Pi coding agent and want the surrounding configuration to be a versioned, transferable artifact rather than a pile of local dotfiles, or if you want to try generating a Genome from your own session history with gee. Skip it if you are not on Pi, if you need a published licence before you ship anything, or if your team expects a stable release line: the package is private at 0.1.0 and no releases were retrieved. Before you commit, run rsih genome validate on the Genome you intend to share, and check the licence situation with whoever owns the repository, because the repository does not state one.

Frequently asked questions

Official sources

1. CosmosMind-ai/RSI-Harness on GitHub
2. Issues
3. README