recall_k=20 do during a sleep cycle?dream_factor (synthetic variants) or dream_rollouts (repeated runs). recall_k is associative recall: pull K similar past tasks from the archive into the current dream batch.The gate tells you whether an edit improves held-out accuracy. But does the deployed skill actually make your daily agent better? Gates operate on synthetic benchmarks — your real workflow is noisier, more varied, and harder to measure. This lesson covers how to confirm your skill is delivering value in the real world.
From SkillLens: format and plausibility don't predict utility. A skill that reads well can be neutral or harmful. The only reliable signal is empirical: does the agent produce better outputs with the skill than without? This applies after deployment too — not just during training.
Without a gate, 25% of extracted skills degrade performance. Even with a gate, you should verify post-deployment — the gate validates on a held-out split that may not perfectly represent your daily tasks.
Before deploying a new skill, capture a baseline on your real tasks:
# Evaluate with NO skill (empty system prompt)
python scripts/evaluate.py \
--config configs/my_env/default.yaml \
--skill /dev/null \
--split test
# Evaluate with your trained skill
python scripts/evaluate.py \
--config configs/my_env/default.yaml \
--skill outputs/my_env/skills/best_skill.md \
--split test
Record both scores. The delta is your measured lift.
Run the same evaluation 3 times (same skill, same test split). The variance between runs is your noise floor. If your measured lift is smaller than 2× the noise floor, you can't confidently distinguish signal from random variation.
# Run 3 times, record scores
for i in 1 2 3; do
python scripts/evaluate.py \
--config configs/my_env/default.yaml \
--skill outputs/my_env/skills/best_skill.md \
--split test 2>&1 | grep "score"
done
From the Sleep README: "single-seed baseline variance is ±1–2 pts, so treat sub-~1.5pt differences as noise." If your lift is +4pp with ±1pp variance, you have real signal.
For real-world measurement, alternate days:
| Day | Skill | Track |
|---|---|---|
| Monday | Deployed skill | Task success rate, time to completion |
| Tuesday | No skill (empty) | Same metrics |
| Wednesday | Deployed skill | Same metrics |
| Thursday | No skill | Same metrics |
After a week, compare. This is crude but catches the big signal: is the skill helping with your actual daily tasks, not just the held-out benchmark?
For pi: rename ~/.pi/skills/best_skill.md to .bak on
off-days. For Kiro: move the steering file out of .kiro/steering/. For
Claude Code: comment out the skill section in CLAUDE.md. No restart needed.
From SkillLens: embedding the quality rubric into the extractor prompt itself yields +1.55pp on average — the optimizer produces better proposals when it knows what "good" looks like. This is the meta-skill idea:
# Add to your skillopt config or system prompt for the optimizer:
# "A good skill rule must:
# 1. Name a specific failure mechanism and its remedy
# 2. Be step-level specific (the agent can follow it mechanically)
# 3. Forbid a specific harmful pattern when applicable
# Only propose rules that pass all three criteria."
Try this for a few nights and measure whether the gate acceptance rate improves. Higher acceptance rate with maintained or improved held-out scores = the meta-skill is working.
From Raw Experience to Skill Consumption (SkillLens) — §5.3 "Meta-Skill" — Microsoft Research. The finding that rubric-aware extraction yields +1.55pp, and the full analysis of why format doesn't predict utility. ~10 minutes for §5.