AutoSkill: turning conversations into versioned SKILL.md files

Skills come out of real interactions, not out of model weights

AutoSkill is presented as a practical implementation of Experience-driven Lifelong Learning. The mechanism is narrower than the phrase suggests and that is its appeal: it learns from real interaction experience, the dialogue plus agent traces, automatically creates reusable skills, and continuously evolves existing skills through merge and version updates. Nothing about it trains a model or changes weights. What changes is the set of instruction files the agent carries between runs. The project describes this as turning short-term interaction signals into long-term capability assets that can be reused across runtimes, and the topics attached to the repository name the same territory, agent skills, continual learning and self-evolving systems. The research framing points at an arXiv preprint, 2603.01145, and the code is maintained by ICALK at East China Normal University.

SKILL.md keeps the outcome readable and editable

The format choice is the most consequential decision in the project. AutoSkill uses the Agent Skill artifact, SKILL.md, with explainability and editability, and the stated benefit is that skills remain readable, reviewable and manually revisable. Compare that with a system that stores preferences as a hidden vector or an opaque embedding and the difference is easy to audit. A SKILL.md file can be read in a diff, corrected by a person, checked into a repository and reviewed like any other artefact. The SDK itself is packaged with a py.typed marker, so it ships type information, and the Python package data includes a skill_taxonomies directory of YAML files for AutoSkill4Doc, which is how the taxonomy of skill kinds is carried in the distribution. The consequence for a team is that the output of the system is a set of files you can read, which is also the reason the project keeps a separate local skill manager for post-session triage.

Extraction stays silent until a durable constraint shows up

The lifecycle example in the README opens with a deliberate restraint. If the user only asks to write a report and gives no stable preference or correction, AutoSkill does not create a new skill, and it outputs an empty extraction result, to avoid noisy, generic skills. That single rule is what keeps the skill bank from filling up with trivia. The trigger is a durable constraint, for example a statement like do not hallucinate, and at that point the system extracts a skill or merges into version v0.1.0. Management is described as backend-first, meaning the automatic add or merge happens without a human in the loop, with optional human edit, save or delete of the SKILL.md afterwards. The shipped examples are given as daily and science scenarios, and the science caption is specific about what counts, reusable lab and process constraints such as hard limits and mandatory procedure steps.

Version bumps instead of duplicate skills

The update path is the part that decides whether a skill bank is usable after a few weeks. When later user feedback adds constraints or changes priorities, AutoSkill updates the existing skill instead of creating duplicates, and the version moves from v0.1.0 to v0.1.1. Duplicates are the natural failure mode of this kind of system, since every new correction looks like a new rule if you store rules rather than skills, and the accumulated pile becomes impossible to retrieve from. The numbering also gives you a history to read, and the project backs the update path with a component called SkillEvo, a framework for replay, evaluation, mutation and promotion that enables models to iteratively self-evolve skills, released as SkillEvo 1.0 on 2026-03-23. The retrieval step closes the loop. For the next similar task, for instance writing a government report about a self-evolving agent, the updated skill is retrieved and used to generate outputs aligned with user expectations.

Offline extraction avoids replaying the original interaction

Requiring a live interaction to learn from is a limitation, and the project attacks it directly. Offline extraction from completed data is a listed capability: existing chats and trajectories can be imported directly for offline skill extraction, with no need to replay the original interaction. The news log dates that addition to 2026-03-01, when offline skill extraction from archived conversations was added, with a pointer to skills in SkillBank and CovSkill. Two sibling components extend the same idea. AutoSkill4Doc is a standalone document-to-skill pipeline for extracting reusable skills from papers, manuals and domain documents, and its release in March 2026 is described as being expect by extracting skills from a document or research paper. AutoSkill4OpenClaw, released in February 2025, is an OpenClaw integration for trajectory-driven skill evolution and native skill mirroring, extracting skills from OpenClaw trajectories.

A four part repository with one shared skill format

The top level is split into four components plus the supporting directories. The autoskill directory holds the core SDK, Web UI, OpenAI-compatible proxy, online skill evolution, offline conversation extraction and offline trajectory extraction. AutoSkill4Doc is the document pipeline, AutoSkill4OpenClaw is the OpenClaw integration, and SkillEvo is the replay, evaluation, mutation and promotion framework. Around them sit examples with runnable entry points and demos, a SkillBank directory as the default local skill storage root, data for evaluation and sample data, tests, and web assets for the local interface. The examples are named in a way that describes the API surface: auto_evalution.py, basic_ingest_search.py, interactive_chat.py, openai_proxy.py and web_ui.py. The package metadata declares two console entry points, autoskill pointing at autoskill.cli:main and autoskill4doc pointing at AutoSkill4Doc.extract:main, with a requires-python of 3.9 or newer.

Provider keys come from the environment, not from dependencies

One line in the package metadata says more about the design than anything else. The dependencies array is empty. The SDK pulls in no third party packages, so a runtime environment stays small and the model and embedding providers are reached over HTTP with credentials supplied by the caller. The .env.example file shows the shape of that configuration. Provider selection is done with AUTOSKILL_LLM_PROVIDER and AUTOSKILL_EMBEDDINGS_PROVIDER, with defaults of internlm and qwen, and keys are supplied for INTERNLM, DASHSCOPE, ZHIPUAI, BIGMODEL, OPENAI and ANTHROPIC, plus a generic compatible endpoint set with AUTOSKILL_GENERIC_API_KEY, AUTOSKILL_GENERIC_LLM_URL and AUTOSKILL_GENERIC_LLM_MODEL and matching embedding variables. The runtime knobs are equally explicit, with AUTOSKILL_USER_ID, AUTOSKILL_SKILL_SCOPE set to all, AUTOSKILL_REWRITE_MODE set to always, AUTOSKILL_EXTRACT_MODE set to auto, AUTOSKILL_EXTRACT_TURN_LIMIT set to 1, AUTOSKILL_MIN_SCORE at 0.4 and AUTOSKILL_TOP_K at 1. Those thresholds are the ones to reason about, because they decide when a skill is written at all.

Docker deployment with a store directory mounted for skills

A Dockerfile and a compose file are included for running the web interface. The image is built on python:3.10-slim, installs the package in editable mode with pip install -e ., and exposes ports 8000 and 9000. The compose service starts the web example rather than the SDK directly:

  command:
    - python3
    - -m
    - examples.web_ui
    - --host
    - 0.0.0.0
    - --port
    - "8000"

and the store directory is mounted at /data/SkillBank, which is where the skills themselves live on disk. The remaining flags are the same environment variables seen in the .env.example, passed as arguments with defaults, so the deployment is configurable without editing the image. Startup maintenance is handled by variables such as AUTOSKILL_AUTO_NORMALIZE_IDS, AUTOSKILL_AUTO_IMPORT_DIRS and AUTOSKILL_AUTO_IMPORT_MAX_DEPTH, which import existing skills into the bank at boot. A local skill manager was added on 2026-05-09 under skills/autoskill for maintaining local skill files after a session, covering reusable-experience triage, similar-skill search and the discard, improve, merge and create decisions. The last push was on 2026-05-10, the repository is not archived, and there are no GitHub releases, so version pinning has to come from a commit rather than a tag.

Editorial conclusion

Adopt AutoSkill if your agent repeats work that users keep re-specifying and you want those preferences captured as reviewable files rather than as prompt fragments. Do not adopt it expecting a model improvement, since nothing here trains a model, and check the extraction thresholds, the min-score and extract-turn-limit settings, before you let it write skills unattended.

Frequently asked questions

Official sources

1. ECNU-ICALK/AutoSkill on GitHub
2. Issues
3. README