SkillOpt is a governance layer for self-improving agent skills

SkillOpt is best understood as governance infrastructure for agent behavior. It does not make a model smarter by changing weights. It changes the external skill document that steers a frozen agent, then refuses to deploy a new version unless it improves on held-out validation. That detail turns the project from another prompt-optimization tool into a useful reference point for operating agents safely.

The project ships two surfaces: a research engine for benchmarked skill training, and SkillOpt-Sleep, a preview deployment companion that reviews supported coding-agent sessions and stages validated memory or skill proposals. Both use the same basic discipline: collect task evidence, generate bounded text edits, and keep a gate between reflection and adoption.

The boundary SkillOpt draws

The unsafe version of agent self-improvement is simple: let the agent inspect failures and rewrite its own instructions. That can work for a few examples, but it creates hidden coupling. A rule added for one failure can break a different task, and no one knows until production behavior changes. SkillOpt draws a harder boundary. Reflection can propose; validation decides. The skill document can evolve; the target model and harness can remain fixed. Deployment receives a best_skill.md artifact rather than an always-mutating instruction blob.

Operational pieces that matter

• A separate optimizer role, so the executor and the editor are not conflated.
• Structured add/delete/replace edits, so changes remain reviewable.
• A learning-rate-like edit budget, so a candidate skill cannot drift too far in one step.
• Held-out validation, so training feedback does not automatically become production instruction.
• Sleep-mode staging, so local agent sessions can become proposals instead of silent memory writes.

For infrastructure teams, the gate is the most important piece. The SkillOpt-Sleep documentation even includes a warning about data boundaries: harvested transcripts are local and read-only in collection, but real backends can send excerpts and derived tasks to the chosen model provider. That means the safe workflow is inspect, redact if needed, mark reviewed, replay, then adopt. A company that skips that step is not using SkillOpt as governance; it is just automating prompt drift.

Where it fits in an agent platform

SkillOpt belongs around recurring workflows with measurable outcomes. A coding agent can replay known repository tasks. A spreadsheet agent can compare generated workbooks against golden files. A document QA agent can score answers against held-out items. In those settings, a skill document can be trained and released much like a configuration artifact.

It fits poorly where evaluation is subjective, sparse, or constantly changing. If there is no stable score, no held-out set, and no review owner, the machinery creates confidence without evidence. The right first step is often not SkillOpt; it is building the task log and evaluator that would make SkillOpt meaningful later.

Adoption checklist

• Define the recurring task class before writing the initial skill.
• Keep train, validation, and test examples separated.
• Log rejected edits, not only accepted improvements.
• Review SkillOpt-Sleep proposals before adopting them into long-term memory or skills.
• Treat best_skill.md as a deployable artifact with rollback, not as a scratchpad.