DEV Community

Cover image for Aweskill: Let Your AI Agent Manage skill itself
webioinfo
webioinfo

Posted on

Aweskill: Let Your AI Agent Manage skill itself

#agents #ai #cli #productivity

Let Your AI Agent Manage skill itself

Most developer tools still assume the human is the operator.

You read the documentation. You install the CLI. You decide where files should go. You copy commands from a README, paste them into a terminal, check the output, fix the path, and then explain the final state back to your AI coding agent.

That made sense when tools were only built for humans.

But AI coding agents now run commands, inspect files, follow project conventions, and repair broken local state. If a tool is meant to help agents, the better question is not:

How does a human use this CLI?

It is:

Can the agent operate the CLI by itself?

That is one of the quiet but important ideas behind aweskill: it is a CLI-first Skill package manager that AI agents can operate themselves.

Website: aweskill.webioinfo.top

It is already used as supporting infrastructure for several Webioinfo projects:

  • awescholar — AI-agent-operable scientific literature discovery and curation. Search, annotate, filter, and report on academic papers.
  • aweshelf — Session bookmark manager for Claude Code and Codex. Bookmark, categorize, and restore sessions with aweswitch profiles.
  • Awesome AI Meets Biology — A curated survey of AI applications in biology, bioinformatics, and biomedical research, powered by awescholar.

The Old Workflow: You Manage the Agent's Tools

When a new AI Agent needs a Skill, the usual workflow looks like this:

  1. You find the Skill.
  2. You download or copy it.
  3. You locate the agent's Skill directory.
  4. You place SKILL.md in the right folder.
  5. You restart the agent.
  6. You hope the next agent uses the same layout.

This is manageable once.

It becomes messy when you use Codex, Claude Code, Cursor, Gemini CLI, Windsurf, Qwen Code, OpenCode, or any other coding agent side by side. Each one has its own directory layout and conventions. The human becomes the package manager.

That is backward.

If the agent is already capable of editing your repo, running tests, and diagnosing failures, it should also be able to manage its own Skills.

The aweskill Workflow: Give the Agent a Protocol

aweskill provides a bootstrap document written for AI coding agents:

Read https://github.com/mugpeng/aweskill/blob/main/README.ai.md and follow it to install aweskill for this agent.
Enter fullscreen mode Exit fullscreen mode

That instruction is enough for a capable coding agent to do the initial setup.

The protocol tells the agent to:

  • check that Node.js and npm are available
  • install aweskill globally
  • initialize the central Skill store at ~/.aweskill/skills/
  • detect the current agent runtime
  • project the built-in aweskill and aweskill-doctor Skills into that agent
  • verify the projection
  • ask you to restart so the new Skills become active

Example of an AI coding agent following README.ai.md to install aweskill and activate the built-in management skills.

After that restart, you no longer have to remember every command. You can ask the agent in plain language.

What the Agent Can Do After Bootstrap

aweskill ships two built-in meta-Skills:

  • aweskill: routine Skill management, including search, install, update, bundles, and agent projection
  • aweskill-doctor: repair-first workflows, including sync checks, cleanup, deduplication, malformed SKILL.md repair, and recovery

Once these are projected into the current agent, the agent can translate natural-language requests into aweskill commands.

Instead of typing:

aweskill find review
aweskill install owner/repo
aweskill agent add skill pr-review --global --agent codex
Enter fullscreen mode Exit fullscreen mode

You can say:

Find a good code-review Skill, install it into aweskill, and enable it for this agent.
Enter fullscreen mode Exit fullscreen mode

The agent can search, inspect results, choose an installable source, run the install, project the Skill, and verify the result.

That is the difference between a CLI that agents can call and a CLI that humans must babysit.

Use Case 1: Bootstrap a Fresh Agent

You open a new machine, a fresh terminal, or a newly installed coding agent. Instead of manually setting up its Skill directory, you give it one instruction:

Read README.ai.md from the aweskill repo and install aweskill for this agent.
Enter fullscreen mode Exit fullscreen mode

The agent follows the bootstrap protocol:

npm install -g aweskill
aweskill store init
aweskill store where --verbose
aweskill agent supported
aweskill agent add skill aweskill,aweskill-doctor --global --agent <agent-id>
aweskill agent list --global --agent <agent-id>
Enter fullscreen mode Exit fullscreen mode

The important detail is that the protocol is conservative. If the agent cannot determine the correct agent-id, it should ask you instead of guessing. It should not project Skills to every installed agent by default.

That makes the bootstrap flow agent-friendly without being reckless.

Use Case 2: Ask the Agent to Find and Install a Skill

You are working on a Python data project and want a useful data-analysis Skill.

You do not need to browse registries yourself. You can ask:

Find a useful Python data-analysis Skill and install the best match into aweskill.
Enter fullscreen mode Exit fullscreen mode

The agent can run:

aweskill find python data analysis
Enter fullscreen mode Exit fullscreen mode

Then it can inspect the results, avoid unsupported discover-only entries, install the best available source, and report what it did:

aweskill install <source>
Enter fullscreen mode Exit fullscreen mode

If the Skill should be active in the current agent, the agent can project it:

aweskill agent add skill <skill-name> --global --agent <agent-id>
Enter fullscreen mode Exit fullscreen mode

The human stays in the loop for judgment. The agent handles the mechanical work.

Use Case 3: Build a Project Bundle by Conversation

Bundles are where agent-operated Skill management starts to feel natural.

Instead of remembering which Skills belong in a frontend project, you can ask:

Create a frontend bundle with the Skills we need for UI design, accessibility review, test-driven development, and release checks. Enable it for this agent.
Enter fullscreen mode Exit fullscreen mode

The agent can turn that into a sequence:

aweskill bundle create frontend
aweskill bundle add frontend frontend-design,accessibility-review,test-driven-development,release-checklist
aweskill agent add bundle frontend --global --agent <agent-id>
aweskill agent list --global --agent <agent-id>
Enter fullscreen mode Exit fullscreen mode

The real value is not saving a few keystrokes. The value is that the agent can reason from the project context, select a relevant group of Skills, make the bundle repeatable, and verify that the current agent can use it.

Later, when you move the same project to another coding tool, the bundle is still there.

Use Case 4: Let the Agent Check for Updates

Skills age like any other dependency. Instructions change. Upstream authors fix bugs. Registries improve metadata. Local copies drift.

Instead of manually checking each Skill, you can ask:

Check whether any installed Skills have source updates, but do not change files yet.
Enter fullscreen mode Exit fullscreen mode

The agent can run:

aweskill update --check
Enter fullscreen mode Exit fullscreen mode

Then it can summarize the result and ask before applying changes.

If you approve, it can run targeted updates:

aweskill update <skill-name>
Enter fullscreen mode Exit fullscreen mode

This is especially useful when you use the same Skill across Codex, Claude Code, Cursor, and Gemini CLI. The projected agents point back to the central store, so one updated source becomes available everywhere it is projected.

Use Case 5: Ask the Agent to Repair Skill State

Local Skill directories are not static. Agents update. Paths change. Symlinks break. Someone manually copies a folder into a managed directory. Another Skill has malformed frontmatter.

This is where aweskill-doctor matters.

You can ask:

Check whether this agent's Skills are broken, duplicated, or suspicious. Show me the report first.
Enter fullscreen mode Exit fullscreen mode

The agent can run read-only checks:

aweskill agent list --global --agent <agent-id>
aweskill doctor sync --global --agent <agent-id>
aweskill doctor clean
aweskill doctor dedup
aweskill doctor fix-skills
Enter fullscreen mode Exit fullscreen mode

The repair commands are dry-run by default. The agent can inspect the report, explain the risk, and only apply changes when you explicitly approve:

aweskill doctor sync --global --agent <agent-id> --apply
aweskill doctor dedup --apply --backup
aweskill doctor fix-skills --apply --backup
Enter fullscreen mode Exit fullscreen mode

This is the right division of labor: the agent diagnoses and prepares the repair; the human approves destructive or state-changing actions.

Use Case 6: Migrate a Working Setup to Another Agent

Suppose you have a good setup in Codex and now want a similar setup in Claude Code.

You can ask:

Look at the Skills and bundles available in aweskill, then project the daily coding setup into Claude Code.
Enter fullscreen mode Exit fullscreen mode

The agent can inspect the central store and bundles, then run:

aweskill agent supported
aweskill agent add bundle daily-coding --global --agent claude-code
aweskill agent list --global --agent claude-code
Enter fullscreen mode Exit fullscreen mode

No manual copying. No guessing where Claude Code stores Skills. No stale folder fork.

One central store. One bundle. Another agent enabled.

Use Case 7: Back Up Before a Risky Change

Before a large cleanup or migration, you can ask:

Back up my aweskill store before making any Skill changes.
Enter fullscreen mode Exit fullscreen mode

The agent can run:

aweskill store backup
Enter fullscreen mode Exit fullscreen mode

Then it can proceed with the requested work. If something goes wrong, the central store can be restored instead of rebuilt from memory.

This is a small detail, but it changes the psychology of maintenance. You can let the agent help because the state is recoverable.

Why This Matters

Agent-operated tooling changes the shape of developer workflow.

The best tools for AI coding agents should be:

  • documented for both humans and agents
  • scriptable through a stable CLI
  • conservative about destructive actions
  • inspectable before applying changes
  • easy to verify after each operation
  • recoverable when local state drifts

aweskill is built around that model.

It is still useful as a normal human-operated CLI. You can run every command yourself. But the more interesting workflow is giving your agent enough structure to operate the tool safely on your behalf.

That is why README.ai.md exists.

That is why aweskill and aweskill-doctor are built-in Skills.

And that is why Skill management should not stay trapped in manual folder work.

More from Webioinfo

aweskill is part of the Webioinfo ecosystem — a collection of small, agent-friendly tools for AI-assisted development:

  • aweshelf — Session bookmark manager for Claude Code and Codex. Bookmark, categorize, and restore AI coding sessions with aweswitch profiles.
  • awescholar — Automated scientific literature discovery. Search, annotate, filter, and generate research reports with LLM-powered pipelines.
  • aweswitch — Agent profile switcher. Launch sessions with different API endpoints, tokens, and models.
  • aweteam — AI coding team coordinator. Start a leader, delegate to configured workers, and keep conversations visible in tmux panes.
  • awecolor — Hex color visualizer. Pipe text or pass files to render hex colors with their actual terminal background.

Try It

If you want the fastest path, ask your current coding agent:

Read https://github.com/mugpeng/aweskill/blob/main/README.ai.md and follow it to install aweskill for this agent.
Enter fullscreen mode Exit fullscreen mode

After restart, try:

Find a useful testing Skill and install it into aweskill.
Enter fullscreen mode Exit fullscreen mode

Then:

Check whether this agent's Skill projection is healthy.
Enter fullscreen mode Exit fullscreen mode

If those three requests work, your agent is no longer just using Skills. It can help manage them.

Top comments (2)

Collapse
 
harjjotsinghh profile image
Harjot Singh •

An agent that manages its own skills is a genuinely interesting frontier - self-modifying capability (the agent decides which tools/skills to acquire or drop) is powerful and a little scary, because it moves you from "I control what the agent can do" to "the agent controls what the agent can do." That's a big trust jump. The upside is adaptivity; the risk is an agent granting itself a capability you'd never have approved.

The design question I'd be careful about: is skill-acquisition gated, or fully autonomous? Self-managing skills only stays safe if there's a boundary the agent can't self-expand past - it can propose a new skill, but a deterministic policy (or a human) approves the actual capability grant. Otherwise "manage its own skills" quietly becomes "escalate its own privileges." It's the same propose-then-gate line I hold in Moonshift (a multi-agent pipeline shipping a prompt to a real SaaS). Cool project - does Aweskill let the agent actually grant itself new capabilities, or just select among pre-approved ones? That distinction is the whole safety story.

Collapse
 
webioinfo profile image
webioinfo •

Thanks for the thoughtful question — the propose-then-gate framing is sharp, and it pushed me to articulate something we should be more explicit about.

The distinction you're drawing is exactly right, and aweskill sits on the select-among-pre-approved side — but with a nuance worth calling out.

What aweskill actually is: a local CLI package manager for SKILL.md files (markdown instruction documents, not executable plugins). It keeps a central store at ~/.aweskill/skills/ and projects selected skills into each agent's expected directory via symlinks. The "self-managing" part is that aweskill ships built-in skills (aweskill and aweskill-doctor) that teach the agent how to operate the CLI — so the agent can run aweskill find, aweskill install, aweskill agent add from natural-language requests.

So does the agent grant itself new capabilities? It can install skills from external sources (GitHub repos, skills.sh, sciskillhub.org) and project them into its own agent directory. That's capability expansion, not just selection from a fixed local set. But the installed artifacts are auditable markdown files, not arbitrary code execution. The agent is operating a package manager — like a human running npm install — not writing new capabilities into existence.

Where the safety boundary actually lives:

  • Skills are instruction documents, not executable plugins — they tell the agent how to use the CLI, they don't inject new system-level capabilities

  • The agent can only install what already exists in the curated upstream sources

  • aweskill itself enforces "managed-only removal" — it won't blindly delete directories it didn't create

  • The human bootstrapped the whole thing: installed the CLI, initialized the store, chose which agents get which skills

The honest answer to your question: it's closer to "select among pre-approved" than "fully autonomous self-modification," but it's not a strict whitelist either — the agent can pull new skills from external sources and activate them. The trust boundary is "the agent can install auditable markdown instruction files from curated registries," not "the agent can grant itself arbitrary system privileges." That's a meaningful distinction from, say, an agent that can write and load its own executable plugins.

If you wanted to tighten it further, you'd add an allowlist of installable sources or a confirmation gate before aweskill install actually runs. The architecture supports that — the CLI is deterministic, the skills are just files, and the projection model is explicit.

Looking ahead, we're planning two additional security measures:

  1. Post-install integrity verification — after a skill is installed from an external source, aweskill will record a content hash. On every subsequent projection or update, it checks whether the skill content has been tampered with since installation. This catches the case where someone modifies a skill file in the central store and the agent silently picks up altered instructions.

  2. Capability declaration and scoping — each skill will declare what agent capabilities it requires (e.g., filesystem access, network requests, shell execution). The CLI will enforce these boundaries at projection time, so a skill that only needs read-only file access can't instruct the agent to run arbitrary shell commands. This moves the trust model from "the skill can do anything the agent can do" to "the skill can only do what it explicitly asked for."