migration-guide
Turn a breaking change (an API rename, removed flag, changed default, or moved module) into concrete upgrade steps with before/after examples. Use when the user asks how to migrate, upgrade, or adapt to a breaking change.
git clone --depth 1 https://github.com/omnigent-ai/omnigent /tmp/migration-guide && cp -r /tmp/migration-guide/examples/scribe/skills/migration-guide ~/.claude/skills/migration-guideSKILL.md
# migration-guide — write upgrade steps for a breaking change
Produce a guide that lets a user on the old version land on the new one with the
least friction.
## Pin down what actually broke
Identify the precise breaking change before writing a word. Get it from the diff
and history, not from the description alone:
- `git diff <old>..<new>` on the affected surface, and `gh pr view <n>` for the
PR that introduced it.
- Dispatch the researcher (`purpose: explore`) to confirm the exact old and new
shapes: the old name/signature/default, the new one, and whether a
compatibility shim or deprecation window exists.
Never document a rename or signature change from memory — the exact symbols are
what users will copy.
## Structure
# Migrating to <version>
## What changed
<one paragraph: the change and why, in user terms>
## Upgrade steps
1. <ordered, mechanical steps>
## Before / after
```
# before
...
# after
...
```
## If you can't upgrade yet
<deprecation window, shim, or flag to opt out — if one exists>
## Write the steps
- Make each step mechanical and verifiable ("rename `--foo` to `--bar`", not
"update your flags"). A user should be able to follow it without rereading the
whole guide.
- Show a minimal, real before/after for each distinct change. Keep examples
copy-pasteable.
- State explicitly when there is no automated path and a manual edit is
required.
## Verify
Route the finished guide through the `reviewer` (`purpose: review`). Migration
guides are acted on directly, so a wrong flag name or step is high-cost — the
cross-vendor fact-check is worth it here.Spin up a live local Omnigent server and exercise the Antigravity (Gemini) SDK harness end-to-end — build antigravity agents, run real turns, smoke-test, and bug-bash. Load when developing, testing, or debugging the antigravity harness (omnigent/inner/antigravity_executor.py, antigravity_harness.py, omnigent/onboarding/antigravity_auth.py) or its auth / model / tool-bridge behavior.
Spin up a live local Omnigent server and exercise the Cursor SDK harness end-to-end — build cursor agents, run real turns, smoke-test, and bug-bash. Load when developing, testing, or debugging the cursor harness (omnigent/inner/cursor_executor.py, cursor_harness.py, cursor_auth.py) or its auth / model / tool-bridge behavior.
Run the Omnigent server as a Docker compose stack (server + Postgres) on any Docker host — your laptop, a VPS, EC2 by hand, or as the base layer of any container-platform deploy. Invoke when the user wants to build the image, bring up the compose stack, debug the stack on a host they already have, or extend the stack for a new platform.
Have the Claude and GPT partners critique each other's answers across a configurable number of rounds (default 1) before converging on a synthesis. Use when the user wants the two perspectives stress-tested against each other, not just shown side by side.
Verify an implementer's diff with an INDEPENDENT, different-vendor sub-agent (diff plus contract only); turn blocking issues into fix-tasks and loop until clean.
Run independent subtasks in parallel — one git worktree and one implementation sub-agent per task, each opening its own PR — then cross-review every PR. polly never merges; the human does.
Delegate read-only investigation, debugging, audit, search, or code-understanding tasks to sub-agents; synthesize only from their structured reports.
Patterns and templates for generating valid Omnigent agent directories. Load when ready to create files.