Skills System

Skills are reusable instruction packages that teach Anyy a focused workflow. They can include a SKILL.md entry point and linked files that are loaded only when needed.

Before You Install

A Skill is instructions with access to the capabilities available in the current session. Read its source, especially commands, external services, credential expectations, and linked files.

Treat Skills as executable guidance

Installing a Skill does not itself grant new operating-system permissions, but using it can direct Anyy to call enabled tools. Install only from a source you trust.

List and Inspect Skills

anyy skills list
anyy skills view SKILL_NAME

To inspect a linked file declared by the Skill:

anyy skills view SKILL_NAME FILE_PATH

Dashboard → Skills provides the same catalog-oriented workflow with status, source, and management actions.

Install a Skill

Anyy installs local .zip packages only. A package contains exactly one SKILL.md with its supporting files, either at the archive root or inside a single Skill directory.

anyy skills install ./my-skill.zip

You can also upload the ZIP in Dashboard → Skills → Install Skill, or ask Anyy to install its local ZIP path in a conversation where skill_manage is available. All entries write the active Profile's same managed library: conversation installation appears on the Skills page, and Dashboard installation becomes available to subsequent prompts after reload. Check the enabled state separately; installation does not re-enable a previously disabled Skill.

Both the ZIP and its extracted content are limited to 10 MiB; Dashboard also caps the complete multipart request at 10 MiB. The name in SKILL.md must be at most 64 lowercase letters/digits joined by single hyphens, for example meeting-notes. Use the same enclosing directory name when present. Validation rejects invalid names before using them as paths, path traversal, symlinks, special files and packages containing multiple Skills. Remote URLs, GitHub sources, local directory installation and --all are unsupported. Existing local Skill discovery and read-only external roots continue to work; they are not package installation.

Use --force only when you intend to replace an existing managed Skill. The CLI uses resident RPC when that Profile is running, and the resident mutation reloads its catalog. Offline mutation requires exclusive Profile ownership; its files are discovered at the next startup. --now asks for a Gateway reload after the offline mutation and reports failure if no Gateway is reachable.

Conversation skill_manage mutations normally reload the shared catalog. An explicit reload:false skips that step; inspect reload or reload_error rather than treating a saved package as proof of a refreshed runtime.

Use Skills in Chat

Ask for the workflow by name or describe the task it covers:

Use the release-notes Skill to summarize the changes in this Workspace.

More than one Skill can participate when the task genuinely needs them. Keep the request focused; loading unrelated Skills increases instruction volume and can create conflicting guidance.

The Skill catalog lists entry-file locations. Anyy loads an entry or supporting file with the selected read or bash tool when needed; relative references resolve from the entry's directory. A reader available through Codemode keeps the catalog. A session with neither reader has no model Skill catalog. An explicit /skill:NAME loads that Skill for the submitted message.

If a recognized /skill:NAME entry file cannot be read or parsed, Anyy reports a nonfatal Skill expansion error after accepting the submitted message. The original input still reaches the model; the notice may appear after response generation has started. See Notifications & Delivery.

There are no separate built-in skills_list or skill_view model tools. CLI and Dashboard inspection remain available; the model reads instructions through its selected readers.

Managed Skill Updates

When skill_manage is available in the conversation's selected tools, it can update the active Profile's managed library. This Anyy capability saves package revisions and supports rollback. Ordinary file edits do not automatically provide that managed-revision guarantee; external and bundled Skills remain read-only to the managed writer. Catalog reload and adding an external root do not create a package revision.

Automatic self-review uses the conversation's available tools, choices and exclusions alongside its configured toolsets, and needs an allowed managed writer. An admitted review keeps its selection across retries and restart; later parent changes do not add tools to it. It saves concrete reusable learning when supported by the conversation, and can finish without changing the library. An update notification requires the actual successful managed result.

Reload, Roll Back, and Remove

Reload the resident catalog after out-of-band changes:

anyy skills reload

Reload updates future discovery and admissions. It does not replace the instructions or selection already admitted for a pending message or review.

Roll back to the previous managed revision, or choose a recorded revision:

anyy skills rollback SKILL_NAME
anyy skills rollback --revision REVISION_ID SKILL_NAME

Uninstall a managed Skill:

anyy skills uninstall SKILL_NAME

Resident rollback/uninstall already reload the catalog. For offline mutations, --now requests a Gateway reload and can fail if no Gateway is running; it does not bypass exclusive Profile ownership.

Tips

• Inspect a Skill again after an update; source content may have changed.
• Keep the original ZIP package when reproducibility matters.
• Keep durable personal preferences in Memory, not in a Skill.
• Use Skills for repeatable procedure; use MCP when you need an external tool or service connection.

See Dashboard Skills for visual management.