How to Migrate from the Claude Ecosystem to the Antigravity Ecosystem

I hit Claude's usage limit while I still had work to finish.

Switching to another agent sounded simple. Open Antigravity, give it the task, keep going.

Except I wasn't starting with a blank assistant. I had built up skills for reviewing code, writing in my voice, generating diagrams, checking deployments, and remembering project decisions. Switching tools meant risking all the small instructions that made my workflow feel like mine.

I didn't need a new workflow. I needed my existing workflow to work somewhere else.

That became the migration: bring my reusable skills into Google Antigravity, keep GitHub Copilot connected to the same source, and separate the parts that genuinely transfer from the parts that only look portable.

The workflow moves through shared instructions. The old conversation, account and permissions do not move with it.

First, what is an agent skill?

A skill is a reusable procedure an AI agent can load when a task needs it. Think of it as a playbook with a description on the cover.

For example, my blogging skill defines how to research a topic, write in my voice, format the article, generate visuals, and stop before publication. I shouldn't need to explain those expectations every time I write a post.

The basic package is small:

blog-workflow/
  SKILL.md
  references/
  scripts/
  assets/

Only SKILL.md is essential. The other folders hold supporting material when needed.

---
name: blog-workflow
description: Drafts and revises technical blog posts with diagrams and contextual GIFs. Use when writing or improving an article.
---

1. Verify the technical claims against primary sources.
2. Open with the reader's problem and the practical payoff.
3. Generate a cover, an explanatory diagram and useful motion.
4. Check the rendered article and every image URL.
5. Save as a draft. Never publish without explicit approval.

The agent first sees the name and description. It reads the full instructions when the skill becomes relevant. This is progressive disclosure, not a promise that every installed skill's complete contents are loaded into every prompt.

Claude Code, GitHub Copilot and Antigravity support this shared concept through the Agent Skills standard. Their extra features, discovery paths and permission models still differ.

What I was actually migrating

Not a subscription. Not a model. Not my entire chat history.

I was moving the reusable instructions and their dependencies into places another agent could discover.

The reason I switched was continuity after hitting a limit. That is different from claiming Antigravity is always cheaper, unlimited, or guaranteed to use a particular model. I did not benchmark those claims.

Step 1: Audit before linking anything

My original inventory counted 53 entries across shared, Claude-specific, nested design and Obsidian-related locations.

But a count is not a migration test. A directory can exist while its link is broken, its scripts are missing, or its instructions depend on tools the new agent doesn't have.

The follow-up audit separated 43 reusable global skills from 10 existing Obsidian-scoped links. I kept those project-specific links out of the new global-sharing pipeline. I also found two unrelated broken legacy links in Claude's directory and left them untouched rather than silently deleting them.

For each skill, I checked:

• Where does the directory actually resolve?
• Does it contain a readable SKILL.md?
• Does it reference scripts, templates or prompt files elsewhere?
• Does another directory contain a different skill with the same name?
• Is this genuinely a global skill, or does it belong to one project?

Resolve duplicate names before choosing a source of truth. Copying the newest file over everything else is not a safe merge strategy.

Step 2: Use the receiving agent's real discovery paths

Here are the relevant personal locations from the official documentation I checked for this revision:

Antigravity has multiple surfaces. Check the documentation for the one you use rather than assuming an IDE, CLI and desktop release have identical paths.

On this Mac, I already had shared skills under ~/.agents/skills/. Most Claude entries pointed there. Several other skills still lived in their original Claude directories.

There was no need to rewrite their Markdown or move their working directories. I linked the missing discovery entries to the same original directories, preserving their scripts and relative references.

For a single skill already stored in the shared directory, the pattern is:

source="$HOME/.agents/skills/blog-workflow"
test -f "$source/SKILL.md" || exit 1

for root in "$HOME/.claude/skills" \
            "$HOME/.copilot/skills" \
            "$HOME/.gemini/config/skills"; do
  mkdir -p "$root"
  target="$root/blog-workflow"
  if [ -e "$target" ] || [ -L "$target" ]; then
    printf 'Inspect existing entry: %s\n' "$target"
  else
    ln -s "$source" "$target"
  fi
done

Notice what is missing: ln -sf. An existing directory or broken link deserves inspection, not forced replacement.

For my larger library, an idempotent local script checks for conflicts before adding missing links. It doesn't copy credentials, scan chat histories, or promote project-specific skills into global scope.

Step 3: Keep updates bidirectional

Copying a skill into three folders solves today's migration. It creates tomorrow's drift.

With directory links, the three paths open the same underlying file. Edit the linked skill through Claude's directory, Copilot's directory or Antigravity's directory, and the other paths expose that change immediately.

These are filesystem aliases, not three replicas exchanging network messages. Existing sessions may need to reload instructions.

The local pipeline now verifies 43 global skills across all three ecosystems. Its disposable tests write through each path and confirm that every peer reads the same bytes. It also tests new-skill registration, repeated runs, name conflicts and broken destinations.

Existing linked skills need no background service. After creating a new skill directory, I rerun the link-registration script. Deleting a discovery link is not the same as deleting the shared skill; removals are deliberate, not automatically propagated.

There are limits:

• This shares files on one machine. Another laptop needs its own installation or a separate versioned distribution process.
• Shared files do not merge simultaneous edits. Two agents editing one skill can still overwrite each other's work.
• A model that already loaded the old instructions may need a fresh invocation or session.
• Matching files do not prove matching output quality.

Step 4: Port the dependencies, not just the Markdown

Some of my skills are routers. Their SKILL.md tells the agent to read a canonical prompt stored in my VS Code user-prompts directory.

That works on this Mac because the file exists and the receiving agent can be granted access. It is not a portable package by itself. On a new machine, I would include the referenced material inside the skill bundle or deliberately migrate that dependency too.

Three other details deserve their own checks.

Hooks are not prompt reminders. Antigravity's current documentation includes lifecycle hooks. The question is whether your specific event, payload and tool names map correctly. Replacing an enforced pre-tool check with “please remember to check” weakens the guarantee.

A named tool is not an installed tool. A skill mentioning an image generator, browser or MCP server doesn't make that capability available. Check the receiving agent's tools and authenticate only what the workflow needs.

A denied write is a boundary, not a migration trick. Use the product's supported setup and permission flow. Don't route around a denied operation through a different tool and call that portability.

Step 5: Test one real workflow before trusting the library

My concrete example is this blogging workflow. Instead of separate reminders to write, format, draw a diagram and make a GIF, one skill now orchestrates the whole draft:

1. Verify the story and technical claims.
2. Write a problem-led article with useful examples.
3. Generate a custom cover, static explanation and contextual animations.
4. Check readability, image delivery and the rendered draft.
5. Stop before publishing.

That last step mattered more than I expected. The old instructions called queue/ a review area, but the scheduler treated every Markdown file there as approved for publication. Another helper named update explicitly forced the article live.

I corrected the workflow to keep unapproved work in drafts/ and update an existing remote draft with published: false.

Porting an instruction faithfully is not enough if the instruction is wrong.

For a receiving agent, my smoke-test prompt is:

Use my blogging skill to outline a migration article.
Read its canonical instructions and list the required visual assets.
Do not publish, upload, commit or push anything.
Report any missing files or tools instead of substituting silently.

I separate two results: the filesystem checks pass; application discovery, tool execution and output quality must still be checked inside each receiving application. This revision does not claim an end-to-end run of every skill in all three agents.

What I would repeat

Start with the skill you use every day. Make its dependencies explicit. Keep one editable source. Test both the useful output and the “must not do” rules.

The useful outcome wasn't the number of folders I could migrate. It was keeping my accumulated workflow knowledge available when one tool hit a limit.

Changing agents should not mean rebuilding how you work. But sharing a playbook is not the same as sharing an entire runtime.

Which part of your setup would be hardest to carry to another agent: skills, hooks, tool access, or project context?

Sources

• Agent Skills specification
• Claude Code skills and symlinked folders
• GitHub Copilot Agent Skills in VS Code
• Antigravity skills and surface-specific locations
• Antigravity lifecycle hooks

Diagrams are original explanatory illustrations, not product screenshots. Product names belong to their respective owners. Paths describe the documented surfaces above and my local setup, not a universal installer.