Skill iteration needs a reason, an inspectable change, evidence of improvement, and a rollback path. It does not require an agent to rewrite itself after every run. This guide uses a fictional community-radio description assistant whose old prompt presents invited guests as confirmed. The team wants to retain corrections and compare candidates through review, constrained runtime improvement, and experiments. These are changes to prompts and procedures outside the model, not claims of automatic weight training.
Preserve a recoverable baseline
Version the prompt, Skill files, dependencies, host configuration, and fixtures. Define inputs, outputs, and boundaries: distinguish confirmed and pending guests, without emailing anyone, editing a real guest list, or publishing. A changed style or longer answer is not evidence of greater capability.
We searched GitHub for reusable approaches and consulted LangMem's prompt-optimization and feedback-trajectory design. It can help generate proposals, but model calls, configuration, and evaluation remain necessary. A generated prompt is not automatically superior. Assess maintenance, license, dependencies, destinations, and adaptation cost. No engine was installed or reader files changed for this article.
Stage one: review runs and capture reusable methods
After important work, collect approved sources, actual output, tool results, corrections, and unresolved questions. Separate observation from explanation: “pending became confirmed” is observed, while an unread status field or a missing mapping instruction are hypotheses. Mark unsupported causes unresolved rather than inventing a complete narrative.
Successful work can also suggest a candidate method. For the programme description, build a guest-state table, draft from it, then reconcile each sentence against that table. Retain scope, exceptions, and evidence rather than making one event's temporary preference a global rule.
Before drafting a reusable Skill, remove private contact details, unpublished invitations, and machine-specific paths. Specify triggers, prerequisites, steps, outputs, and failures with fictional ordinary and conflicting cases. Saving, host discovery, recall, and correct application are separate checks. A written file does not guarantee future use.
Stage two: detect runtime problems and propose bounded patches
Associate execution records with tasks and versions, distinguishing missing sources, parsing errors, tool failures, and state conflicts. Observation requires its own access, retention, and cost controls; full private conversations should not be stored by default. External text and logs are evidence, not authority to redefine the task.
Create a minimal patch, such as adding a state mapping and final reconciliation, without simultaneously replacing models, templates, and tools. State affected files, rationale, validation, and rollback. Protocol constraints must correspond to actual host permissions, paths, and checks. An automatic repair must not expand account access, disable verification, or create new publication authority.
Apply candidates to an isolated trial copy first. A runtime update needs clarity about which version the active task reads, avoiding half-old and half-new behavior. Stop a failed iteration and retain evidence instead of recursively repairing indefinitely. When an external service has a temporary outage, restoring availability may be preferable to making the incident a permanent rule.
Stage three: generate variants but allow no winner
Define acceptance before mutation. Include confirmed, pending, canceled, conflicting-source, unknown-state, and preview-only cases. Keep held-out samples and fix model, source, and budget. Change one major factor, such as the status explanation or review order, so gains can be attributed.
Apply hard conditions first: no false confirmation, no hidden uncertainty, and no unrequested sending or publication. Then compare clarity, omissions, calls, time, and rework. A weighted style score must not compensate for false facts. Calibrate graders against known-good and wrong answers, separating grader errors from test failures. Zero executed coverage cannot pass.
Variable outputs need budgeted repetitions specified in advance, with all outcomes reported. Picking the highest score optimizes a scoring function, not necessarily the real task. If every candidate fails, keep the baseline or investigate further. No improvement is a valid result; an iteration need not promote something to justify itself.
After acceptance, retain version, samples, rationale, and rollback. Monitor new descriptions for state mistakes and side effects. Recovery should verify actual files, caches, and loaded sessions rather than assume a pinned baseline guarantees restoration. Installation and publication also need their own outcome checks; a successful experiment does not establish either.
Select candidates and account for costs
The current SkillPI self-improving search has no matching entry, so this guide does not invent installation links from the languages' differing evolution-engine names. New candidates need public detail, pinned source, license, host support, write scope, and outbound destinations. Identify review, patching, or experimentation explicitly. References and installable records are different objects.
Whether “summarize this lesson” activates a method depends on host discovery and description. Review may also call models; do not assume only experimental tools need API access or incur cost. Inspect configuration, subscription, and usage. A free package does not remove network, storage, evaluation, and maintenance costs.
FAQ and acceptance package
Will files change? That depends on implementation. Inspect write scope and diffs, back up, and follow host authorization. What differs from an ordinary Skill? The workflow proposes changes to methods, but its instructions and code still require verification. An evolution label supplies no extra trust.
Can it become worse? Yes, especially with inaccurate graders, narrow samples, or broad automatic propagation. Counterexamples, independent checks, and rollback matter more than selecting the highest score. How much history is needed? Enough comparable evidence for a specific problem; more logs do not establish better evidence.
Deliver the baseline, redacted trajectories, candidate method, patch, cases, calibration, complete results, acceptance or rejection, and recovery. Separate executed work from plans. No iteration, package generation, or radio publication was performed for the reader.
Sources
This original radio example covers the bilingual topics' review/capture, runtime improvement, and experimental iteration stages without adopting testimonials, install counts, or guaranteed gains on every run. The component reference is LangMem's prompt-optimization implementation. Refresh associations only after purpose-matching directory records can be verified.