huggingface/skills: Agent Skills for the Hugging Face Hub

The problem: agents guess at Hub commands

A coding agent asked to upload a dataset or launch a Space will usually improvise. It recalls a plausible command, invents a flag, and fails. Hugging Face Skills addresses that by shipping the instructions instead of hoping the model memorized them. Each skill is a self-contained folder holding a SKILL.md file with YAML frontmatter (name and description) followed by the guidance the agent follows while the skill is active. The repository describes skills as definitions for AI/ML tasks like dataset creation, model training and evaluation, and it follows the standardized Agent Skills format documented at agentskills.io. The audience is narrow and specific: developers who already run a skill-aware coding agent and want Hugging Face Hub work to happen inside it rather than in a separate terminal session. The README states the repository is compatible with Claude Code, Codex, Gemini CLI and Cursor, which is the whole supported set.

What is inside the skills/ directory

The repository layout lists skills/, scripts/, agentsmd/, hf-mcp/, apps/ and assets/, plus per-client manifest directories .claude-plugin/ and .cursor-plugin/. The README's table is auto-generated by scripts/generate_agents.py and names the shipped skills. hf-cli covers the hf command for downloading, uploading and managing models, datasets, spaces, buckets, repos, papers and jobs. hf-mem estimates memory needed to load Safetensors or GGUF weights for inference. huggingface-datasets wraps the Dataset Viewer API: subset and split metadata, row pagination, text search, filters, parquet URLs, size and statistics. huggingface-llm-trainer covers TRL and Unsloth training through Hugging Face Jobs. huggingface-local-models selects models for llama.cpp and GGUF on CPU, Mac Metal, CUDA or ROCm. huggingface-community-evals runs inspect-ai and lighteval locally. huggingface-best answers "what model should I use" and benchmark comparisons. The hf-cloud-* family handles AWS context discovery, isolated Python environments, SageMaker deployment planning, IAM preflight, serving image selection and production endpoint defaults. The breadth is real, but the README notes the table is generated and should not be edited by hand, so the authoritative list lives in the directory itself.

Installing hf-cli in Claude Code

Claude Code treats the repository as a plugin marketplace. Register it first, then install the CLI skill by name. The README gives these two commands, and the second one pins the skill to the marketplace you just added.

/plugin marketplace add huggingface/skills
/plugin install hf-cli@huggingface/skills

After that, additional workflow skills arrive through the hf CLI rather than the plugin system. The README does not print the output of these commands, so what you see depends on your client. The pattern to remember is that hf-cli is the bootstrap: it is the recommended first skill because it teaches the agent every hf command, and the README says it is generated from your locally installed CLI so it stays current.

Installing the rest of the skills

Once hf-cli is active, the agent can run the install command for any other skill in the repository. The placeholder is literal: substitute the folder name from the skills/ directory.

hf skills add <skill-name>

The README is explicit that the client plugin marketplaces expose hf-cli as the bootstrap path for core Hub operations and that additional workflow skills can be installed on demand with this command or discovered by skill-aware clients over CLI/MCP integrations. That second path matters: .mcp.json is configured with the Hugging Face MCP server URL, so a client that speaks MCP may surface skills without a manual install. The README does not document what happens when a skill name does not exist, and it does not describe an uninstall or rollback command.

Codex, Gemini CLI and Cursor take different routes

Codex does not use a marketplace here. You copy or symlink the skills you want from skills/ into a standard .agents/skills location, for example $REPO_ROOT/.agents/skills or $HOME/.agents/skills, as described in the Codex Skills guide. Codex then discovers them through the Agent Skills standard and loads SKILL.md when it decides the skill fits or when you invoke it explicitly. Gemini CLI uses the gemini-extension.json file in the repository root and installs with a local path or the GitHub URL.

gemini extensions install . --consent

Cursor ships plugin manifests at .cursor-plugin/plugin.json and .mcp.json. The README states the marketplace entry is intentionally limited to hf-cli, and points to hf skills add for everything else. Contributors regenerate manifests with ./scripts/publish.sh. That script is the piece most likely to surprise a forker: edit a SKILL.md by hand and the generated manifests and AGENTS.md bundle can drift out of sync until the script runs again.

The fallback when your agent has no skill support

Not every client implements the Agent Skills format. The README offers agentsmd/AGENTS.md directly as a fallback for agents that do not support skills, describing it as a generated bundle of instructions. This is a real escape hatch, but it is a different mechanism: instead of the agent selecting one skill folder and loading its SKILL.md, you are handing the agent one combined file. The trade-off is context. A single bundle covering the hf CLI, datasets, training, local models, evaluation and SageMaker cannot be as selective as loading huggingface-datasets alone when the task is dataset pagination. If your agent supports skills, use them; the fallback exists for the cases where it does not, and the README presents it that way rather than as an equal option.

Limits, failure modes and when this is the wrong tool

The first constraint is client support. If your agent is not Claude Code, Codex, Gemini CLI or Cursor, nothing here loads without the AGENTS.md fallback, and that fallback loses the per-skill selection that makes the format useful. The second is marketplace scope: Cursor and Codex users who expect a one-click bundle of every workflow will not get it, because the README says the marketplace entry is intentionally limited to hf-cli. The third is the AWS-heavy hf-cloud-* set. Those skills assume SageMaker, IAM roles, serving containers and CloudWatch, so they are dead weight for anyone training locally or on other infrastructure. Fourth, hf-cli is generated from your locally installed CLI. That is a strength for freshness and a hazard for reproducibility: two developers on different hf versions can get different instructions from the same repository revision. Finally, the license is Apache-2.0, and the README does not describe a versioning scheme or a changelog, so pinning a known-good revision is on you. This is the wrong tool if you want a hosted service that runs Hub operations for you. It is instruction packaging, and the agent still executes the commands.

Alternatives and how they differ

The most direct alternative is using the hf CLI yourself in a terminal. The difference is who holds the context: with the CLI you read --help and compose commands, while with hf-cli the agent holds the command surface and you describe the outcome. That is faster for exploration and worse for auditability, since you are trusting generated instructions rather than a command you typed. The second alternative is the AGENTS.md fallback already in this repository, which trades skill-level selection for a single always-loaded file. The third is writing your own SKILL.md. Because the format is the standardized Agent Skills format with YAML frontmatter for name and description, a team with a private workflow can follow the same shape, and the README invites contributions of your own skills to the repository. That is the honest comparison: this project is not a runtime, it is a curated set of instruction folders, and its value is the curation rather than any execution machinery.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-18, three days before this writing, so it is being touched. The README lists no releases, which means there are no tagged versions to track and no release notes describing breaking changes. Upgrades therefore happen at the granularity of the default branch and of individual skill folders. The practical cost is low for the skills themselves, since a SKILL.md is text, but the generated artifacts raise it: scripts/generate_agents.py produces the README table and scripts/publish.sh regenerates manifests, so a fork that edits skills without rerunning those scripts will publish stale metadata. On licensing, the repository is Apache-2.0. That permits commercial and private use and requires attribution and notice retention. It does not grant trademark rights, and the README does not state how the Hugging Face name may be used in derivative skill packs. If you plan to redistribute a modified bundle, read the LICENSE file at the repository root rather than relying on this summary.

Editorial conclusion

Adopt huggingface/skills if your agent already runs in Claude Code, Codex, Gemini CLI or Cursor and you want Hub operations such as model search, dataset management, Spaces and Jobs driven by instructions the agent loads itself. Skip it if your tooling has no skill support and you are unwilling to fall back to agentsmd/AGENTS.md, and skip it if you expect one install to cover every workflow, because the Cursor and Codex marketplaces expose only hf-cli. Before committing, verify three things: that your client version discovers skills from the documented locations, that hf-cli generates from your locally installed CLI so the command surface matches your version, and that the skill you actually need appears in the skills/ directory rather than only in the README table.

Frequently asked questions

Official sources

1. huggingface/skills on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README