antigravity-skills: four levels of agent skill, in sample form

A sample repository for the Agentic Command pattern

antigravity-skills contains a collection of example Skills for Google Antigravity and Gemini CLI. The examples demonstrate what the readme calls the Agentic Command pattern, where natural language requests are routed to specialized instructions, tools and context.

That routing idea is the point of the repository. Instead of hoping a general purpose agent handles a request well, you write a skill that intercepts a class of request and gives it a deterministic treatment: a formatting rule, a template, a worked example, or a script.

The skills are organised as four progressive levels of complexity, which is what makes the repository useful as teaching examples rather than as a code drop. The tutorial examples live in `skills_tutorial/`, and a separate `gemini-cli-skills/` directory holds an example for the Gemini CLI specifically.

Around the code there is a reading path. The readme links a Google Cloud blog post on getting started with Antigravity skills, a codelab with the same subject, and a separate community hub repository for more resources, articles and updates on Antigravity. The project itself is small: the top level of the repository holds a README, the `gemini-cli-skills` directory and the `skills_tutorial` directory.

Skills in this system let you define how an agent should behave, which tools it should use, and what context it should reference, and the four levels differ precisely in how much of that they lean on.

Level one is a prompt and nothing else

The first level, Basic Routing, is pure prompt engineering.

The example is `git-commit-formatter`, whose function is to intercept commit requests and format the message according to the Conventional Commits specification. Its key file is `SKILL.md` and that is the entire implementation.

This is the baseline, and it is worth being clear about what it does and does not do. The skill does not run a formatter, it does not parse git history, and it does not guarantee a valid commit message. It routes the request to a set of instructions that describe how a Conventional Commits message should look, and the agent writes the message accordingly.

The reason this is the right place to start is that it isolates the mechanism. When a skill is a single markdown file with instructions, the only variable is the quality of the instructions, and any weirdness in the result is a prompt problem rather than an integration problem. Every later level adds one new mechanism on top of that same foundation, so the progression is a controlled comparison rather than four unrelated examples.

For a team that writes commit messages by hand and disagrees about the format, this is also the most immediately useful of the four.

Level two adds a file on disk

The second level is Asset Utilization, and the example is `license-header-adder`.

Its concept is loading static resources, and its function is to add a standard Apache 2.0 licence header to source files by reading a template from the `resources/` folder. The key files are `SKILL.md` and `resources/HEADER_TEMPLATE.txt`.

The difference from level one is the source of truth. A prompt describes what the header should look like; a template file is the header. That is a meaningful upgrade for anything that has to be byte-identical across many files, because a licence header with a wrong year or a wrong copyright holder is a legal nuisance, and prose instructions are a poor way to guarantee exact text.

It also demonstrates the shape of a skill that carries resources, which is a directory with a SKILL.md and a resources folder beside it. That layout is what you copy into your workspace later, and it is why the installation step in the readme copies whole folders rather than individual files.

The example is deliberately small, but the pattern generalises to any skill whose output must be copied verbatim into a codebase.

Level three replaces instructions with a worked example

The third level is Few-Shot Learning, and the example is `json-to-pydantic`.

Its concept is learning by example. Its function is to convert JSON data into Pydantic models by referencing a golden example pair, an input JSON alongside its output Python, rather than relying on complex instructions. The key files are `SKILL.md` and the `examples/` directory.

The idea is that a single correct transformation teaches more than a paragraph of rules, and the `examples/` folder is where that transformation lives. This is the level where the skill stops being about formatting and starts being about a real transformation with a right answer that can be checked.

It is also the level where a designer has to make a judgement the earlier examples avoid. One golden pair encodes a lot of decisions at once, such as how nested objects are modelled, how optional fields are typed and how lists are declared. If the example is unrepresentative, the agent will follow it faithfully and produce the wrong result, so the example has to be chosen to stand for the common case rather than the interesting one.

The `examples/` directory in the key files list is the visible sign of that: the skill is not just a file of text, it carries data that the model is expected to imitate.

Level four hands the work to a script

The fourth level is Tool Use and Validation, and the example is `database-schema-validator`.

Its concept is delegating to deterministic scripts. Its function is to validate SQL schema files for safety and naming conventions by running a Python script, ensuring accurate results. The key files are `SKILL.md` and `scripts/validate_schema.py`.

This is the level that changes the reliability argument. A model reading a schema file and judging naming conventions is a probabilistic process. A model running a validator script and reporting what it said is a deterministic one, and the check becomes something you can write a test for.

The pattern generalises to the cases where a model should not be the arbiter at all. Anything with a right answer that can be expressed as code, formatting checks, schema validation, conversions, linting, is better handled by a script that the agent calls, because then the agent's job is reduced to selecting and running the right check and explaining the result.

The `scripts/` directory in the key files list is the marker of that design. It is also the level with the most operational weight, since the script now has to exist, be correct, and be kept in step with the conventions it enforces, which is a maintenance commitment that the earlier three levels do not carry.

Installing a skill means copying a folder and restarting

The usage section of the readme is three steps, and there is no package manager, no installer and no registry involved.

1. Clone this repository.
2. Copy the desired folders from `skills_tutorial/` into your workspace's `.agent/skills/` directory, or into your global `~/.gemini/antigravity/skills/` directory.
3. Restart your agent session.

The choice between the two destinations is the decision that matters. A workspace directory scopes the skill to one project, so a repository specific convention like the licence header adder or the commit formatter can live with the code it applies to. The global directory applies to everything you run, which suits a preference you want everywhere.

The restart is because the agent session reads the skills directory when it starts. A newly copied skill is not picked up mid-session, which is a small thing to know before you conclude that a skill is broken.

Since the install is a copy, there is no version tracking. If you later change a skill in this repository, your copy does not change, and the same applies to a copy you made in a workspace. For example material that is a reasonable trade, and it is also the reason to treat the examples as templates to adapt rather than as components to depend on.

The Gemini CLI example and the state of the repository

The `gemini-cli-skills` directory holds one example, `always-verify-gcp`, whose concept is validating GCP commands with the latest official documentation.

Its function is specific: the skill interprets ambiguous Google Cloud commands by first consulting the official documentation through the Developer Knowledge MCP Server, and then using the `ask_user` tool to provide a validated response. The key file is `SKILL.md`.

Two things are notable. The skill does not answer from its own memory, it consults a documentation source first, which is a way of handling the case where a cloud command is ambiguous or where the documentation has moved on. And it uses an ask user tool rather than acting on its own, so the human stays in the loop at the point where a wrong answer would be acted upon.

As a repository, it is minimal in the way a sample project should be. The top level holds a README, the `gemini-cli-skills` directory and the `skills_tutorial` directory, and there are no GitHub releases, so there is no version history to consult.

On licensing, the README states Apache 2.0 while the licence field for the project itself is left unset in the repository listing, which is a discrepancy worth resolving before you copy anything into a codebase of your own. The last push was on 2026-06-27 and the repository is not archived, so the examples are there, but this is a small teaching repository rather than a maintained distribution.

Editorial conclusion

antigravity-skills suits a developer who wants to understand the Skills format for Google Antigravity or Gemini CLI before writing their own, and it suits a trainer who needs four working examples of increasing complexity. It is a poor fit as a production dependency, because it is a handful of example folders rather than a package with a release line, and it is a poor fit if you want prebuilt skills for a domain, since the examples are about git commits, licence headers, JSON conversion and SQL schema validation. Before you copy anything, read the blog post and the codelab that go with the repository, and note that installing a skill means copying a directory and restarting the session, with no update mechanism to track later changes.

Frequently asked questions

Official sources

1. Issues
2. README
3. rominirani/antigravity-skills on GitHub