How I cut skill overload in Google Antigravity: a per-project skill library

The Honeymoon Ends with Token Limits

I use Google Antigravity 2.0 as my primary AI coding environment. When you first start pairing with autonomous coding agents, the experience feels like magic: you find an interesting capability in the community or marketplace, install it, and watch the agent run with it.

Then time passes.

A few weeks in, I had accumulated roughly 60 custom skills and 13 plugins—including massive toolsets like Flutter (24 skills), Chrome DevTools (7 skills), Google Workspace (5 separate plugins), ACE Studio for music production (4 skills), Gemini API tools, Android development, and Superpowers (14 skills). And every single one of them was loaded into every single project.

When I opened the workspace for my personal portfolio—a lightweight, static HTML and CSS site—the agent's context was immediately flooded with 24 Flutter mobile skills and vocal synthesis tools.

To understand why this breaks down, you have to look at how Antigravity handles skills under the hood. A skill is a folder containing a SKILL.md file. At the start of every session, Antigravity reads the name and description of every installed skill so the agent knows what exists in its toolkit. The full instruction body only loads when a skill is actively triggered, which is efficient per skill. However, skill descriptions add up fast. At roughly 50 to 100 tokens per skill description by my estimate, having ~120 active skills across plugins and standalone folders meant burning roughly 6,000 to 12,000 tokens before I had typed my very first prompt.

Worse than the token bill was tool confusion. When an agent has dozens of near-matching descriptions loaded into context, the probability of selecting an irrelevant tool skyrockets. Having a static web project list Dart testing utilities and audio-pitch algorithms creates needless cognitive noise for the LLM.

After this setup proved itself in Antigravity, I applied the same architecture to Claude Code so both tools now share one unified skill library and helper script, and expanded it to support a 2,750-skill third-party catalog with on-demand search.

Looking for Existing Solutions First

Before building anything custom, I spent time looking for battle-tested solutions. My rule was simple: adopt proven tools that have already worked for others rather than invent new machinery.

What I found fell into two distinct categories:

• Token reduction: Proven tools already existed. Julius Brussee's Caveman—a system prompt technique that forces the agent to speak with concise, high-density technical prose—had over 75,000 GitHub stars and 300,000+ installs on the skills registry. Furthermore, tokless bundled Caveman alongside other token-saving utilities and supported Antigravity directly (~270 stars, actively maintained).
• Skill management: Here, the ecosystem was virtually empty. The closest attempts were an "Agent Kits" filter skill (3 GitHub stars, which only filtered its own bundled tools) and an experimental "skill router" (0 stars, which attempted to select skills without actually disabling any, thereby increasing the token load). Neither met the bar of a proven, dependable solution.

My path forward was clear: adopt tokless for baseline session token efficiency, and design a lean, reversible system to manage skills per project.

Layer 1: The Token-Saving Baseline (tokless)

The first layer was wiring tokless into Antigravity. It installs a suite of specialized token-saving tools into the agent's workflow:

The macOS App PATH Gotcha

Right after installation, tokless doctor reported that everything was healthy. Yet, two critical MCP tools—codegraph and context-mode—never appeared in Antigravity's active tool list.

The cause: both tools are Node.js applications starting with the shebang #!/usr/bin/env node. Node was installed under /usr/local/bin. While macOS Terminal inherits a complete user PATH, desktop applications launched from the Dock or Finder receive a stripped-down default system PATH (/usr/bin:/bin:/usr/sbin:/sbin). The MCP servers were failing silently on launch.

Running a test with an isolated environment proved the diagnosis immediately:

env -i PATH=/usr/bin:/bin:/usr/sbin:/sbin ~/.local/bin/codegraph --version
# -> env: node: No such file or directory

The Fix: Explicitly pass the correct PATH inside the MCP server definition in Antigravity's mcp_config.json:

"env": {
  "PATH": "/usr/local/bin:~/.local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
}

The same issue affected RTK when the terminal hook executed, producing command not found: rtk. Adding export PATH="$HOME/.local/bin:/usr/local/bin:$PATH" to ~/.zshenv ensured that non-interactive subshells inherited the binary.

The lesson: On macOS, "works in Terminal" never guarantees "works in a desktop application."

Layer 2: The Library Pattern

Antigravity 2.0 has built-in support for workspace-level skills and plugins: skills placed in <project>/.agents/skills/ and plugins placed in <project>/.agents/plugins/ load only when that specific workspace is open.

The core idea of the library pattern is simple: move all non-essential skills and plugins into storage directories that Antigravity does not scan, and copy into each project only what that specific project requires.

~/skill-library/            ~60 skills (inactive, unscanned storage)
~/plugin-library/           11 plugins (inactive, unscanned storage)

~/.agents/skills/           Global skills: only "project-starter"
~/.gemini/config/plugins/   Global plugins: "superpowers", "google-developer-knowledge"

<project>/.agents/skills/   This project's specific skills
<project>/.agents/plugins/  This project's specific plugins

The Result: Global user skills dropped from ~60 to 1 (project-starter). Global plugins dropped from 13 to 2 (superpowers and google-developer-knowledge). A typical project now carries 2 to 5 skills and 0 to 2 plugins. For example, my personal website workspace now loads only wrangler and web-perf, plus the chrome-devtools-plugin.

Safety by Design: Every move is logged to .moved.json. If anything ever needs to be reverted, a single restore command puts every file back into its original global folder. Antigravity's config.json is backed up automatically before any edits take place.

Layer 3: The Project Starter Skill

To make this workflow effortless, I authored a small global skill called project-starter backed by a Python CLI (starter.py).

Whenever I tell the agent "start a new project" (Flow A) or "check what this project needs" (Flow B), it follows a disciplined interview:

1. Introspects the libraries: It reads starter.py list and starter.py plugins-list to inspect all available tools.
2. Asks at most 3 targeted questions: It queries only what changes tool selection (runtime environment, hosting target, whether it calls an AI model like Gemini).
3. Presents a lean proposal: It outputs a concise proposal listing selected skills and plugins with a one-line rationale, alongside what was explicitly excluded.
4. Waits for confirmation: Upon approval, it creates the directory and copies only the required tools into .agents/.

Real Proposal Example

For a browser-based client app interacting with the Gemini API and deployed to Cloudflare:

• Skills added: wrangler (for Cloudflare deployment), web-perf (Web Audio API profiling).
• Plugins added: chrome-devtools-plugin (DOM and media debugging), gemini-api (prompt engineering).
• Excluded: workers-best-practices (no custom serverless routes), gsheets (exports are local files).
• De-duplication: I explicitly dropped tdd, because superpowers already provides test-driven-development. Having two skills for the same task wastes tokens and causes the agent to oscillate between them.

For existing repositories, starter.py audit inspects files (pubspec.yaml → Flutter, package.json/HTML → Chrome DevTools, Gemini dependencies → Gemini plugin) and recommends missing tools automatically.

Layer 4: Keeping Library Plugins Updated

Decoupling plugins from Antigravity's global directory created one obvious challenge: Antigravity would no longer automatically update them.

I hit three dead ends trying to solve this:

1. The CLI: Running agy plugin install <name>@antigravity-plugins-official failed with "unknown marketplace" under agy 1.4.7. The CLI parser recognized the syntax, but lacked backend marketplace connectivity.
2. The App UI: The desktop application's plugin settings listed no version numbers and had no manual update button.
3. Manual Reinstallation: Blocked by the same CLI limitation.

What Worked: Inspecting Antigravity's application cache revealed that the app maintains a local copy of the official marketplace catalog on disk. Each plugin entry contains its latest version tag, download URL, and SHA-256 checksum.

I wrote a lightweight update job managed by macOS launchd:

• It compares library plugin versions against the cached marketplace catalog.
• When an update exists, it downloads the archive, validates the SHA-256 checksum, moves the old version to ~/plugin-library/.backups/, and refreshes the copy in any active project under ~/Documents/Antigravity/.
• It never touches Antigravity's runtime configuration while the app is active, and triggers a native macOS notification whenever an update is applied.

Extending the Setup to Claude Code

Once the library pattern was running smoothly in Antigravity, I turned to Claude Code. My Claude Code installation had 38 skills installed globally in ~/.claude/skills—the same general development workflow set that was already sitting in my Antigravity library, since I had originally installed them into both tools concurrently. It also carried one plugin installed globally across every project, alongside skills and a plugin synced directly from my claude.ai account. None of the token-saving utilities were connected yet.

Rather than building a second, parallel system for Claude Code, I extended the existing architecture so both tools share a single source of truth:

1. Connecting Token-Saving Tools: I hooked tokless into Claude Code with a single command (tokless --agents claude). This gave Claude Code the identical token-saving baseline as Antigravity: Caveman concise prose, Ponytail senior-engineer rules, Karpathy principles, RTK terminal condensing, CodeGraph code indexing, Context-Mode sandboxing, and ProjectMem session memory.
2. One Shared Library Instead of Two: Before moving any Claude Code skill, the helper script performs a byte-by-byte file comparison against the existing library copy:
   • Identical content: The skill is moved to a local backup folder, preventing redundant duplicates in the library.
   • Different content: The skill is added to the library with a -claude suffix (e.g. <name>-claude), ensuring neither variation is lost.
   • Not in library: The skill is added directly to ~/skill-library/.
   Skills synced from claude.ai are deliberately left untouched, as they are managed upstream through claude.ai's account settings.
3. Project-Scoped Plugins: Claude Code has native support for installing plugins for a single project (claude plugin install <plugin> --scope project). The plugin that previously burdened every session is now installed strictly inside repositories that use it. Furthermore, because Claude Code manages its own plugin updates natively, no custom update job was needed.
4. One project-starter for Both Tools: The same starter.py CLI powers both tools. Antigravity projects reside in my main workspace directory and receive .agents/skills/; Claude Code repositories live under ~/code and receive .claude/skills/. Each tool maintains its own concise instruction playbook pointing at the shared script and library.

First Measured Result: During early test sessions, RTK—the tool that compresses terminal output before the LLM ingests it—reported its own telemetry: across 38 commands, 8.4K input tokens were processed, saving 3.8K tokens. That represents a 45% token reduction on terminal output. While this is an initial small sample covering terminal commands rather than full end-to-end sessions, it provides real empirical validation rather than theoretical estimates.

Adding a 2,750-Skill Collection: Library vs. Catalog

With both tools sharing a ~60-skill library, I decided to incorporate a large community collection: Agentic Awesome Skills (github.com/sickn33/agentic-awesome-skills), a set of roughly 2,750 SKILL.md playbooks across software engineering, security, and cloud infrastructure, complete with risk classifications where offensive and pentesting skills are explicitly labelled.

This immediately broke my original design assumption.

project-starter originally worked by reading the name and description of every skill in the library before proposing a toolset. Reading 60 skill descriptions consumed negligible tokens. But for 2,750 skills, reading every description would consume roughly 150,000 tokens by my estimate every time I created or audited a project—completely defeating the purpose of token efficiency.

To solve this scale problem without losing access to the collection, I introduced a fundamental architectural separation between a Library and a Catalog:

• The Curated Library (~60 skills): The compact, vetted collection of tools I personally use. Read in full by the agent during interviews, and always preferred whenever a search matches both locations.
• The Inactive Catalog (~2,750 skills): Kept in a dedicated storage folder (~/skill-catalog/) outside the search paths of both Antigravity and Claude Code. It costs exactly zero tokens during regular sessions because the agent never lists or scans it.
• Fast Keyword Search: Instead of reading everything, the agent uses a search <keywords> command. The CLI scores every playbook across title, category, and description text, returning only the top 25 matches across the combined library and catalog. The agent runs 2 to 4 targeted queries based on the project stack. In my tests on a simulated 2,750-skill catalog, a search took about 0.15 seconds.
• Priority & Namespacing: If a skill exists in both places, the library version wins by default. If the agent specifically needs the upstream catalog version, it can reference it explicitly as source:name.
• Safety Guardrails: Offensive and pentesting skills are hidden from search results unless explicitly requested.
• Upstream Synchronization: A catalog-update routine mirrors changes from GitHub into the catalog folder as a read-only source. Active projects keep their copied versions, and local catalog modifications are overwritten upon update (any skill requiring personalization is copied into the library first).

A Security Habit, Not Just a Feature: Catalog skills are authored by many different people. In an agentic environment configured to execute commands autonomously, a skill's instructions are effectively code. My non-negotiable rule: before approving any catalog skill for an active repository, I open and review its SKILL.md and any scripts in its folder.

Workflow Refinements

As the setup matured across two AI agents and thousands of skills, I refined the operational flows:

• Three Explicit Agent Flows: The instruction playbook enforces three predictable flows: creating a new project (Flow A), auditing an existing workspace (Flow B), and provisioning missing plugins (Flow C). Every proposal follows a fixed format: each proposed tool with a one-line reason, plus "considered but left out" and why.
• No-Duplicate Governance: The agent enforces a strict anti-redundancy rule. It will never propose a standalone skill if an active global plugin already covers that capability (e.g. a standalone TDD skill when the Superpowers plugin already includes test-driven development).
• Codebase Heuristic Auditing: The audit workflow inspects codebase signatures—detecting pubspec.yaml for Flutter, package.json and HTML files for Chrome DevTools, or model SDK dependencies for Gemini—and proposes missing tooling automatically.

Lessons Learned

1. Always resolve symlinks before filesystem operations: On macOS, ~/.gemini/config/skills was a symlink pointing to ~/.agents/skills. Early iterations of my script processed the same directory twice and tripped over itself. Resolving realpath before moving files and saving undo logs after each operation solved the problem.
2. Dry runs are mandatory: Any script touching directory hierarchies must support --dry-run and be tested against cloned test fixtures before touching production directories.
3. Trust direct file checks over tool reports: tokless doctor displayed a configuration path that differed from the active file, and the agent initially hypothesized that missing MCP servers "only activate when needed" (which is false for MCP transports). Inspecting process tables and raw config files resolved the discrepancy.
4. Official documentation can drift from reality: The CLI documentation described marketplace commands that the shipped binary could not perform. Always test CLI commands against live binaries.
5. Use the platform's local cache: Finding Antigravity's marketplace catalog cache turned an impossible update process into a reliable, 100-line background routine.
6. Compare before you deduplicate: Same name doesn't mean same content. A file-by-file comparison decided whether a skill was a true duplicate before merging.
7. Scale changes the design: A pattern that's right for 60 items (read everything) is wrong for 2,750 (search). Splitting "curated library" from "big catalog" kept both useful at zero baseline token cost.
8. Each tool has different strengths: Claude Code's built-in per-project plugins and updates made half of the Antigravity workarounds unnecessary there. Check what the tool already does before building around it.
9. Let tools report their own numbers: The first empirical savings figure (45% terminal output reduction) came from RTK's self-reported telemetry, not theoretical estimates.

Caveats

• Terminal Output Boundary: The 45% figure is from a small number of commands and only covers terminal output, not total session tokens.
• Catalog Token Estimate: The ~150,000-token figure for reading the whole catalog is an estimate from description counts.
• Simulated Search Speed: Search speed was measured in my tests on a simulated catalog of the same size.
• Unreviewed Community Skills: Third-party catalog skills are unreviewed until I read them; treat community skill playbooks with the same caution as executable code.
• Estimated Overall Savings: Token savings are estimated based on skill description sizes and prompt counts; individual session savings vary based on conversation length.
• Cache Latency: The Antigravity plugin update job relies on Antigravity refreshing its marketplace catalog cache, which can occasionally lag behind upstream releases.
• Third-Party Reinstalls: Certain third-party desktop apps (such as ACE Studio) manage their own plugins and may reinstall them globally following an application update.

Credits & Resources

• tokless: github.com/HoangP8/tokless
• Caveman: github.com/JuliusBrussee/caveman
• Superpowers: github.com/obra/superpowers
• Agentic Awesome Skills: github.com/sickn33/agentic-awesome-skills
• Claude Code Plugins Documentation: code.claude.com/docs/en/plugins
• Google Antigravity Documentation: Skills Guide · Plugins Guide