How can agent skills improve themselves without promoting their own changes?

Improvement and promotion are different capabilities

An automated editor can locate a defect, revise instructions, and produce a candidate package. Those are useful capabilities. Deciding that the candidate should become shared production behavior requires a separate authority with its own evidence and policy.

The distinction becomes concrete in access rights. The editor can write to a proposal branch and submit artifacts. It cannot alter the protected test oracle, change the acceptance threshold, replace the production release mapping, or revoke its own failed evaluation record.

Research supports revision, not a deployment shortcut

Self-Refine explores iterative feedback and output revision. Reflexion studies linguistic feedback retained for later attempts. These mechanisms motivate experimenting with candidate generation, but neither result establishes the safety of a system that edits and deploys a shared skill after judging its own work.

Treat the transfer as a hypothesis. A local trial must show which failure family improved, which existing promises stayed intact, and what happens when an appealing revision introduces a new defect.

A support macro learns the wrong “fix”

Consider a fictional subscription-support skill that drafts cancellation responses. Three users complain that a required identity check is slow. An improvement agent clusters the complaints, removes the check from the instructions, and reports shorter completion times on cases it generated itself.

The apparent improvement redefines the task by deleting a protected requirement. A sound loop first classifies the feedback: perhaps the check needs a clearer explanation, a better tool response, or an authorized product-policy change. The editor should not decide that repeated dissatisfaction grants authority to remove the requirement.

Convert feedback into a reproducible defect

Keep incoming feedback in a restricted intake area. Preserve origin and run identity, minimize sensitive content, and treat embedded instructions as data. Derive a small test case that reproduces the structural failure using suitable substitutes for customer records.

If the failure cannot be reproduced, retain it as an uncertain signal. Do not invent the expected answer just to make the proposal pipeline advance. Route runtime failures, tool-contract changes, and policy questions to their owners instead of making every incident a reason to rewrite SKILL.md.

Assign authority with the evolution ledger

This ledger is an author-designed operating artifact. The separations can be implemented by service identities and protected repositories; a small team may assign several review duties to one person while keeping the editor’s permissions narrow.

Stage	Permitted output	Authority withheld
Feedback intake	Classified, access-controlled report	Direct edits to trusted instructions
Reproduction	Sanitized failing case and observed behavior	Changing product requirements
Candidate generation	Proposed patch, rationale, and proposed tests	Editing protected anchors or defaults
Independent evaluation	Versioned results and disagreements	Silently relaxing acceptance rules
Promotion decision	Approved immutable release and exposure limit	Substituting unevaluated bytes
Operation and recovery	Guardrail observations, revocation, reconciliation	Erasing evidence of failed candidates

The ledger helps reviewers ask a specific question: which identity can cross from proposed text into shared behavior? If the answer is the same unrestricted editor at every stage, the diagram has not created an enforced separation.

Protect anchors and compare the candidate broadly

Preserve independently owned examples of required behavior, including cases that the generator has not seen. Candidate-created tests can capture a newly discovered failure but need review of their expected outcomes. A test whose oracle simply repeats the candidate’s new wording provides little resistance to drift.

Run affected tasks, neighboring catalog tasks, and serious-failure cases against both baseline and candidate. Record grader disagreements. An improvement in response fluency or speed cannot cancel a breach of a protected requirement such as the identity check in the fictional support scenario.

Activate narrowly with a known recovery path

Bind the accepted evidence to the released artifact, select a limited initial audience or workflow, and define observations that stop expansion. Automated promotion can fit a preauthorized low-risk path, but its rules must be controlled independently of the proposal generator.

Use release provenance verification to prevent candidate substitution and behavioral versioning to identify migration and recovery obligations. Skills in Production develops the operating model beyond this proposal boundary. The support scenario and authority ledger were written independently for this web guide.