trampoline-ai/predict-rlm/rlm-gepa
Claude Code and agent skill by trampoline-ai/predict-rlm
- community
Checking that the SKILL.md file is still in the repository.
Add, evaluate, and optimize RLM-GEPA projects for an existing PredictRLM. Use when a user wants to improve reusable RLM instructions from execution traces, build a train/validation optimization harness, configure AgentSpec or OptimizeConfig, run optimize --check, or inspect RLM-GEPA run artifacts. For creating the base RLM itself, use rlm first.
Install
npx vskill@latest install trampoline-ai/predict-rlm/rlm-gepaSKILL.md
Optimize an RLM with RLM-GEPA
RLM-GEPA improves reusable text components, usually a Skill.instructions string, using scored executions of a real PredictRLM. It is not a replacement for initial RLM design. Start only after the base RLM has a concrete signature, tools, a measurable outcome, and a working smoke path.
The system has two loops:
- Executor loop — run each candidate RLM against train or validation
examples, collecting outputs, RunTrace objects, scores, and feedback.
- Proposer loop — use scored traces to make a surgical edit to a declared
mutable component.
AgentSpec controls which transferable behaviors the proposer may improve. OptimizeConfig controls budget, concurrency, models, and search behavior. Keep those concerns separate.
Workflow
Step 1: Confirm optimization fit
Use RLM-GEPA when the user wants a reusable behavior to improve and can provide:
- a working PredictRLM with its real DSPy signature and tool surface;
- a text component worth optimizing, such as domain skill instructions;
- representative examples and a deterministic or carefully designed score;
- concrete feedback for imperfect outputs.
Do not optimize a vague prompt before the base RLM works. First fix functional bugs, missing tools, weak output schemas, and unsupported sandbox dependencies. Do not use GEPA for a one-off answer or a generic chat-agent prompt.
Step 2: Audit data and split boundaries
Inspect examples before coding loaders or split logic. Identify input shapes, reference-output shape, duplicates, shared source groups, missing labels, and failure modes the score should expose.
Use consistent semantics:
- Train — examples available to proposer and candidate-gating work.
- Validation — examples used to select candidates and catch regressions.
- Held-out test — optional reporting-only data. Do not leak it into prompt
text, proposer traces, candidate selection, or optimization feedback.
Prefer deterministic splits. Record the seed, grouping key, counts, and sampling limits. Split by document, user, task family, or source whenever related rows would otherwise leak across train and validation.
Keep the evaluator harness-side. The RLM may use safe task tools and documents, but it must not see hidden answer keys, oracle APIs, or evaluator feedback while solving an example.
Step 3: Define the mutable component and AgentSpec
Build the concrete RLM first. Derive its signature and tools with agent_spec_from_rlm(...); do not duplicate those broad descriptions manually. Add only context that the RLM cannot reveal:
- at least two distinct
use_casesdefining the transfer boundary; - at least three nonempty
runtime_grounding_examplesgroups containing stable
runtime facts;
scoring_descriptionexplaining score, partial credit, and hard failures;- optional
counterfactual_axis_name(domains,task shapes,failure modes,
task types, or problem classes) and an anti-hack domain_conventions_note.
A useful AgentSpec teaches grounded behavior, not benchmark trivia. Name actual tool contracts, library symbols, sandbox facts, and evaluator-visible failure surfaces. Do not key instructions on task IDs, file names, row counts, or answer artifacts.
Step 4: Implement the project contract
Subclass RLMGepaProject. Its contract is intentionally small:
seed_candidate()returns exactly the declared component keys and nonempty
seed text.
load_trainset()andload_valset()return nonempty sequences.evaluate_example()runs the candidate RLM, scores it, and returns a finite
RLMGepaExampleResult with feedback, traces, separate evidence, stable example_id, and useful rlm_inputs.
For an imperfect result, feedback must be nonempty. Good feedback identifies the actual failing surface: page, cell, clause, tool response, assertion, timeout, or schema mismatch. It describes what happened, not replacement prompt text.
Successful PredictRLM predictions always provide trace: RunTrace and evidence: RunEvidence. Forward each run's result.evidence independently of result.trace, retaining both if scoring the completed run fails. On run failures, recover available evidence through predict_rlm.evidence.extract_evidence_from_exc alongside trace extraction, including through cancellation/timeout cause chains. Exceptions can lack either artifact. Incomplete captured evidence is rejected; fake successful predictions must provide both complete artifacts.
Override task_timeout_for_example(example, default_timeout) or task_resources_for_example(example) only when the workload genuinely has per-example timeout or resource needs. Override minibatch_group_id(example) when grouped examples must be sampled together.
Step 5: Configure the project CLI
Keep optimization code local to the generated project:
Install the required extra and expose the project CLI:
Set model, budget, concurrency, timeout, selection, merge, and telemetry choices in OptimizeConfig or explicit CLI flags. Do not hide experiment behavior behind environment-only switches.
Step 6: Verify before spending a budget
First validate the project without a real search:
Then use a small budget to validate the full loop. Only increase max_metric_calls, minibatch_size, or concurrency after the trace, score, and cost surfaces are trustworthy.
Useful commands:
plot additionally requires the gepa-viz extra: predict-rlm[gepa,gepa-viz].
Optimization writes run_metadata.json, gepa_state.bin, optimization_summary.json, all_candidates.json, task and proposer traces, and cost_log.jsonl beneath the run directory. Treat those artifacts as the evidence for accepting a candidate, not a single aggregate score.
Guardrails
- Optimize only declared text components; do not let GEPA alter code, evaluator
logic, data splits, or hidden answer access.
- Keep task execution and scoring deterministic where possible.
- Use the shared RLM-GEPA adapter semantics for concurrent evaluation rather
than creating ad hoc task loops; it owns concurrency, timeouts, traces, progress, resources, and cost accounting.
- Use
--verbose-rlmfor human-readable RLM rollout traces and--debug-rlm
for lifecycle diagnostics.
- Keep train evidence, validation selection, and held-out reporting separate.
- Treat patch merge as evidence-backed behavioral grafting from trace
disagreement, never prompt concatenation or broad source-text import.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/rlm-gepa/SKILL.md
Popularity
- Repository stars
- 435
- Repository forks
- 47
- 7-day trend score
- 0
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/trampoline-ai/predict-rlm/rlm-gepa)