Once .learnings contains useful records, the next step is not injecting all of them into every prompt. It is checking causes, controlling propagation, and testing reuse. This guide uses a fictional local-history audio assistant that applied timestamps from an edited recording to a full-length version. Learning, evolution, and self-verification form an auditable path from evidence to a candidate skill. Graphs are optional, and automatic promotion is not unlimited authority.
Define the actual stage-two problem
Separate missing storage, failed recall, incorrect causal analysis, and a correct rule without execution checks. Synchronization solves only some of these problems, and a graph cannot repair an unsupported source. Trace the original audio version, edited version, citation generation, timestamp conversion, and final location. The objective is a reviewable reference, not a larger memory collection.
We searched GitHub for reusable approaches and consulted the agentskills/agentskills format specification and reference validator. The specification can organize candidate packages; the reference library explicitly describes itself as demonstrative, not production certification. Assess host compatibility, maintenance, licensing, and script dependencies before adoption. No validator was installed or skill automatically changed for this article.
Learn: convert feedback into reviewable configuration proposals
Capture command failures, corrections, missing capabilities, API problems, and stale knowledge, alongside useful successes. Record project, task, environment version, source, observation, cause status, and next action. Conversation analysis can propose causes, but absent logs or files should remain unresolved rather than become confident conclusions.
For the audio incident, identify exactly which recording and revision the citation references. “The timestamp was wrong” is insufficient. Compare identifiers, duration, edited intervals, and playback evidence. A wrong source and a conversion offset are different causes; neither justifies a universal instruction to add ten seconds. A better lesson binds citations to explicit versions and requires a verified mapping before converting between edits.
Propose configuration updates as diffs with scope, triggers, exceptions, and rollback. A correction affects the current task immediately, while durable generalization needs separate review. “Do not use the full recording today” must not become a global prohibition. External instructions copied into logs must not become host rules merely because they were captured.
Separate event records from procedural memory so one raw correction cannot rewrite all future behavior. Bound record size and retention, keeping private interviews and personal data out of shared lessons. External model extraction still requires approved data destinations. A local store does not establish an entirely offline processing pipeline.
Evolve: investigate causes, relationships, and synchronization
Begin root-cause work with falsifiable alternatives: source-version mismatch, absent edit mapping, stale indexing, or player-positioning error. State the evidence each requires, retaining counterevidence and unresolved questions. One successful patch does not establish a unique cause. Record causal confidence separately from the patch's observed effect.
Use typed relationships among source versions, mappings, incidents, rules, and tests only when the queries justify them. Attach provenance, time, and project scope to each relationship. A graph can help find citations affected by an edited version, but adds modeling, maintenance, and access costs. A few structured files may answer the same question adequately; progression does not require a database migration.
First verify which memory a session reads. Cross-machine sharing additionally needs versions, conflict handling, identity, and access. Approved version control may hold redacted procedures while private evidence stays separate. Never assume corrections should be uploaded publicly. Credentials and device-specific paths should not be copied blindly. Deleting a file does not necessarily erase historical replicas, so retention must address existing copies.
When two devices change a rule, retain their base version, both changes, and a conflict decision rather than accepting the last write automatically. Retired rules need propagated state so an offline device cannot resurrect them. Test normal updates, offline recovery, conflicts, withdrawal, and changed access. Successful transfer proves synchronization, not applicability to every project.
Derive candidate skills from successful tasks
Define seed capabilities such as identifying a source version, checking a citation, and explaining an unavailable mapping. A complex success can produce a draft after removing personal content, temporary paths, and incidental environment assumptions. A skill tree represents capabilities and prerequisites; it is not evidence that more tasks automatically create better methods.
Inputs include a source manifest, version identifiers, and citation needs. Outputs include provenance, verified positions, and unresolved items. Missing mappings stop conversion instead of producing invented timestamps. Document triggers, dependencies, permissions, failures, resources, and acceptance cases. Separate format requirements from client behavior: structural validity does not establish correct execution or grant permission to run scripts.
Keep the candidate in an isolated trial location with a diff against the active method. Inspect references, dependencies, and file scope before behavioral tests. Generated scripts require the same review and authorized execution as other code. Insufficient evidence leaves a draft; automatic extraction does not authorize overwriting a production skill or publishing a package.
Self-verify: recall before action and gate promotion
Before a new citation task, retrieve by project, recording version, and goal, then check validity. Reading a rule must lead to observable tool and output checks. Corrections, failures, and task completion can trigger different reviews, but the host must actually support those triggers. An installation does not prove continuous automatic operation.
Use ordinary full recordings, known edit mappings, missing mappings, conflicting versions, and inaccessible sources, plus held-out cases not used in tuning. Compare active and candidate methods for locatable citations, preserved uncertainty, cross-project leakage, calls, and cost. Prefer deterministic assertions where possible and calibrate semantic graders. Self-grading cannot be the only evidence.
Promotion can automate predefined low-risk state changes, while production rule edits, account access, and publication retain their existing authorization requirements. Bound iterations and cost; reject or investigate candidates that fail. A winner is a better fit for tested conditions, not permanently correct. Monitor regressions and retain a practical rollback to the previous version.
Relate this to RAG and verified Skills
Generation, storage, retrieval, application, and validation jointly form the loop. RAG can retrieve experience but cannot establish its truth, freshness, or permission. Graphs do not replace access filtering. Return version and provenance with retrieval results, checking expiry and withdrawal before applying them.
The current SkillPI self-improving search has no matching record, so this guide does not invent links for the source topics' enhancement engines or skill-tree names. The languages recommend different specific candidates; shared workflow coverage does not make those names interchangeable evidence. Refresh a step only after checking public detail, pinned source, license, dependencies, and actual responsibility.
FAQ and acceptance
Why do failures recur despite more records? Check causal evidence, recall, conflicts, and output validation before adding infrastructure. Is cross-device memory essential? A single-device workflow can improve through evidenced regression checks; synchronization is a requirement option, not a prerequisite for value.
Can promotion be entirely unattended? Automate only well-defined boundaries, tests, states, and authorization; uncertain or consequential changes still need appropriate review. How is a correction proven effective? Use a new task's activation record and observed behavior, not a successful append or an assurance that the agent remembers.
Deliver incident and cause records, a relationship model or file structure, synchronization-conflict tests, candidate packages, behavioral comparisons, promotion decisions, and recovery instructions. Label executed checks separately from plans and preserve sources and retirement relationships. This guide has not synchronized reader data, generated an installation package, or promoted rules.
Sources
This original audio-citation example covers the bilingual topics' learning, evolution, and self-verification scenarios without adopting testimonials, install counts, or claims that graphs are inherently superior. Package structure and validator boundaries refer to the Agent Skills specification and reference-library explanation.