recursive-improve

A staged process for improving an AI agent from execution traces. Execution traces are saved records of the agent's messages, tool calls, and outcomes.

In plain words
What is it for?
Use it to analyze traces, gather relevant domain context, define metrics, build a review rubric, propose improvements for approval, and implement the approved changes.
Why use it?
It turns past runs into documented lessons, measurements, review criteria, and a prioritized improvement plan. It also checks whether the required trace files and earlier analysis already exist before starting.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/kayba-ai/recursive-improve/data
Any agent
npx skills add kayba-ai/recursive-improve --skill data
Clone the repo
git clone --depth 1 https://github.com/kayba-ai/recursive-improve

Made for: Claude Code, Codex.

Per session 89 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 6,426 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00089 $0.06426
Opus 5 $0.00044 $0.03213
Sonnet 5 $0.00018 $0.01285
Haiku 4.5 $0.00009 $0.00643

Measured 2d ago against content hash 773d3322982a, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

recursive-improve scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

The scan reads SKILL.md. This mod also ships 1 executable file (__init__.py), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

recursive_improve/data/SKILL.md · 747 lines

How it starts

The opening of the file, as written. The whole thing — 747 lines — stays where its author put it; the contents beside it link to each section on GitHub.

recursive-improve: Agent Improvement Pipeline

End-to-end pipeline: trace analysis → skill extraction → domain context → metrics → rubric → action plan → review → fixes.

Prerequisites

Traces must exist in eval/traces/. If they don't:

  • Ask the user for their traces directory
  • Copy .json, .md, and .toon files into eval/traces/

Skip condition: If eval/stage1_insights_summary.md already exists (from a prior run or from recursive-improve analyze), skip Stages 0 and 1 — go directly to Stage 2.


Stage 0: Trace Analysis

Analyze raw execution traces to extract learnings. This stage adapts ACE's recursive reflector methodology — a structured 6-phase strategy that moves from data discovery through verified deep-dives to synthesized, evidence-backed insights.

Inputs

  • eval/traces/ — raw trace files (.json, .md, .toon)

Phase 1: Discover

Map the data shape and inventory. Do NOT judge outcomes yet — just catalog what you have.

  1. Read 2-3 trace files. Identify:

    • Top-level keys and message schema (3 levels deep)
    • Message format: role, content, tool_calls, turn_idx, etc.
    • Total trace count and per-trace message counts
  2. Search for agent operating rules, policy, or instructions embedded in the traces — these are often in large strings (>500 chars). Check:

    • role: "system" messages
    • info.environment_info.policy or similar fields
    • Large embedded strings in any field
  3. Build an inventory table:

    File                  Messages  Has system prompt?  Has tool calls?
    trace_001.json        42        yes                 yes
    trace_002.json        18        yes                 no
    ...
    
  4. Record discovered rules/policy verbatim — understanding what the agent was supposed to do is essential for evaluating what it actually did.

Phase 2: Derive Evaluation Criteria

Based on your discovery (schema, rules, patterns), define specific evaluation criteria to apply to every trace during the survey phase.

Read the full file on GitHub · 747 lines

Files

What ships with it

4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 747 lines · 89 tokens per session scan A 773d3322982a

Subscribe to this mod's changes

recursive-improve is a skill published in the GitHub repository kayba-ai/recursive-improve (251 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 89 tokens to every session and 6,426 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

lanes

Start, restart, stop, and check loop lanes as named background Claude Code sessions seeded from canonical prompt files, the scripted replacement for the manual morning refresh (cancel loop, clear, re-paste the canonical prompt) across N lanes on a machine. start/restart first pull the repo and refresh the plugin…

melodic-software/claude-code-plugins · 195 tokens

audit-install-state

Read-only audit of a Claude Code INSTALLATION directory, the machine-scope /.claude tree plus /.claude.json. Inventorying every file, separating what the product's own retention sweep already manages from what nothing manages, resolving what each number in a filename actually means before any process-liveness check…

melodic-software/claude-code-plugins · 222 tokens

audit-native-overlap

Map native Claude Code surfaces, built-in CLI commands, bundled skills, plugin-backed built-ins, session-provided skills, against the current repo's plugin skills and agents, so a custom component never silently duplicates what Claude Code itself now ships. Bare invocation is a READ-ONLY report: overlap candidates…

melodic-software/claude-code-plugins · 260 tokens

audit-automation-gaps

Audit a repo's Claude Code automation landscape, covering hooks, MCP servers, skills, subagents and scheduled tasks, against the enforcement hierarchy, producing PASS/REJECT/CONDITIONAL verdicts backed by evidence. The default verdict is REJECT because most gaps are already covered by compiler/analyzer/build-time…

melodic-software/claude-code-plugins · 126 tokens

audit-prompting-postures

Audit locally-owned instruction components, including skill bodies, agent definitions, hook instruction text, output styles, CLAUDE.md and rules, for MISSING posture guidance the official prompting guide says their purpose needs: delegation criteria/caps in orchestration components, minimal-scope and anti-test-gaming…

melodic-software/claude-code-plugins · 250 tokens

audit-skill-visibility

Audit whether each installed skill is actually VISIBLE to the model, and diagnose why most of a fleet never gets used. A skill is invisible when its description is dropped by the skill-listing context budget (Claude Code drops descriptions by a decay-weighted usage score, so an unused skill loses the keywords that…

melodic-software/claude-code-plugins · 312 tokens