Gemini CLI reads the same SKILL.md files that Claude Code reads. It is not a Google-specific variant or a near-copy with renamed fields. It is the actual open Agent Skills format that Anthropic released, the one that roughly forty agent products now consume. So if you already wrote a Gemini CLI skill for Claude Code, dropping it into Gemini CLI is a copy command, and the rest of this post is about where to copy it and how Gemini decides when to fire it.
That portability is the whole reason this is worth your time. A skill is a folder with instructions an agent loads on demand. Google's Gemini CLI skills documentation confirms it supports the standard directly, and Gemini CLI shows up on the agentskills.io client showcase next to Claude Code, Codex, Cursor, and Copilot.
Does Gemini CLI support agent skills?
Yes, and the support is native, not bolted on through a plugin. The Gemini CLI docs describe a skill as a directory containing a SKILL.md file plus optional subdirectories for scripts and reference material. The file carries YAML frontmatter with at minimum a name and a description, followed by the instructions the model should follow. That is the exact shape of an Anthropic Agent Skill: same frontmatter keys, same progressive-disclosure loading model, same folder layout.
Progressive disclosure is what makes this cheap to run. At startup, Gemini CLI loads only the name and description of every skill it can find. The full instruction body stays on disk until a task actually matches the description, and at that point the model pulls SKILL.md into context and follows it. You can keep twenty skills installed and pay almost nothing in tokens until one of them is relevant. That mechanic is the same across every tool that implements the standard, which is why a skill behaves the same way in Gemini CLI as it does in Claude Code.
Where Gemini CLI looks for skills
Gemini CLI checks four tiers, in increasing order of precedence. Built-in skills ship with the CLI. Extension skills come from installed extensions. Then there are two tiers you control directly:
- User skills, for things you want everywhere:
~/.gemini/skills/or~/.agents/skills/ - Workspace skills, scoped to one project:
.gemini/skills/or.agents/skills/
The .agents/skills/ path is the interesting one. It is a deliberate cross-tool alias, the same directory convention other agents recognize, so a skill placed there is reachable by more than just Gemini. The docs note that within a tier the .agents/skills/ alias takes precedence over the .gemini/skills/ directory. If you are authoring skills you intend to share across tools, .agents/skills/ is the path to standardize on.
One discovery rule trips people up. Gemini CLI finds SKILL.md either at the root of the skills directory or exactly one level deep. A skill at .gemini/skills/api-auditor/SKILL.md is found. A skill buried two directories down is not, so keep the folder flat.
Installing a skill, three ways
The fastest path for a skill that already exists in a Git repo is the install command, run from your terminal:
gemini skills install https://github.com/user/repo.git --consent
The --consent flag skips the security confirmation prompt. Skip it deliberately, not by habit. A skill can carry scripts, and gemini skills install is pulling executable code from a URL onto your machine, so read what you are installing first. Once it lands you can confirm with:
gemini skills list --all
And remove one with:
gemini skills uninstall my-skill --scope workspace
The second path is for skills you already have on disk, which is the common case if you wrote one for another tool. Inside an interactive Gemini CLI session, link the folder:
/skills link <path> [--scope user|workspace]
The third path is the most direct of all: make the directory yourself and drop the file in. On Windows PowerShell:
New-Item -ItemType Directory -Force -Path ".gemini\skills\api-auditor"
Write SKILL.md into it, then inside a session run /skills reload so Gemini picks it up without a restart, and /skills list to confirm it registered. To turn skills on and off without deleting them, /skills enable <name> and /skills disable <name> do exactly what they say.
Writing a SKILL.md that Gemini actually fires
The frontmatter is two fields and a body. Here is the structure the creating-skills docs show:
---
name: code-reviewer
description: Expertise in reviewing code changes for correctness, security, and style. Use when the user asks to "review" their code or a PR.
---
Below that frontmatter you write the instructions in plain Markdown. name has to be a unique identifier and should match the directory name. The description is where the real work happens. It is the only thing Gemini reads at discovery time, so it is how the model decides whether to load the skill at all.
A vague description is the single most common reason a skill sits there doing nothing. "Helps with code" tells the model almost nothing about when to reach for it. The example above works because it names the domain (code review), spells out the specific concerns it covers (correctness, security, style), and includes the literal trigger words a user is likely to type ("review" their code or a PR). The Gemini docs are blunt about this: the description is your trigger mechanism, so be specific about the tasks it handles and the keywords that should fire it.
Write the description for the dispatcher, the way the model will read it, and lead with the trigger condition. Name the artifacts and verbs that should activate the skill. If your skill formats SQL migration files, say so, and say "use when editing files under migrations/" rather than "assists with database work." The more concrete the description, the less the skill activates at the wrong moment and the more reliably it activates at the right one.
The body is yours: step-by-step procedures, a checklist, constraints, links to bundled reference files. You can ship scripts alongside it and reference them from the instructions. Keep the body focused on one job. A skill that tries to do six things is harder for the model to apply than six skills that each do one.
The portability payoff
Here is what the shared format buys you in practice. Write one SKILL.md for, say, your team's API review checklist. Put it in .agents/skills/api-review/. Commit it to the repo. Now every engineer who runs Gemini CLI gets it, and so does everyone on Claude Code, and Codex, and Cursor, because they all read the same standard from the same directory convention. You maintain one file, and the review checklist never drifts between the person using Google's CLI and the person using Anthropic's.
That is a real change from the old world of per-tool config, where the same procedure had to be rewritten as a Claude Code thing and a Cursor thing and a Copilot thing, and the three copies slowly disagreed. A skill is portable knowledge in a version-controlled folder, and the tool reading it is interchangeable.
Authoring the file is the part that stops non-coders, though. YAML frontmatter, trigger-tuned descriptions, knowing how deep a folder can nest before discovery breaks. Knack handles that by interviewing you about the workflow you want to capture and writing a valid SKILL.md from your answers, with no YAML required. Because the output is the open Agent Skills standard, the file it produces drops straight into .gemini/skills/ and runs in Gemini CLI exactly as it runs in Claude Code. One interview, one file, every tool on the showcase list.
If you only take one thing from this, take this: put your skills in .agents/skills/, spend most of your effort on the description, and stop maintaining four copies of the same instructions.
Verifying the details yourself
Google's docs are the source of record and they move. The Agent Skills page covers discovery tiers and the install commands. The creating-skills guide covers frontmatter and description tuning. The getting-started tutorial walks the first build end to end. If a command here ever disagrees with what gemini skills --help prints on your machine, trust your machine.