Stores durable facts in a categorized, plain-markdown vault on disk, alongside your agent's built-in memory.
Coding
Rotifer Self-Evolving Agent
Try itRank an Agent's Rotifer Genes against the Arena and swap in stronger ones. Invoked explicitly via /evolve — scan local capabilities, compare Genes, inspect fitness scores, and replace weak ones with user approval. Not for capabilities outside Rotifer.
What it does
Your Agent gets stronger by competing, not by configuring. Scan capabilities, benchmark against Arena rankings, and upgrade to fitter alternatives — driven by objective performance data, not opinions.
The skill document
Rotifer Self Evolving Agent
Your Agent gets stronger by competing, not by configuring. Scan capabilities, benchmark against Arena rankings, and upgrade to fitter alternatives — driven by objective performance data, not opinions.
Runtime Integration
This skill is invoked with /evolve and uses the Rotifer MCP Server at runtime:
npx @rotifer/mcp-server@0.16.0 --tools=evolve
--tools=evolve is not decoration. The server can expose 31 tools, including
publish_gene, login and arena_submit; this Skill needs ten, so ten is what
it asks for. The rest are not listed and are refused if called. Nothing here can
publish on your behalf or log you in.
The launch line also omits --allow, so the sandbox escapes (no_sandbox,
trust_unsigned) are refused. Ten tools with an escape hatch in one of them
would not be ten tools.
Quick Start
Evolve Your Agent
Scan your Agent's current setup and get upgrade recommendations:
/evolve
This analyzes your local Agent configuration, identifies capabilities below Arena median, and recommends higher-performing replacements.
Check Agent Status
View your Agent's capability dashboard:
/evolve status
Shows all installed capabilities, their fitness scores, and overall Agent health.
Upgrade a Capability
Replace a capability with a stronger alternative:
/evolve upgrade
Finds the top-ranked alternative in the same domain, shows you the swap, and installs it only after you approve. This is the one command that changes what is installed: it replaces a Gene in the project's genes/ directory with third-party code from the marketplace, which changes what your Agent does at runtime. create-agent writes an Agent definition and run-agent executes one; every other /evolve command is read-only.
Genes are project files, not global ones. Install into the project the user is in — do not pass project_root to install_gene unless the user names a different project, and say which directory the Gene is going into when you propose the swap.
Overwriting is now undoable, so it is allowed again.
install_genewithforce: truemoves the replaced Gene into/.snapshots/before writing. Say so when you use it, and tell the user the two ways back:rollback_genehere, orrotifer rollbackin a terminal. One snapshot per Gene — the next overwrite of the same Gene supersedes it, and a rollback consumes it, so this undoes the last upgrade rather than a history.
Discovery & Comparison
Discover Capabilities
Find capabilities by what you need, not by internal names:
/evolve discover web scraping
/evolve discover --domain code.format
/evolve discover --fidelity Native
Compare Candidates
Side-by-side fitness comparison:
/evolve compare
Arena Rankings
See top performers in any domain:
/evolve arena search.web
/evolve arena code.format
Inspect Details
Full technical details for a specific capability:
/evolve inspect
Agent Management
Create a New Agent
/evolve create-agent
Run Your Agent
/evolve run-agent
This executes the Agent's Genes — it is not a read-only command. Execution goes through the rotifer CLI (or an npx -y @rotifer/playground fallback) and stays inside the WASM sandbox. It also leaves two traces on disk: a line per Gene execution in ~/.rotifer/run-logs/.jsonl, and a fitness state file next to the Agent definition. Both are local; neither is transmitted. Never pass no_sandbox: the server refuses it unless launched with --allow=no-sandbox, which this Skill does not do. Running a Gene as plain Node.js is something the user does themselves, with rotifer agent run --no-sandbox.
How it Works
Under the hood, Rotifer uses Genes — atomic, transferable AI capabilities that compete in an Arena. The fittest Genes (measured by the fitness function F(g)) rise to the top of the rankings automatically. Ranking is the automatic part; putting a Gene on your machine is not.
F(g) = [S_r · ln(1 + C_util) · (1 + R_rob)] / [L · Resource_Cost]
No voting, no human preference — pure runtime performance metrics determine which capabilities win.
Capability Types (Fidelity)
| Type | Description |
|---|---|
| Native | Pure WASM — fully sandboxed, highest security |
| Hybrid | WASM logic + controlled external calls |
| Wrapped | Thin envelope around an external API |
What "Evolve" Actually Does
When you run /evolve, the assistant:
- Lists your local Agent's installed Genes (
list_local_agents+list_local_genes) - Checks each Gene's fitness against Arena rankings (
get_gene_detail+get_arena_rankings) - Identifies Genes scoring below the domain median
- Searches for stronger alternatives (
search_genes) - Presents a ranked upgrade plan with fitness comparisons
No Gene is replaced without your confirmation.
Security & Transparency
Runtime dependency
This Skill runs @rotifer/mcp-server@0.16.0 via npx at runtime. The package is fetched from npm on first use and cached locally. This is a standard MCP Skill pattern but means you are trusting remote code — review the source before use.
/evolve run-agent is a second such path: it invokes the rotifer CLI, and when that is not on PATH it falls back to npx -y @rotifer/playground.
- Source code: github.com/rotifer-protocol/rotifer-mcp-server
- Verify:
npm view @rotifer/mcp-server@0.16.0 dist.integrity
Network requests
Gene, Arena and profile queries go to the Rotifer public API at rotifer.dev (hosted on Supabase). Beyond that the MCP server makes one version check per day against registry.npmjs.org, caching the answer in ~/.config/rotifer/update-check.json; npx reaches the same registry when it fetches or refreshes a package.
Usage telemetry. When you are logged in, the MCP server reports each tool call to Rotifer Cloud, fire-and-forget: the tool's name, the Gene id the call acted on (when there is one), whether it succeeded, its latency in milliseconds, and your Rotifer user id. That is what get_mcp_stats reads back. Running a Gene while logged in also records that invocation, as the protocol's anti-manipulation metrics depend on it.
Logged out, no usage record is sent. One thing goes out either way: installing a Gene bumps that Gene's public install counter — a single request carrying the Gene id and nothing else, no user id and no session. It is how the Arena counts installs.
ROTIFER_TELEMETRY=0 stops all three (false and off work too; any other value is not an opt-out). Until @rotifer/mcp-server@0.16.0 it did not stop the install counter, and this section said "logged out, nothing is reported", which was not true of an install.
What is not sent: the arguments you pass, the contents of any file, your environment variables, and your local configuration. The three are logMcpCall, logGeneInvocation and the track_download call inside installGene, all in src/cloud.ts — short enough to read in full. Nothing else here reports on its own initiative: every other outbound call is a tool you invoked doing its job, the WASM artifact download, or the daily version check above.
Credentials
Public Gene and Arena data needs no login: the MCP server reads it with the Supabase anon key (a public, client-safe key protected by Row Level Security). It does not read your environment variables, nor secrets belonging to any other tool.
This Skill cannot log you in: login is not in its tool set. If you have logged in elsewhere — rotifer login in a terminal — that session token lives in ~/.rotifer/credentials.json with 0600 permissions, is sent only to the Rotifer API, and rotifer logout deletes it. Genes and Agents do not live there — they are project files, described below. The one other thing that lands under ~/.rotifer/ is a run log, written when you use run-agent; it never leaves your machine. Being logged in is what turns usage reporting on; see above.
Local data access
-
Reads installed Genes under
genes/, and Agent definitions under.rotifer/agents/— both in the current project — to generate upgrade recommendations. -
Local configuration is designed not to be transmitted to any server. Comparison logic runs locally against data fetched from the public API. The only thing that leaves the machine beyond your queries is the usage record described under Network requests — tool name, Gene id, outcome, latency, user id — sent only while you are logged in, and nothing beyond it. You can verify both by inspecting the source code.
-
Writes are four things and nothing else:
- Genes into
genes/(install_gene), and the copy an overwrite replaces intogenes/.snapshots/ - Agent definitions into
.rotifer/agents/(create_agent), and a fitness state file beside them when you run one - a run log at
~/.rotifer/run-logs/.jsonl(agent_run) — one line per Gene execution, mode0600, rotated at 10 MB, never transmitted - the update-check cache above
The first two are project files, written under a project root — not into your home directory. That root defaults to the directory the server was started in,
rotifer.json'sgenes_dircan renamegenes/, andinstall_genetakes aproject_rootargument, so the destination is whichever project the call names; these commands name the current one. Nothing else on disk is modified, and no Gene is installed, replaced, or removed without explicit user confirmation. - Genes into
-
An overwrite is recoverable.
install_genewithforcemoves the replaced copy into/.snapshots/before writing;rollback_generestores it, and so doesrotifer rollbackfrom a terminal — both write the same format. One snapshot per Gene: the next overwrite supersedes it, a rollback consumes it. -
Removing this Skill does not uninstall Genes it installed. They stay in that project's
genes/directory as ordinary Genes;rotifer uninstallremoves one, and that is undoable through the same snapshot.
Tool surface
The MCP server can expose 31 tools, covering compiling, publishing, Arena submission and login. This Skill launches it with --tools=evolve, which exposes ten:
search_genes · get_gene_detail · get_arena_rankings · compare_genes · install_gene · rollback_gene · list_local_genes · list_local_agents · create_agent · agent_run
The other 21 are not listed and are refused if called anyway, so what the assistant can reach through this Skill is the ten above and nothing else. Until version 2.4.0 all 31 were reachable — if you have an older copy, that is what it does.
The ten cover the whole surface, not just the tool list. The server also serves resources — read-only URIs returning the same data as tools of the same name — and those travel with the set: three of the seven (rotifer://genes/{id}/stats, rotifer://developers/{name}, rotifer://leaderboard) are dropped from the listing and refused if read directly, because their tools were not asked for. Until @rotifer/mcp-server@0.16.0 they were readable whatever the tool set said. Prompts are not restricted, and are not meant to be: a prompt returns text and reaches nothing — no query, no file, no process.
You can check rather than take our word for it: npx @rotifer/mcp-server@0.16.0 --tools=evolve and ask it to list its tools.
Permission justification
network:outbound— query Arena rankings, Gene metadata and fitness scores from the Rotifer public API, and fetch the MCP server package itself from npm.filesystem:read— read the project's installed Genes and Agent definitions, which is what an upgrade recommendation is computed from.filesystem:write— install and roll back Genes, write Agent definitions, and append the run log and update-check cache described above.process:exec—run-agentexecutes through therotiferCLI, ornpx -y @rotifer/playgroundwhen the CLI is not installed.
Until version 2.4.3 this list said network:outbound and nothing else, while the Skill already read and wrote project files and shelled out to a CLI. The behaviour was described in the sections above but the declaration was narrower than the behaviour, which is the same defect as asking for ten tools and being able to reach thirty-one.
Links
Related skills
Join a video meeting as an AI bot with voice, avatar, and screenshare across four operating modes.
Save, search, and manage personal notes and knowledge bases in Get笔记 on explicit request.
Generate and edit Draw.io, Mermaid, and Excalidraw diagrams from natural language using a structured JSON spec.
Fetch raw ad creative, app, ranking, and revenue data from AdMapix as structured JSON.
Find why your productivity system keeps failing, then apply the smallest fix — capacity math, bottleneck routing, durable local notes.
More from xiaoba-dev
Browse all skillsRoute any Rotifer request to the right sub-capability — onboarding, scaffolding, diagnostics, search, or fidelity upgrade.
Build a Rotifer Agent from existing Genes through a 7-phase workflow of decomposition, composition, creation, and testing.
Compare two Rotifer Genes head-to-head and get a Markdown report with F(g) fitness and V(g) security grades.
Cross-vendor adversarial review. WARNING — this sends your brief, and any source files you approve, to a model hosted by a THIRD-PARTY vendor, where it stays in that vendor's session history under their retention terms. Ship a plan, proposal, or design to a model from a DIFFERENT vendor to attack it; every objection carries a verifiable anchor; the defender rules with an evidence tag on each ruling; the final round classifies into still-disputed / unresolved / verified-consensus instead of forcing agreement; a fresh-session judge is mandatory whenever the outcome looks too clean. Invoke only when the user explicitly asks for an adversarial review by a model from another vendor. One model role-playing several experts is not this skill.
Session knowledge distillation: assign what you just learned in this session into an agent's four-layer persistent knowledge base (rule / memory / skill / decision record). The core is four disciplines — search before adding, pick the right layer, guard against bloat, and run a hygiene pass before landing anything. Fits agent workflows that already have (or want to build) these four layers; this is not a general note- taking tool. Invoke explicitly at the end of a session to consolidate what was learned.
Installs a documentation governance architecture in a project and diagnoses what it is missing. Three actions: audit diagnoses the current state against seven components (source-of-truth layering / decision records / cascade discipline / planning system / checkpoints bound to actions / gates / incident traceability); init installs what is missing (config, a script copy, a pre-commit gate, two Claude Code hooks, decision and plan templates); check keeps verifying that what the docs claim about reality still holds (TODOs left hanging too long, cascade memos never carried out, plan status that doesn't match reality, broken references, broken links, § section references pointing to the wrong place, missing index entries, broken tables, endpoints the docs declare but the code doesn't have). The framework was distilled from the documentation system of a large protocol project, and every check is tied to a real incident. ⚠️ init modifies the repository and installs hooks that keep running aft