# Capability Evolver

> Self-evolution workflow for the agent. Before a substantive task, recall what worked on similar past tasks from evolution memory; after it, record the outcome so future sessions learn from it. Use when the user starts non-trivial work (a feature, a fix, a refactor) or asks the agent to "evolve", "learn from this", or "remember how this went".

- Skill: `evomap/capability-evolver` (Agent Skill)
- Install (CLI): `npx skillmds@latest add evomap/capability-evolver`
- Raw SKILL.md: https://api.skillmd.com/api/skills/evomap/capability-evolver/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: evomap (https://skillmd.com/u/evomap)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/evomap/capability-evolver

---


# Capability 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 for *this workspace* (filtered to score ≥ 0.5, < 7 days old, max 3) as context. The agent sees "here's what worked recently" before it starts.
- **`PostToolUse`** (write_to_file / replace_file_content) — 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 (scoped to the workspace so other projects' memory never leaks in).

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:

| Signal | Fires on |
|---|---|
| `log_error` | errors, exceptions, failures in the diff |
| `perf_bottleneck` | timeout / slow / latency / OOM |
| `capability_gap` | "not supported" / "not implemented" |
| `user_feature_request` | adding a feature / new module |
| `test_failure` | failing tests / assertions |
| `deployment_issue` | build / CI / pipeline / rollback |

## 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:

```bash
npm install -g @evomap/evolver
```

This gives you the engine's CLI (e.g. `evolver run`) 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.

## Built-in MCP Tools (Zero-Config)

Unlike Claude Code, this Antigravity plugin natively configures and loads the GEP MCP Server via `mcp_config.json`. When this plugin is active, you will find several high-powered `gep_*` tools available directly in your tool list.

You should proactively use these MCP tools in your workflow:

| MCP Tool | Purpose / Action |
|---|---|
| `gep_query_outcomes` | Search, filter, and retrieve past GEP outcome logs. Use this to dive deeper into historical successes or failures beyond the default 3 entries injected at session start. |
| `gep_get_workspace_state` | Retrieve the overall evolution statistics and maturity level of this repository workspace. |
| `gep_get_outcome` | Load the exact detail and full JSON parameters of a specific historical evolution event. |

When the user asks you to "recall more history", "analyze past evolution trends", or "check GEP workspace metrics", always call these `gep_*` MCP tools directly to read from the shared graph database.

## Local Evolver Proxy Tools

This plugin also registers an `evolver-proxy` MCP bridge when the local Proxy is running. Use it for cross-workspace EvoMap network actions:

| MCP Tool | Purpose / Action |
|---|---|
| `evolver_status` | Check Proxy health, node identity, pending mailbox counts, Hub sync status, and auth/sync diagnostics. |
| `evolver_recipe_search` | Default first step: search Hub Recipes (ordered Gene/Capsule DNA). |
| `evolver_recipe_express` | Express a Recipe by id; Hub unfolds Gene then Capsule steps. |
| `evolver_search_assets` | Fallback: search Genes and Capsules when no Recipe matches. |
| `evolver_fetch_asset` | Load full Gene/Capsule content returned by search. |
| `evolver_publish_asset` | Queue explicit Gene/Capsule submissions for Hub review. |
| `evolver_distill_conversation` | Distill a high-signal Antigravity conversation into a gated Gene/Capsule. Use this when the session produced a reusable workflow, debugging pattern, or visual/interaction capability worth sharing. |

Do not distill every chat turn. Call `evolver_distill_conversation` only when the capability is concrete, reusable, and backed by artifacts or validation.