Genome, one argument, and the pi surface RSIH deliberately leaves alone

Everything RSIH adds to pi is packed into the first argument

The Pi coding agent treats positional arguments as the message to send, and most of its options take a value. That single fact is why RSIH accepts a genome marker in exactly four positions and only as the first argument. Four spellings resolve to the same thing:

rsih --genome paperlab   # explicit
rsih :paperlab           # colon shorthand
rsih ::paperlab          # double colon
rsih +paperlab           # plus

Put the marker anywhere else and it eats a message word or an option value instead of selecting a config. A fifth spelling using a parenthesis is not offered at all, because the character is a shell metacharacter and `rsih (paperlab` is a syntax error in both zsh and bash. So the extension surface is a single switch on argv[1], and the README points at docs/rsih_in_cli.md for the persistent RPC mode that other programs and agents use to drive the same binary.

install.sh asks copy or link before it writes anything

There is no npm install path. The documented setup is a clone and a script:

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

The script checks dependencies, builds, installs into `~/.local/bin`, and then asks which install mode you want. `--copy` moves the binary and all its assets out of the repository permanently, which is what you want if the clone is disposable. `--link` symlinks to the build output instead, which is the mode for working on RSIH itself, and it is also the mode that breaks the moment the clone is deleted. Node 22.19 or newer is required. With bun installed the build compiles a single file binary; without bun it falls back to a node wrapper, so the two modes do not produce the same artefact and a machine that changes its package manager mid-project changes what ends up on the path.

rsih is pi under a different config directory, and a test guards that

The compatibility claim is unusually specific: once installed, `rsih` is `pi`, with every flag, subcommand and slash command working unchanged. Launched without a Genome it behaves exactly like pi, and a test guards that invariant rather than leaving it as a promise. The single behavioural difference is where configuration lives, moving from Pi's own directory to `~/.rsih`. That directory is also where community Genomes land: drop a Genome directory someone shared into `~/.rsih/genomes/` and it runs, with no install step. Four subcommands cover the lifecycle:

rsih genome list                    # what's installed, what shipped, what's outdated
rsih genome show paperlab           # resolved Genome + the settings patch it would write (read-only)
rsih genome validate ./my-genome
rsih genome install paperlab        # restore the factory version

`show` is read-only, which makes it the safe way to see what a Genome would actually write. `install` restores the shipped version, so a locally edited paperlab can always be thrown away. `validate` takes a path, which is the path a shared directory arrives on before anyone trusts it.

run-id stitches separate shell calls into one conversation

Scripted use gets its own model. A `--run-id` value makes every call carrying the same id append to the same conversation, and the Genome is stated once on the first call and then restored automatically:

rsih :notes -p "Outline this week's lab notes" --run-id week-32 --cwd ~/lab
rsih       -p "Section 3 is too long; split it" --run-id week-32 --cwd ~/lab
rsih       -p "Export as markdown"              --run-id week-32 --cwd ~/lab --json

Note how the Genome marker appears only on line one and that the calls repeat neither it nor the run id in full: the id carries the state. The other flags in that set are narrower. `--cwd` sets the working directory and decides where the session lands, `--model` swaps the model for one call only, and `--json` emits a structured event stream rather than prose. A `--resume` and a `--fork <session>` form sit alongside the plain bare `rsih` invocation. So the conversation identity, the working directory, the model and the output format are four separate controls, and only the first is sticky across a run.

Piped stdin joins the prompt, which stalls any non-TTY caller

Piped stdin joins the prompt text. The practical consequence is the sharpest edge in the whole tool: a `-p` call in a non-TTY context waits for stdin to close. A parent process that spawns `rsih -p` and leaves the pipe open gets a call that never returns, with no output and no error. The fix is stated plainly in the docs: close the stdin pipe, or redirect it from `/dev/null`. This matters for the `--run-id` pattern above, because that pattern is built for exactly the calling context that triggers the problem. Anything wrapping RSIH in a script, a CI step or another agent needs the redirect on the first attempt, not after a hung job times out. Nothing in the command set disables stdin joining, so there is no flag to sidestep it, only the shell-level workaround.

paperlab declares four components and inherits the other eight

The example Genome is where the isolation model becomes concrete. A Genome is a complete, self-contained, deliverable configuration: system prompt, tool set, skills, MCP servers, extensions, runtime policies, memory, keybindings and themes, all in one directory. `paperlab` declares four of those. `instructions` appends a paper experiment operating mode, treating research question, dataset, model, environment and evaluation as one coupled experiment, taking the shortest path to a real smoke test before scaling, preferring traceable datasets from primary sources, keeping datasets, caches and checkpoints off constrained system disks, and never reporting run state from directory existence or stale summaries. `skills` adds three file-backed skills: `research-experiment-scout`, `experiment-bootstrap` and `experiment-run-ops`. `commands` adds `/run-status`, which is read-only and takes no credentials. `resources` sets `isolate: true`, turning off Pi's automatic discovery of skills, prompt templates and themes so the prompt carries only what the Genome declares, while `AGENTS.md` and `CLAUDE.md` stay untouched. The other eight components, including `model` and `tools`, are not declared at all and inherit the Pi default, so `rsih :paperlab` runs on whatever model you have configured.

GEE reads your session stores instead of asking for a system prompt

Two Genomes ship: `paperlab`, the example, and `harness-rsi`, a harness whose output is other Genomes. The second one is reached by a one-word command:

gee            # == rsih :harness-rsi == rsih --genome harness-rsi

GEE, short for Genome Expression Engine, never asks what system prompt you want, because it reads what you already did. It opens with one question, what the Genome is for, then asks which session stores to analyse. RSIH's own store is included by default; you can add Pi's `~/.pi/agent/sessions`, Claude Code's `~/.claude/projects`, and Codex's session and archive stores under `CODEX_HOME`, which defaults to `~/.codex`. From there it groups history by working directory and aggregates tool-call histograms, frequent bash commands, hot files and the corrections you keep repeating. The stated discipline is aggregate first, read raw text selectively, never dump a whole JSONL into context. The scenario you described then becomes the yardstick for classifying evidence: which recurring pattern should be a skill, which a tool, which an MCP server, and which is only preference worth remembering. The walkthrough ends one line into the write step, after the point where it would start drafting files. Beyond that classification boundary the docs go quiet, so what a generated Genome actually looks like on disk is left to the examples in `examples/genomes/`.

Version 0.1.0, private true, and no release anywhere

The package manifest says `"name": "rsih"`, `"version": "0.1.0"`, `"private": true` and `"license": "MIT"`. The private flag means npm publishing is blocked by design, and the repository has no GitHub releases, so a pinned artefact does not exist for anyone to depend on. Two binaries come out of the build, `gee` at `./dist/src/gee/cli.js` and `rsih` at `./dist/src/cli.js`, both reached only after a local build. The four Pi packages are pinned to an exact version rather than a range, `@earendil-works/pi-agent-core`, `pi-ai`, `pi-coding-agent` and `pi-tui` all at 0.84.3, with `@modelcontextprotocol/sdk` at 1.30.0, so an upstream Pi release cannot move under a working install without an edit. Node is declared as `>=22.19.0`, and the build and every script run through `node --experimental-strip-types`, which is why the floor sits at 22.19 rather than at 22. The test command names its nine suites explicitly, from `test/core-harness.test.ts` through `test/session-sources.test.ts`. A Chinese README sits next to the English one, and the last push landed on 23 September 2026 with 723 stars, 28 forks and 4 open issues.

Editorial conclusion

Judgment: RSIH is worth reading as a config layer design rather than adopting as a tool today. The part that holds up is the isolation model, where one Genome declares four components and inherits the other eight, and the run-id conversation scheme, where three commands share one thread without retyping the Genome. The parts that do not hold up are distribution, with no release, a private package flag and an install script that writes into your home directory, and the GEE write step, which is the part you would want and the part the docs stop short of. Anyone picking this up should first read install.sh to see which mode it defaults to, then decide whether copy or link matches how you intend to work, and treat harness-rsi as unproven until its output Genomes have been inspected.

Frequently asked questions

Official sources

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