@ericrisco/rsc weekly downloads statistics

rsc-harness

You build the product. rsc-harness builds its harness.

Every time you open a project, your agent starts from zero. rsc is a meta-harness: it gives the assistant you already use (Claude Code, Codex, Cursor and 15 more) a memory, hands, a trade and reflexes, so it stops starting over.

Give this URL to your agent and paste the request in the chat:

Or start from the terminal:

The problem

• You explain everything again. Every new session, every new project: the stack, the conventions, what was decided, what must not be touched. • What the agent does not know, it invents. And the guess looks plausible, which is worse than an obvious error. • Decisions die with the chat. What you settled yesterday is gone the moment the window closes.

The most important thing an agent needs is documentation, and nobody keeps it for the agent.

When people fix this by hand, the result is a Frankenstein harness: duplicated instructions, unrelated skills, premature hooks, unnecessary MCPs and no clear owner. Open standards cover single parts (Agent Skills, MCP, AGENTS.md), but none of them decides which complete harness your project needs.

The idea: documentation is your agent's memory

The model is the brain your agent rents, and you already have it. rsc adds the rest, in four pieces:

| Piece | Where it lives | What it does |

| Memory | 02-DOCS/ | A wiki the agent reads before it works and keeps up to date while it works. | | Hands | 01-TOOLS/ | One folder per tool, with a test that proves the connection works. | | Trade | skills | Only the skills your project needs: 271 available, a handful installed. | | Reflexes | hooks | Rules that hold even when the agent forgets them mid-session. |

Why documentation comes first

An agent without documentation spends most of its effort searching. It opens files, greps, reads the same module twice, and still ends up guessing. Every one of those turns costs tokens, and the guess costs more later.

With a well-structured 02-DOCS/, the agent knows where to look. It finds what it needs in one read instead of ten, so the same task costs fewer tokens.

And because it finds what already exists, it builds on it:

• It reuses the function you already have instead of writing a second one. • It follows the structure your project already uses, every time. • It works from what is true about your code, not from a plausible guess, so less of what it writes breaks.

Good documentation is not overhead for your agent. It is what makes it cheaper and better at the same time.

A day with rsc

1. You install it. It asks a few questions in plain language: how technical to talk, what the project is for, its goal, and which assistants you use. It reads only the project root. 2. It shows the plan before it writes anything. Every piece is selected, deferred or excluded, each with its reason. Nothing is written until you accept that exact plan. 3. You ask for things. The agent decides how much process each request needs, and says so in one line: an answer, a quick change (FTD), or the full chain (SDD). 4. It documents as it goes. Decisions, connections and progress land in 02-DOCS/, not in the chat. 5. Tomorrow, the agent already knows. You, a teammate on another machine, or another assistant open the project and continue where the last session stopped.

What changes for you

• You never explain your project again. The knowledge lives in the repo, not in your head. • Fewer tokens, more consistent code. The agent finds instead of searching (see why documentation comes first). • The right amount of process. A typo gets fixed; a new subsystem gets a spec. The agent picks. • Safe for teams by default. Shared knowledge, one workspace per agent, and no surprise commits on main. • Any assistant, or several at once. 18 are supported, and they share one installation. • It talks so you understand. Short sentences, in your language, technical or with analogies.

Install in one minute

The first run asks one question about conversation (technical, or with analogies), then what the project is for, its goal and the assistants to target. Then it presents the complete plan. A small website can defer SDD, agents and code guards; an operations harness does not receive them merely because it lives in a repository. Deferred components record the evidence that would make rsc recommend them later, and rsc reassess reports it without installing anything.

Everything stays in the project. The real skill files are written once to .rsc/skills//, and each assistant gets a symlink back to that shared base, so picking several duplicates nothing. Skills load progressively: only their description is paid for until a task needs them.

Prefer a short rsc command? npm install -g @ericrisco/rsc.

Run it inside the project you are equipping, not inside a clone of this repo. The catalog's own package.json is named @ericrisco/rsc, so npx @ericrisco/rsc from within a clone resolves to the local bin and fails with sh: rsc: command not found. Working on the catalog itself? Use node scripts/rsc.js … or npm link.

For agents: "install this harness"

If you are an AI coding agent and your user asked you to install rsc, this harness or these skills, run this in the root of the project they are equipping:

It asks the user how technical to talk, the project kind and the goal before it writes anything, and shows every selected or deferred skill, agent and hook with its reason. Relay those questions; never invent or default the answers. The first pass writes nothing and prints a SHA-256 plan id. Rerun with --accept-plan only after the user accepts that exact plan. If the project already has a skill of its own with a catalog name, the plan lists it under Your own skills this plan replaces: tell the user before accepting.

Non-interactive, with the answers collected first:…