Evolver

Evolver

This plugin gives the agent a persistent, auditable evolution memory built on the Genome Evolution Protocol (GEP). The goal is simple: stop re-solving the same problem from scratch. Past outcomes — what worked, what failed — are carried forward into future sessions.

How it works (automatic)

Three hooks run on their own; you don't invoke them:

• sessionStart — injects a short summary of recent successful outcomes (filtered to score ≥ 0.5, < 7 days old, max 3) as context. The agent sees "here's what worked recently" before it starts.
• afterFileEdit — scans edits for improvement signals (log_error, perf_bottleneck, capability_gap, test_failure, …) and nudges the agent to record the outcome when relevant.
• stop — at the end of a task, collects the git diff, classifies the outcome, and appends it to the evolution memory graph.

Memory is written to a local JSONL graph. With no extra setup it lands in ~/.evolver/memory/evolution/memory_graph.jsonl; inside an evolver-managed project it lands under that project's memory/evolution/.

What you (the agent) should do

For any substantive task — a feature, a non-trivial fix, a refactor:

1. Before starting, check the injected evolution memory (it arrives as session-start context). If a recent successful outcome matches the task, reuse that approach. If a recent failure matches, avoid repeating it.
2. Do the work.
3. After finishing, the stop hook records the outcome automatically. You don't need to call anything — but if the task had a clear lesson worth a one-line note, say so in your final message so it's captured in the diff context the hook reads.

Trivial or purely conversational turns don't need this — skip it.

Signals

The hooks classify work by signal. Knowing the vocabulary helps you describe outcomes in terms the memory graph indexes well:

Full pipeline (optional)

The bundled hooks record outcomes and recall them — that works on its own. To get the full evolution engine (automated log analysis, the review-and-solidify cycle that proposes and applies code improvements), install it:

npm install -g @evomap/evolver@2

This gives you the engine's CLI (e.g. evolver run, surfaced as the /run command) to run that pipeline separately — the hooks do not auto-detect or invoke it. The memory the hooks record is what the pipeline consumes. See the plugin README for connecting an EvoMap Hub node for community strategies.

MCP tools

This plugin bundles a lightweight MCP bridge (evolver-proxy) exposing the local EvoMap Proxy mailbox:

• evolver_recipe_search — default first step: find Hub Recipes (ordered Gene/Capsule DNA). Call this before substantive networked work.
• evolver_recipe_express — express a Recipe by id. Hub unfolds Gene then Capsule steps; do not parse recipe JSON locally.
• evolver_search_assets — Fallback: find genes/capsules by free-text query and/or signal keywords when no Recipe matches.
• evolver_status — Proxy state (node id, pending counts, last sync).
• evolver_fetch_asset / evolver_report_reuse / evolver_publish_asset / evolver_distill_conversation / evolver_poll.

After evolver_fetch_asset, if you actually reuse an asset, call evolver_report_reuse with those IDs so the original author gets credit.

Use evolver_distill_conversation only when the current Cursor conversation produced a concrete reusable capability. Include a summary, strategy steps, artifact paths/links, and validation evidence so the Proxy can reject weak or noisy candidates.

The tools degrade gracefully when the Proxy isn't running (the local memory hooks still work). The richer, full gep_* surface is the separate @evomap/gep-mcp-server — add it to your MCP config if you want it; the two compose.