# Antigravity workflows retire on November 1, 2026: how to convert them to skills

Canonical: https://clawdocx.com/blog/antigravity-workflows-to-skills
Author: Theo Marsh
Published: 2026-09-22
Updated: 2026-09-22

> Google retires Antigravity workflows on November 1, 2026. Run /migrate-workflows to convert them to Agent Skills, and check the skill paths for your surface.

Run `/migrate-workflows` in Antigravity 2.0 before 1 November 2026 and Google converts your workflows into Agent Skills for you, without a rewrite. Google's migration guide states that workflows "are deprecated and will be retired on November 1, 2026", and that after that date "workflow directories will no longer be indexed or executable via slash commands". The commands you already type survive the move, because a skill in `.agents/skills/<name>/` is invoked as `/<name>` exactly as the workflow was.

## What exactly retires on 1 November 2026?

Workflows are the older of Google's two ways to script a repeated task in Antigravity. The [IDE Workflows](https://antigravity.google/docs/ide/workflows) page describes them as a way to "define a series of steps to guide the Agent through a repetitive set of tasks", saved as markdown files, invoked "via a slash command with the format /workflow-name", and limited to 12,000 characters each. They are created from the Customizations panel, either globally or per workspace.

The deprecation notice appears on two of Google's own pages. The migration guide carries it in full:

> Workflows are deprecated and will be retired on November 1, 2026.
>
> Existing workflows will continue to work until this date, but we recommend migrating to Agent Skills to take advantage of progressive disclosure, directory-based asset bundling, and open ecosystem interoperability.

The IDE Workflows page repeats the same date, pointing readers at the migration guide or at the `/migrate-workflows` command.

One thing the documentation does not say is that your files are deleted. The FAQ answer is narrower than that: "After this date, workflow directories will no longer be indexed or executable via slash commands." The markdown stays on disk. What stops is discovery and invocation, which is the part any script or habit of yours depends on.

Google's stated reason for the change is that Antigravity adopted the open Agent Skills standard in May 2026, and that a single monolithic markdown file could not carry helper scripts or reference material alongside its instructions. If you have not met the format before, our guide to [what a SKILL.md actually is](/docs/skills-explained) covers the shape that Antigravity is moving to.

## What changes when a workflow becomes a skill?

Google publishes a feature-by-feature comparison in the migration guide. The rows that change something practical for you are these:

| Feature | Legacy workflow (`.md`) | Agent skill (`SKILL.md`) |
|---|---|---|
| Specification | Proprietary Antigravity format | Open Agent Skills standard (agentskills.io) |
| Structure | Single standalone `.md` file | Directory bundle: `<skill-name>/SKILL.md` plus assets |
| Workspace path | `.agents/workflows/<name>.md` | `.agents/skills/<name>/SKILL.md` |
| Global path | `~/.gemini/config/workflows/<name>.md` | `~/.gemini/config/skills/<name>/SKILL.md` |
| Context loading | Entire file loaded into the prompt | Metadata indexed upfront, body loaded on demand |
| Bundled assets | Not supported | Supported: `scripts/`, `references/`, `examples/` |
| Slash commands | `/<workflow-name>` | `/<skill-name>` |
| File size limit | 12,000 characters | Unrestricted bundle, modular multi-file architecture |

The size limit is the row worth acting on. A workflow that was trimmed to fit under 12,000 characters can be reassembled properly once it is a bundle, with the long reference material moved into `references/` and the shell steps moved into `scripts/`.

## How do you run the automatic migration?

Open Antigravity 2.0 and run the command:

```
/migrate-workflows
```

Google's guide lists exactly what the agent then does:

1. Scans both global (`~/.gemini/config/workflows/`) and workspace-level (`.agents/workflows/`) directories.
2. Parses each workflow's YAML frontmatter and body.
3. Scaffolds `.agents/skills/<workflow-name>/SKILL.md` with compliant metadata.
4. Archives the original workflow files by appending `.bak`, so `deploy.md` becomes `deploy.md.bak`.
5. Activates the new skills immediately, for slash commands and for autonomous use.

Step 4 is why this is low risk to try. The originals are renamed rather than removed, and Google's FAQ confirms that where a workflow and a skill share a name, "Antigravity will execute the skill", so a half-finished migration does not leave you running both.

Step 3 is the one to read carefully. The command scans the global workflow directory as well as the workspace one, but the scaffolding step the documentation describes writes into the workspace path, `.agents/skills/<workflow-name>/`. If you keep workflows globally, check where each one landed before you trust the result, and move it to `~/.gemini/config/skills/<name>/SKILL.md` if you want it available across every project.

## How do you migrate a workflow by hand?

Worth doing for any workflow you have wanted to split up. Google documents four steps.

Create the skill directory:

```bash
mkdir -p .agents/skills/deploy-staging
```

Move the workflow file into it as `SKILL.md`:

```bash
mv .agents/workflows/deploy-staging.md .agents/skills/deploy-staging/SKILL.md
```

Standardise the frontmatter. Only two fields are involved, and only one of them is required. The [Agent Skills reference](https://antigravity.google/docs/skills/) lists `description` as required, "a clear description of what the skill does and when to use it", and `name` as optional, defaulting to the folder name when it is absent:

```yaml
---
name: deploy-staging
description: Deploys the current project build to the staging preview environment on App Engine. Use when testing staging releases or verifying PR previews.
---
```

Then extract anything bulky, which is the step that earns the migration:

```
.agents/skills/deploy-staging/
├── SKILL.md
├── scripts/
│   └── deploy.sh
└── references/
    └── staging-endpoints.json
```

Google's instruction for the body is to point at those files rather than paste them: "instruct the agent to run or inspect those files when needed rather than duplicating them in the prompt". That is the whole point of progressive disclosure, and it is the same discipline described in our guide to [building a custom skill](/docs/building-custom-skills).

Verify by invoking the skill directly, for example `/deploy-staging`, and watching the agent load the metadata and run the steps.

## Where do migrated skills have to live on each surface?

This is the part most likely to cost you an afternoon, because Antigravity has three surfaces and they do not share a global directory. The Agent Skills reference gives these locations:

| Surface | Workspace skills | Global skills |
|---|---|---|
| Antigravity 2.0 | `<workspace-root>/.agents/skills/<skill-folder>/` | `~/.gemini/config/skills/<skill-folder>/` |
| Antigravity CLI (`agy`) | `<workspace-root>/.agents/skills/<skill-folder>/` | `~/.gemini/antigravity-cli/skills/<skill-folder>/` |
| Antigravity IDE | `<workspace-root>/.agents/skills/<skill-folder>/` | `~/.gemini/config/skills/<skill-folder>/` |

The workspace path is the same everywhere, so a skill committed to a repository is picked up by all three. The global path is not: the CLI reads `~/.gemini/antigravity-cli/skills/`, while Antigravity 2.0 and the IDE read `~/.gemini/config/skills/`. The migration guide names only the `config` path, so if you work mainly in `agy`, a global workflow migrated by the command will not be where the CLI looks for it. Copy it across, or keep the skill in the workspace where every surface agrees.

Two smaller path notes from the same reference: Antigravity "defaults to `.agents/skills`, but still maintains backward compatibility for `.agent/skills`", singular; and the IDE also still supports a legacy `~/.gemini/antigravity/skills/` global directory. The CLI additionally loads plugin-provided skills from `~/.gemini/antigravity-cli/plugins/<name>/skills/`, and lists them with `agy plugin list`.

## What should you check before 1 November?

A short list, in the order that a missed item hurts:

- **Global workflows.** Find them in `~/.gemini/config/workflows/` and confirm each one has a skill directory, on the path your surface actually reads.
- **Workflows that call other workflows.** The IDE Workflows page documents this pattern: `/workflow-1` can contain instructions like "Call /workflow-2". Google's guide does not discuss what happens to those references after migration. The names line up, because each skill is named after its workflow and any skill is invocable as `/<name>`, but that is worth running once rather than assuming.
- **The `.bak` files.** They are your rollback until 1 November. Leave them in place until the replacement skill has actually run.
- **Anything outside Antigravity that types the slash command.** A CI step, a script or a teammate's notes referring to `/deploy-staging` keeps working, since the skill takes the same name, but only if the skill exists where that surface looks.
- **Workflows you no longer use.** The migration converts everything it finds. A deprecation is a reasonable moment to not carry dead prompts forward.

Because skills follow the open standard rather than a Google-only format, a skill you write for Antigravity can be shared with other compliant tools, and skills written elsewhere can be dropped into `.agents/skills/`. Treat anything you did not write as untrusted code and read it before you enable it. Our [SKILL.md audit checklist](/docs/skill-security-audit) is the process for that; ClawDocx does not vet or endorse third-party skills.

If you want the wider picture of what else Antigravity supports, including plugins, MCP servers and hooks, the [Antigravity platform hub](/ai-agents/antigravity) tracks it.

## Frequently asked questions

**When do Antigravity workflows stop working?**

Google's migration guide says workflows are deprecated and will be retired on November 1, 2026. Existing workflows keep working until that date, after which workflow directories are no longer indexed or executable via slash commands.

**Do I have to migrate my workflows by hand?**

No. Antigravity ships a /migrate-workflows slash command that scans your global and workspace workflow directories, scaffolds a skill bundle for each one, and renames the originals with a .bak suffix. Manual migration is documented as an option if you want to split a long workflow into a multi-file bundle.

**Will my slash commands still work after migrating?**

Yes. Google's migration FAQ states that any skill in .agents/skills/<name>/ or ~/.gemini/config/skills/<name>/ can be invoked via /<name> in chat, just like legacy workflows. The automatic migration names each skill after the workflow it came from, so the command you already type keeps matching.

**What happens if I have a workflow and a skill with the same name?**

Skills take precedence. Google's FAQ says that if both .agents/skills/deploy/ and .agents/workflows/deploy.md exist, Antigravity executes the skill. That makes the migration safe to run before you delete anything.

**Where do global skills go in the Antigravity CLI?**

The CLI uses ~/.gemini/antigravity-cli/skills/<skill-folder>/ for global skills, which is a different directory from the ~/.gemini/config/skills/ path that Antigravity 2.0 and the IDE use. The migration guide names only the config path, so check the CLI location yourself if you work in agy.

## Sources

- [Antigravity docs: Migrating from Workflows to Skills](https://antigravity.google/docs/migration/workflows-to-skills/)
- [Antigravity docs: Agent Skills](https://antigravity.google/docs/skills/)
- [Antigravity docs: IDE Workflows](https://antigravity.google/docs/ide/workflows)
- [Antigravity docs: Rules and Workflows](https://antigravity.google/docs/rules-workflows/)