ohmg — Gemini / Antigravity entry for oh-my-agent
When to use this skill
- You want to adopt
oh-my-agentfrom a Gemini CLI workflow - You want Antigravity to read the same project-local multi-agent setup
- You need a portable
.agents/source of truth that can later project into Gemini, Claude, and Codex surfaces - You need to explain when Gemini can use native generated agents versus when
oma agent:spawnfallback is required - You want the Gemini / Antigravity path without copying the full Claude-first (
omc) or Codex-first (omx) runtime catalogs
Instructions
Step 1: Identify the runtime and desired ownership model
Determine which of these the user actually wants:
- Gemini CLI first — they want Gemini-native agent files and Gemini-centric usage
- Antigravity first — they want Antigravity to consume a portable agent harness
- Portable harness first — they want one project-local source of truth that can later project into Gemini, Claude, or Codex
- Vendor-first runtime instead — they actually want Claude-first orchestration (
omc) or Codex-first orchestration (omx)
If the request is really about Claude Code-native orchestration, route to omc. If the request is really about Codex CLI-native orchestration, route to omx. Use ohmg when the center of gravity is Gemini CLI / Antigravity + portable harness adoption.
Step 2: Teach the current upstream mental model
Frame ohmg around the modern upstream surface:
- product/runtime name:
oh-my-agent - common CLI:
oma/oh-my-agent - source of truth:
.agents/in the project - native generated vendor views:
- .gemini/agents/*.md - .claude/agents/*.md - .codex/agents/*.toml
- dispatch rule:
- same-vendor runtime → prefer native generated vendor agent files - cross-vendor task → fall back to oma agent:spawn / oma agent:parallel
Do not lead with old oh-my-ag naming, /coordinate, or .agent/skills/ paths.
Step 3: Provide the right install/bootstrap path
Gemini CLI / general portable setup
# one-liner installer (macOS/Linux)
curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash
# or launch directly
bunx oh-my-agent@latest
# or install globally
bun install --global oh-my-agentAfter install, use the interactive oma flow to choose a preset and generate the project-local harness.
Useful operator commands:
oma doctor
oma link
oma dashboard
oma dashboard:webWhen install constraints exist
If interactive setup is not appropriate, explain the manual path:
- bring
.agents/into the project - run
oma linkto regenerate runtime-specific views - verify the generated Gemini / Claude / Codex files exist where expected
Step 4: Explain Gemini-native vs Antigravity behavior correctly
Gemini CLI path
Gemini can use generated native agent files from .gemini/agents/*.md when the runtime vendor matches the target vendor.
Use this framing:
- keep
.agents/canonical - generate/update
.gemini/agents/*.md - let Gemini use native generated agent definitions when possible
Antigravity path
Antigravity can consume .agents/agents/ directly, but does not support custom subagent spawning the same way Gemini / Claude / Codex runtimes can.
Use this framing:
- Antigravity is a portable-consumer surface for the harness
- do not oversell it as identical to Gemini-native multi-agent spawning
- when the task needs explicit cross-vendor or custom spawning behavior, explain the fallback CLI/runtime path instead of pretending Antigravity owns it natively
Step 5: Show the real workflow surfaces
Use upstream workflow language that matches current oh-my-agent docs:
/plan— PM task breakdown and API-contract-oriented planning/work— step-by-step gated multi-agent execution/orchestrate— CLI-based parallel agent execution/ultrawork— higher-intensity quality workflow/review— security / performance / accessibility review/debug— structured debugging/scm— SCM and Git workflow support
Useful CLI examples:
oma agent:spawn backend "Build auth API" session-01
oma agent:parallel -i backend:"Auth API" frontend:"Login form"
oma dashboard
oma dashboard:webUse these as examples of the portable harness, not as a promise that every runtime exposes the same native UI.
Step 6: Handle cross-vendor questions with explicit boundaries
Use this routing logic:
- Use
ohmgwhen the request is about:
- Gemini CLI setup for oh-my-agent - Antigravity compatibility - .agents/ source-of-truth structure - native Gemini generated agents - portable harness adoption before choosing per-vendor runtime layers
- Use
omcwhen the request is about:
- Claude Code plugin / in-session orchestration - /team, /autopilot, /ralph, /ccg, or Claude-first runtime operations
- Use
omxwhen the request is about:
- Codex CLI workflow skills like $deep-interview, $ralplan, $team, $ralph - .omx/ runtime state and Codex-first orchestration behavior
If a user wants one portable harness that can later serve Gemini + Claude + Codex, keep ohmg as the anchor and mention omc / omx as downstream vendor-first layers, not replacements for the .agents/ source of truth.
Step 7: Troubleshoot the most common drift points
Check these first:
- Wrong product naming — use
oh-my-agent/oma, not oldoh-my-ag - Wrong source-of-truth path — prefer
.agents/, not legacy.agent/ - Generated files stale or missing — rerun
oma link - Environment mismatch — Gemini-native behavior differs from Antigravity capability
- Monitoring confusion — dashboard observes agent/memory activity; it is not the whole orchestration model
- Mixed-vendor expectations — if native dispatch cannot own the task, explain
oma agent:spawn/oma agent:parallel
Examples
Example 1: Gemini CLI adoption
User: “Set up oh-my-agent for Gemini CLI.”
Response: Use ohmg. Install oh-my-agent, keep .agents/ as the source of truth, then regenerate Gemini-native agent files so Gemini can use .gemini/agents/*.md when the runtime vendor matches. A good start is curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash or bunx oh-my-agent@latest, then oma doctor and oma link.
Example 2: Antigravity compatibility
User: “I want Antigravity to use the same multi-agent setup as Gemini.”
Response: Use ohmg, but explain the capability boundary clearly: Antigravity can consume .agents/agents/ from the same portable harness, yet it does not support custom subagent spawning the same way Gemini-native or CLI fallback paths do. Keep .agents/ canonical and use Antigravity as a compatible consumer surface.
Example 3: Portable harness with later Claude/Codex routing
User: “I need Gemini-native agents now, but later I may route work to Claude or Codex.”
Response: ohmg is the right anchor. Start with oh-my-agent and .agents/ as the project-local source of truth. Let Gemini use generated native agent files now, then project the same harness into .claude/agents/ or .codex/agents/ later. If the user later wants Claude-first runtime orchestration, route those runtime details to omc; if they want Codex-first workflow skills, route to omx.
Example 4: Choosing between ohmg, omc, and omx
User: “Should I use ohmg, omc, or omx?”
Response: Use ohmg if your main goal is a Gemini / Antigravity-friendly portable harness centered on .agents/. Use omc for Claude-first orchestration and omx for Codex-first orchestration. ohmg is the portable harness adoption lane; omc and omx are vendor-first runtime overlays.
Best practices
- Use current upstream naming —
oh-my-agent/oma, notoh-my-ag - Keep
.agents/canonical — generated Gemini/Claude/Codex surfaces should derive from it - Prefer same-vendor native dispatch first — only escalate to CLI spawning when vendor/runtime mismatch requires it
- State Antigravity limits plainly — it is compatible, but not identical to Gemini-native custom subagent behavior
- Route vendor-first runtime questions cleanly — keep Claude-first runtime depth in
omcand Codex-first runtime depth inomx - Use
oma linkafter structure changes — stale generated files are a common source of confusion - Treat dashboards as observability helpers — they support the workflow; they are not the workflow itself