Create upgrade guides for changes that make existing code or settings stop working. The skill checks differences and history, then provides specific steps, copyable before-and-after examples, and any available options for postponing the upgrade.
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.
Review the instructions the agent will receive before you install.
Produce a guide that lets a user on the old version land on the new one with the least friction.
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.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.
# 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>
--foo to --bar", not
"update your flags"). A user should be able to follow it without rereading the
whole guide.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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Test Omnigent’s native Antigravity integration with a live local server and the real agy CLI. Verify messages traveling between the web interface and terminal, mirrored replies, permission requests, interruption, session resumption, and process cleanup.
Test Omnigent’s Antigravity SDK integration against a live local server. Build test agents and run real conversations to check Gemini authentication, model selection, tool connections, and failures across the full execution path.
Create reference documentation directly from source code for public functions, classes, command-line commands, and endpoints. Organize parameters, defaults, return values, errors, and runnable examples, then check that the documentation matches the implementation.
Create an Omnigent agent directory using validated templates for configuration and instructions. Choose how the agent runs, then add web search, shell access, external tool connections, or subagents only when the task requires them.
Turn a selected range of commits or merged pull requests into release notes grouped by change type. Describe user-visible effects, link to supporting changes, and highlight breaking changes so readers can assess an upgrade.
Test Omnigent’s setup, help, and terminal interactions by driving the real CLI in an isolated environment. Capture rendered screens and compare checks before and after a change to establish whether a reported interface problem was fixed.