Skills
A skill is a folder with a SKILL.md file that teaches the agent one kind of task: how to fill PDF forms, how your team writes release notes, how to deploy. The agent sees every skill's name and description on each turn and reads the full instructions only when a task calls for them. Your prompts stay short and the agent stays focused.
Skills work the same in the CLI, the VS Code extension and the Desktop app. Instructions that should apply to every task in a project belong in AGENTS.md instead.
Create a skill​
- Make a folder under
.abacusai/skills/in your project, or under~/.abacusai/skills/to use it in every project. - Add a
SKILL.mdwith a description and your instructions.
my-project/.abacusai/skills/release-notes/
└── SKILL.md
---
name: release-notes
description: Write release notes from merged PRs since the last tag. Use when asked for a changelog, release notes, or "what shipped".
---
1. Run `git log --oneline $(git describe --tags --abbrev=0)..HEAD`.
2. Group commits by feature, fix and internal.
3. Write one line per user-visible change, past tense, no commit hashes.
- Start a new session. The skill shows up in
/skills listin the CLI and in the Skills section of the VS Code settings. Type/release-notesto use it, or just ask for release notes and let the agent pick it.
Where skills live​
| Scope | Folder | Who gets it |
|---|---|---|
| Project | <project>/.abacusai/skills/ | Everyone who opens the project. Commit it. |
| Project | <project>/.agents/skills/ | Same, using the folder name other agent tools also read |
| Global | ~/.abacusai/skills/ | You, in every project on your machine |
| Global | ~/.agents/skills/ | Same, using the shared folder name |
All four folders are read and merged. If two skills have the same name, the project copy wins over the global copy, and .abacusai/ wins over .agents/. The marketplace installs into .agents/skills/, so other tools you use can pick those skills up too.
Folder layouts​
| Layout | Skill name |
|---|---|
skills/<name>/SKILL.md | The folder name |
skills/<name>.md | The filename, for a skill with no extra files |
skills/<group>/<name>/SKILL.md | The folder that holds SKILL.md. You can group skills in subfolders up to eight levels deep. |
Names are lower-cased, and spaces or punctuation become dashes, so My Cool Skill.md becomes /my-cool-skill. A skill folder can hold scripts, reference documents and other files next to SKILL.md. Point at them from the instructions and the agent reads them when needed.
The SKILL.md file​
A SKILL.md starts with a short header between two --- lines, followed by the instructions in Markdown.
| Field | Required | What it does |
|---|---|---|
description | yes | When to use the skill. This is what the agent reads to decide, so say what the skill does and name the phrases that should trigger it. A skill without a description is skipped. |
name | no | Display name. Defaults to the folder name. |
argument-hint | no | Hint shown after /skill-name in the pickers, such as <file.pdf>. It also decides what Enter does on the skill's row: a hint that starts with <arg> marks the argument as required, so Enter completes /name and waits for you to type it. An [optional] hint, or none, runs the skill straight away. |
user-invocable | no | Set to false to keep the skill out of the / pickers and refuse explicit invocation. The agent can still choose it on its own. |
disable-model-invocation | no | Set to true to keep the skill out of the agent's automatic choices. You can still invoke it explicitly. |
allowed-tools | no | Tools to pre-approve while the skill runs. See Tools a skill may use. |
Both invocation flags default to allowing invocation, and setting both hides the skill from both paths. It still appears in /skills list so you can inspect or remove it.
license, compatibility and metadata are read and kept as description, so skills written to the Agent Skills specification load unchanged. Claude Code's execution fields — context, agent, model, hooks, shell interpolation and disallowed-tools — are not implemented and are ignored.
There is no size limit on the instructions. The agent reads them from disk only when it uses the skill. The first 100 skills are offered to the agent; the CLI warns you once if you have more.
Tools a skill may use​
allowed-tools lists tool patterns to approve for the turn, in the same syntax as a permission rule:
allowed-tools: Read, Grep, Bash(git status *)
A space-separated string, a comma-separated string and a YAML list all work. Spaces and commas inside parentheses stay part of the pattern.
Read this as approval, not restriction. It adds allow rules for the turn; it does not limit the skill to those tools. Four things keep it contained:
- Your
denyandaskrules still win, so a skill cannot grant itself something you have forbidden. - The grant applies only when you invoke the skill. A skill the agent picks on its own runs under your ordinary rules.
- The grant lasts one run. It clears when the run ends, fails, or is interrupted, and nothing is written to your settings.
- Shell patterns still go through the usual command analysis.
- A skill that came with the project grants nothing until you have trusted the folder. The skill still loads and runs; only its pre-approvals wait. See Workspace trust.
Worth a look before installing a third-party skill: allowed-tools is the one header field that changes what runs without asking.
Use a skill​
The agent gets the name and description of every skill on each turn. When a request matches, it reads the skill and follows it. You can also point at a skill yourself:
| You type | What happens |
|---|---|
| "Write the release notes" | The agent matches your request against skill descriptions and picks one |
/release-notes since v2.1 | The skill is used for this turn, with the rest of the line as your request |
| "Fix the bug, then follow /release-notes for the summary" | A /skill-name anywhere in a message works too |
In the CLI, typing / opens a picker with commands and skills. In VS Code, typing / in the message box opens the skill picker. Built-in commands such as /model always win over a skill with the same name.
Install from the marketplace​
Search and install skills that the community publishes on skills.sh without leaving the CLI or VS Code. Skills that failed a security audit are hidden from results, and the audit badges are shown on the rest.
CLI​
| Command | What it does |
|---|---|
/skills list | Show installed skills grouped by project, global and built-in |
/skills add <search> | Search as you type and install into the project |
/skills add-global <search> | Same, but install for all your projects |
/skills remove <name> | Delete an installed skill |
/skills update | Update every marketplace skill that changed |
No restart needed. The list refreshes after each command.
VS Code​
Open Abacus Settings and scroll to Skills. "Browse Marketplace" opens the search with a Workspace or Global destination toggle. "Check for updates" marks the skills that changed. The pencil icon opens a skill's SKILL.md and the trash icon deletes it.
Built-in skills​
These ship with the product. Type the name with a / to run one, or just describe what you want and the agent picks it. They are listed under "Built-in", cannot be deleted, and a project or global skill with the same name replaces one.
| Skill | What it does |
|---|---|
/init | Writes this project's AGENTS.md by studying the codebase — build, test and lint commands, layout, conventions, and the gotchas that are not obvious. Run it in a repository that has none. --refresh updates an existing one. |
/review | Reviews the current diff, or a PR number, branch or path, for correctness bugs and cleanups. Reports confirmed findings, most severe first. --fix applies them. |
/security-review | Audits changes for exploitable vulnerabilities — injection, auth gaps, exposed secrets, path traversal, SSRF, XSS, crypto misuse — and reports only findings it can trace from an attacker-controlled input to a real impact. |
/simplify | Same behavior, less code. Reuse, simplification and cleanup of what a change left behind. Quality only; use /review to hunt bugs. |
/verify | Proves a change works by running it end to end, instead of reasoning from the diff. |
/browser-use | Drives a real browser — open pages, click, fill forms, read results. See Browsing the web. |
/doctor | Diagnoses an unhealthy install and proposes fixes. See When something is wrong. |
/setup | Sets this machine up for the CLI. See When something is wrong. |
/abacus-help | Answers questions about Abacus.AI itself — installing, signing in, which model is answering, plans and credits, what the agent can see on your machine. |
/doctor and /setup are CLI only. The rest work in both the CLI and the VS Code extension. The desktop app and CoWork ship a different set, including skills for Word, PowerPoint, Excel and PDF files.
When something is wrong​
Two of the built-in skills exist to fix the product rather than your code, and they are worth knowing about before you open a support ticket.
/setup configures a new machine. It probes your OS, terminal, editors, multiplexers and shells, then fixes only what is actually broken: Shift+Enter inserting a newline instead of submitting, the VS Code terminal tab title, tmux and screen key passthrough, shell integration, notifications and colors. It also offers to install the VS Code extension. Run it with no arguments, or name one area — /setup newline, /setup title, /setup keys.
/doctor diagnoses an install that has gone wrong. It covers duplicate or stale installs, reclaimable disk under the config folder, a config.json or mcp.json that fails to parse and is being silently ignored, quarantined credentials that make you log in again and again, skills and instruction files eating your context every session, corporate TLS proxies causing certificate errors, and your permission posture. Narrow it with /doctor install, /doctor disk, /doctor config, /doctor context, /doctor network or /doctor permissions.
Reach for /doctor when the CLI is slow to start, keeps signing you out, ignores a setting you wrote, or an update did not seem to apply.
Browsing the web​
/browser-use is built in. With it the agent can open pages, click, fill forms and read what comes back, which is how it checks a page it just changed or pulls something out of a site that has no API.
It drives a browser you already have installed through the bundled agent-browser program, so there is nothing to install and no Node or Playwright setup. You can run it yourself too:
abacusai agent-browser open https://example.com
abacusai agent-browser snapshot -i
abacusai agent-browser close
Loading the skill does not authorize anything on its own: browser actions go through the usual permission rules, and files the browser writes under ~/.agent-browser/tmp/ are treated like other workspace artifacts. Saved sessions, profiles and authentication vaults never get a blanket write grant.
Share skills​
Skills are just files. Commit your project's .abacusai/skills/ folder to share it with your team, or publish a skill on GitHub so others can install it from the marketplace. Keep secrets out of skill files; put credentials in MCP server settings or environment variables instead.
Troubleshooting​
My skill is not listed​
Check that the header has a description, that the file is named SKILL.md inside a folder or <name>.md at the top level, and that you started a new session after adding it. A skill with user-invocable: false is hidden from the pickers on purpose.
Two skills have the same name​
The project copy silently replaces the global one. Rename one of them.
The agent does not use my skill​
The description decides. Say what the skill does and list the phrases that should trigger it. While you refine it, /skill-name forces the skill for one turn.
For further help, reach out at support@abacus.ai.