Antigravity Skills Show Where Coding Agents Are Heading: Less Tool Bloat, More Team Policy
The most important coding-agent feature of the month may be a directory with a Markdown file in it. That sounds like underselling it. It is not. Google’s updated Antigravity Skills material points at the part of agentic development that teams are finally being forced to operationalize: how do you give an AI agent project-specific judgment without dumping your entire company handbook, tool catalog, deployment process, and security policy into every prompt?
The answer Google is teaching is Agent Skills: lightweight, directory-based packages containing a SKILL.md file plus optional scripts, references, templates, examples, and assets. A skill has YAML frontmatter for routing metadata and Markdown instructions for the actual procedure. The important field is the description, because the agent uses it as the semantic trigger. A vague description like “database tools” is bad. A precise description like “executes read-only SQL queries against the local PostgreSQL database to retrieve user or transaction data” tells the router when to load it and, just as importantly, when not to.
This is not customization fluff. It is the architecture pattern coding agents need if they are going to survive contact with real engineering teams.
The enemy is not small context windows anymore. It is context obesity.
The updated Google Cloud Community tutorial and Google Codelab both frame the problem bluntly: modern agents already have large context windows and many tools, but indiscriminately loading everything creates context saturation, latency, cost, and what the tutorial calls “context rot.” The examples are familiar to anyone who has wired up MCP servers with enthusiasm and then watched the agent get weird. GitHub MCP can expose around 50 tools. Playwright MCP can expose 24. Chrome DevTools MCP can expose 26. A developer can easily hand an agent 40–50K tokens of tool descriptions before the actual work even begins.
That is not intelligence. That is a junk drawer with an API key.
Skills solve a different problem than bigger context windows. Bigger context lets the model hold more. Skills decide what it should hold right now. The pattern is progressive disclosure: the agent sees a lightweight menu of available capabilities, then loads the heavier procedural knowledge only when the user’s request matches a skill. If a developer asks to refactor authentication middleware, the agent should load the security and project-structure guidance, not the CSS build pipeline, marketing asset policy, and every GitHub operation the MCP server can perform.
This is where the Antigravity material becomes more interesting than a how-to post. Google is effectively acknowledging that agent performance is not only a model problem. It is a context-management problem, a policy-distribution problem, and a team-practices problem. The model can be excellent and still fail if it is surrounded by irrelevant tools, stale instructions, and unreviewed local automation.
Skills are the missing middle between prompts and infrastructure
The useful distinction in the Codelab is the “hands versus brains” framing. MCP provides the hands: persistent connections to systems like GitHub, PostgreSQL, Slack, browsers, and internal services. It is powerful because it gives agents live capabilities. It is also operationally heavy because it involves servers, credentials, schemas, lifecycle management, network access, ports, state, and security review.
Skills provide the brains: the method for using tools safely and consistently. A database migration skill can say which checks must run, which environments are forbidden, how to inspect schema drift, when to ask for approval, and which script to use for deterministic validation. It may call an MCP tool, but it does not need to be an MCP server itself. For many local engineering tasks, a skill with a small script is safer and cheaper than a persistent tool service.
That matters because agent teams are already overusing MCP as the default answer to every problem. Need a changelog? MCP server. Need commit formatting? MCP server. Need to add a license header? MCP server. Need to validate a schema? MCP server. That is how a simple agent setup turns into a tiny distributed system nobody wanted to operate. Skills give teams a more boring and better option: put methodology in files, put deterministic work in scripts, version them with the repo, and load them only when needed.
The sample Antigravity skills make this concrete. git-commit-formatter encodes Conventional Commits. license-header-adder keeps a static Apache 2.0 header in a resource file instead of making the model recreate legal text from vibes. json-to-pydantic uses examples so the model learns the desired pattern rather than interpreting a wall of rules. database-schema-validator delegates deterministic checking to a Python script. These are not glamorous demos. That is exactly why they are useful. They turn repeated team habits into reviewable assets.
Policy belongs near the code
The Antigravity paths are also telling. Project skills for Antigravity live under /.agents/skills/; global skills live under ~/.agents/skills/. For Antigravity CLI, project skills live under /.agent/skills/; global skills live under ~/.gemini/antigravity-cli/skills/. The split matters. Project-specific policy should live with the project. Personal convenience skills should not silently leak into a team repo. Global habits are useful, but they are also a source of invisible behavior differences between developers.
If your production-deploy process, database safety checklist, migration style, release-note format, cloud-command verification rule, or security-review standard is important, it should be versioned, reviewed, and discoverable. A skill is a good place for that because it is close enough to the agent to affect behavior and close enough to the repo to be treated like software. A Slack message from six months ago is not governance. A prompt snippet in someone’s dotfiles is not team policy. A reviewed SKILL.md with scripts and examples can be.
There is a catch: skills can also become a new supply-chain surface. A bad skill description can trigger at the wrong time. A stale reference can teach the agent an obsolete deployment path. A script can be destructive. A global skill can smuggle personal assumptions into a client project. A skill that says “always run this command” can become a footgun with Markdown syntax. The file may look harmless, but from the agent’s perspective it is part of the operating system.
Teams should treat skills like code-adjacent automation. Require review for project skills. Prefer read-only defaults. Make destructive actions ask for human confirmation. Keep scripts small and deterministic. Pin references instead of linking to mutable docs without context. Include explicit “do not” rules. Add examples for common success and failure cases. Audit global skills separately from repo skills. If a skill touches production, credentials, customer data, billing, or deployment, it deserves the same seriousness as any other automation that can change state.
The coding-agent comparison just got less about models
For teams comparing Antigravity, Claude Code, Codex, Cursor, OpenCode, and OpenClaw-style routers, skills are now a strategic feature, not a side panel. The winning agent platform will not be the one that can ingest the largest pile of context. It will be the one that lets teams express judgment cleanly: when to run tests, how to write commits, what secrets never to expose, how to verify cloud commands, how to inspect a database safely, when to escalate to a human, and how to recover when a tool fails.
This is also why Google’s timing matters. The Gemini CLI to Antigravity migration is pushing developers toward a more structured runtime. Skills are the softer half of that platform move. Plugins, MCP, Workspace auth, and Google Cloud projects give agents access to systems. Skills tell agents how to behave once they have access. One without the other is dangerous in opposite directions: tools without policy are powerful and sloppy; policy without tools is safe and inert.
The practical move is not to create a skill for everything. Start where repetition and risk overlap. Create a commit-message skill. A test-runner skill. A safe database-inspection skill. A migration-checklist skill. A cloud-command verification skill that requires official docs before suggesting destructive infrastructure commands. Measure whether they reduce repeated prompting, failed tool calls, token waste, and review friction. Then add workflow-level skills only after the small ones prove useful.
Do not dump your engineering handbook into SKILL.md and call it context engineering. That is just context rot with a filename. Good skills are narrow, triggered precisely, backed by examples, and paired with deterministic scripts where the model should not improvise. The boring shape is the point.
Google’s Antigravity Skills update is not a flashy model launch, and that is why it is worth attention. Models make agents possible. Skills make them operable. If coding agents are going to become part of normal software delivery, the hard work will look less like prompting magic and more like writing small, reviewed instruction packages that encode how a team actually works. Looks pedestrian. Ships better.
Sources: Google Cloud Community, Google Codelabs, rominirani/antigravity-skills, Anthropic