DEV Community

Cover image for Rotifer v0.5: Reputation, Skill Import & P2P Foundation
Rotifer Protocol
Rotifer Protocol

Posted on • Edited on • Originally published at rotifer.dev

Rotifer v0.5: Reputation, Skill Import & P2P Foundation

Rotifer Playground v0.5.0-alpha.2 introduces three pillars every AI capability ecosystem needs: trust, portability, and decentralization.

Skill Import: From IDE to Ecosystem in One Command

AI IDE skills (the SKILL.md files in Cursor, Codex, Windsurf, etc.) are powerful but trapped in local directories. They can't be shared, versioned, compared, or improved through competition. Rotifer v0.5 bridges this gap:

rotifer scan --skills                          # discover local SKILL.md files
rotifer wrap my-skill --from-skill ./SKILL.md  # convert to a Rotifer gene
rotifer compile my-skill                       # validate
rotifer publish my-skill                       # share with the world
Enter fullscreen mode Exit fullscreen mode

Your locally crafted skills now have an identity, a fitness score, and an evolutionary future.

How Skill Import Works

The wrap --from-skill command performs a structured conversion. It parses the SKILL.md file, extracts the instruction content, and wraps it as a Rotifer gene with a proper phenotype. The gene's express function takes a user prompt and returns the skill's instructions formatted as context for an LLM.

This is deliberately a one-way bridge with a return path. You can also export a Rotifer gene back to a SKILL.md file using rotifer export --as-skill. This bidirectional conversion means skills can enter the Rotifer ecosystem (gaining fitness scoring, Arena ranking, and cloud distribution), compete and improve, and then return to their original format — better than when they left.

The conversion preserves the original skill's content verbatim. Rotifer adds structure (phenotype schema, domain classification, metadata) but never modifies the instructions themselves. Your prompt engineering is yours.

Reputation System

Every Gene and developer now earns a computable reputation — the gene reputation score R(g):

R(g) = 0.5 · Arena + 0.3 · Usage + 0.2 · Stability
Enter fullscreen mode Exit fullscreen mode
rotifer reputation <gene-ref>     # gene's reputation score
rotifer reputation --mine        # your developer reputation
rotifer reputation --leaderboard # global developer rankings
Enter fullscreen mode Exit fullscreen mode

5% monthly decay keeps the leaderboard fresh — ship or slide.

Why This Formula?

The three components capture different quality signals:

  • Arena (50%) — direct head-to-head performance against competitors. This is the strongest signal because it's measured under controlled conditions with standardized inputs.
  • Usage (30%) — how often other developers install and execute the gene. Popular genes that solve real problems earn more reputation. But usage alone can't dominate — a widely-installed gene that performs poorly in the Arena still loses reputation overall.
  • Stability (20%) — how consistently the gene performs over time. A gene that scores well once and then degrades is less valuable than one that delivers reliable results across versions.

The 5% monthly decay is a deliberate evolutionary pressure. Without decay, early movers would permanently dominate the leaderboard. With it, even high-reputation genes must continue performing to maintain their position. This mirrors biological fitness landscapes where static organisms are outcompeted by adaptive ones.

P2P Gene Network (Foundation)

The foundation for decentralized gene discovery is in place:

rotifer network start   # spin up a local P2P node
rotifer network peers   # see connected peers
rotifer network search  # cloud-first, P2P-augmented discovery
Enter fullscreen mode Exit fullscreen mode

This is the metadata layer. Full P2P gene transfer is on the roadmap.

Why a Stub?

P2P networking is complex. libp2p alone brings 50+ transports, protocols, and configuration options. Implementing it prematurely would mean either shipping a fragile system or delaying the features developers actually need today (reputation, skill import, cloud registry).

The v0.5 stub establishes the network interface contract — the commands, the data formats, the discovery semantics — without committing to a specific P2P implementation. When we build the real P2P layer in v0.9, the CLI commands and developer experience won't change. Only the transport beneath them will.

This is the Rotifer way: define the interface first, implement later. The same pattern applied to IR (interface in v0.1, implementation in v0.2) and Cloud Binding (interface in v0.3, implementation in v0.4).

Cloud Binding

The official Cloud endpoint is live at cloud.rotifer.dev. Self-hosting is fully supported via the ROTIFER_CLOUD_ENDPOINT environment variable.

By the Numbers

  • 20 CLI commands
  • 165 tests passing
  • 31 files changed, +2,110 lines
  • 20+ documentation pages (EN + ZH)

What These Foundations Enable

Trust, portability, and decentralization are not features — they are prerequisites. Without trust (reputation), developers cannot distinguish good genes from bad ones at scale. Without portability (skill import), the ecosystem starts empty and stays empty. Without decentralization (P2P foundation), the protocol depends on a single cloud provider.

v0.5 assembled these three pillars simultaneously because they reinforce each other. Reputation scores are only meaningful when there are enough genes to compare — which skill import provides. Skill import is only useful when imported genes can be evaluated — which reputation enables. And both features work best when they are not gated by a single registry — which the P2P stub prepares for.

This release marked the transition from "can you build genes?" to "can you build an ecosystem?" The answer required trust infrastructure, not just developer tooling.

Get Started

npm install -g @rotifer/playground
Enter fullscreen mode Exit fullscreen mode

Top comments (0)