Ohmg

Name: Ohmg
Author: akillness

akillness/oh-my-skills

219 installs
40 repo stars
Updated August 4, 2026
akillness/oh-my-skills

Coordinate oh-my-skills game dev tasks—scope, milestones, and cross-skill handoffs—while building a commercial Godot or Steam-bound title.

About

Meta game-development skill from oh-my-skills that helps agents plan and coordinate building a shippable game: break epics into tasks, align art, lighting, and store prep work, track dependencies, and keep implementation focused on playable milestones.

Game milestone and scope framing
Cross-skill task sequencing
Definition-of-done for game features
Risk and dependency callouts
Handoffs to specialized oh-my-skills

Ohmg by the numbers

219 all-time installs (skills.sh)
Ranked #89 of 247 Game Development skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/akillness/oh-my-skills --skill ohmg

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/akillness/oh-my-skills/ohmg.svg)](https://skillselion.com/skills/akillness/oh-my-skills/ohmg)

Installs	219
repo stars	★ 40
Last updated	August 4, 2026
Repository	akillness/oh-my-skills ↗

What it does

Coordinate oh-my-skills game dev tasks—scope, milestones, and cross-skill handoffs—while building a commercial Godot or Steam-bound title.

Files

SKILL.mdMarkdownGitHub ↗

ohmg — Cross-vendor portable multi-agent harness (oh-my-agent v10.4.1)

When to use this skill

You want to adopt `oh-my-agent` as a portable multi-agent harness across any AI IDE
You want a single `.agents/` source of truth that projects into Claude Code, Codex, Gemini, Antigravity, Cursor, Grok Build, Kimi Code, OpenCode, Pi, Qwen Code, Reasonix, Amp, GitHub Copilot, or Kiro CLI
You need OMA equivalents for Claude /team, /autopilot, /ultrawork, or /ultraqa on any runtime
You need specialized domain agents (frontend, backend, architecture, QA, PM, DB, mobile, infra, debug, design, etc.) that stay consistent across runtimes
You need to explain when native generated agent files are used versus when `oma agent:spawn` fallback is required
You want the vendor-agnostic harness path without locking into the full Claude-first (omc) or Codex-first (omx) runtime stacks

Instructions

Step 1: Identify the runtime and desired ownership model

Determine which of these the user actually wants:

1. Portable harness first — they want one .agents/ source of truth that projects to any supported runtime 2. Specific runtime first — they have a primary IDE but want multi-agent support via OMA 3. Claude Code native instead — route to omc 4. Codex CLI native instead — route to 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 user wants the cross-vendor portable harness or their runtime is not Claude Code or Codex.

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-agent

After 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:web

When install constraints exist

If interactive setup is not appropriate, explain the manual path:

1. bring .agents/ into the project 2. run oma link to regenerate runtime-specific views 3. 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:web

Use these as examples of the portable harness, not as a promise that every runtime exposes the same native UI.

Step 5.5: Map Claude team / autopilot / ultrawork / ultraqa to OMA

Read references/parallel-quality-workflows.md when the user asks to bring Claude OMC workflows to Gemini or Antigravity.

Claude / OMC intent	OMA / Gemini shape	Antigravity boundary
`/team N:role "task"`	`/orchestrate "task"` or `oma agent:parallel -i role:"task"`	Antigravity can consume `.agents/agents/`, but explicit spawning may need OMA CLI fallback
`/autopilot "task"` or `autopilot: task`	`/plan "task"` followed by `/work`; use `/orchestrate` only when the work must split into explicit lanes	Antigravity can follow the generated harness, but do not promise a native Claude-style `/autopilot` command unless the local projection exposes it
`/ultrawork "task"`	`/ultrawork "task"` or `oma agent:parallel` independent lanes	Keep `.agents/` canonical and regenerate views with `oma link`
`/ultraqa "target"`	`/review "target"` or `/ultrawork "QA target"` with QA/security/performance lanes	Do not promise a native `/ultraqa` command unless the local projection exposes it

Step 6: Handle cross-vendor questions with explicit boundaries

Use this routing logic:

Use `ohmg` when 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 `omc` when the request is about:
Claude Code plugin / in-session orchestration
/team, /autopilot, /ralph, /ccg, or Claude-first runtime operations

Use `omx` when the request is about:
Codex CLI workflow skills like $deep-interview, $autopilot, $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:

1. Wrong product naming — use oh-my-agent / oma, not old oh-my-ag 2. Wrong source-of-truth path — prefer .agents/, not legacy .agent/ 3. Generated files stale or missing — rerun oma link 4. Environment mismatch — Gemini-native behavior differs from Antigravity capability 5. Monitoring confusion — dashboard observes agent/memory activity; it is not the whole orchestration model 6. Mixed-vendor expectations — if native dispatch cannot own the task, explain oma agent:spawn / oma agent:parallel 7. Claude workflow parity confusion — map team, autopilot, ultrawork, and ultraqa as workflow intents, not identical command implementations

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

1. Use current upstream naming — oh-my-agent / oma, not oh-my-ag 2. Keep `.agents/` canonical — generated Gemini/Claude/Codex surfaces should derive from it 3. Prefer same-vendor native dispatch first — only escalate to CLI spawning when vendor/runtime mismatch requires it 4. State Antigravity limits plainly — it is compatible, but not identical to Gemini-native custom subagent behavior 5. Route vendor-first runtime questions cleanly — keep Claude-first runtime depth in omc and Codex-first runtime depth in omx 6. Use `oma link` after structure changes — stale generated files are a common source of confusion 7. Treat dashboards as observability helpers — they support the workflow; they are not the workflow itself 8. Map QA carefully — OMA /review or /ultrawork can satisfy the ultraqa intent, but only call it /ultraqa when that workflow exists locally

References

Installation, layout, and generated surfaces
Runtime boundaries: Gemini vs Antigravity vs OMC/OMX
Workflow and command packets
Parallel and quality workflows
Upstream README
Supported agents matrix

{
  "skill_name": "ohmg",
  "evals": [
    {
      "id": 1,
      "prompt": "Set up oh-my-agent for Gemini CLI.",
      "expected_output": "The skill gives a current oh-my-agent / oma install path, keeps .agents as the source of truth, and mentions oma doctor or oma link.",
      "assertions": [
        "The response includes oh-my-agent or oma naming rather than only oh-my-ag",
        "The response includes an install path such as curl install.sh, bunx oh-my-agent@latest, or bun install --global oh-my-agent",
        "The response mentions .agents as the source of truth",
        "The response includes oma doctor or oma link"
      ]
    },
    {
      "id": 2,
      "prompt": "I want Antigravity to use the same multi-agent setup as Gemini.",
      "expected_output": "The skill explains that Antigravity can consume the portable harness but does not support custom subagent spawning the same way Gemini-native runtimes do.",
      "assertions": [
        "The response states that Antigravity can use the same .agents-based harness",
        "The response explicitly notes the custom subagent spawning limitation",
        "The response does not claim Antigravity is identical to Gemini-native execution"
      ]
    },
    {
      "id": 3,
      "prompt": "I need Gemini-native agents now, but later I may route work to Claude or Codex.",
      "expected_output": "The skill keeps ohmg as the portable harness anchor, explains generated vendor views, and routes Claude/Codex runtime depth to omc/omx as needed.",
      "assertions": [
        "The response mentions generated Gemini, Claude, or Codex agent surfaces from the same canonical source",
        "The response keeps .agents or the portable harness as the anchor",
        "The response mentions routing Claude-first runtime questions to omc and Codex-first runtime questions to omx"
      ]
    },
    {
      "id": 4,
      "prompt": "Should I use ohmg, omc, or omx?",
      "expected_output": "The skill clearly distinguishes portable Gemini/Antigravity adoption from Claude-first and Codex-first runtime overlays.",
      "assertions": [
        "The response describes ohmg as the Gemini or Antigravity facing portable harness lane",
        "The response describes omc as Claude-first runtime orchestration",
        "The response describes omx as Codex-first runtime orchestration"
      ]
    },
    {
      "id": 5,
      "prompt": "My ohmg docs still say oh-my-ag and .agent paths. What should I trust?",
      "expected_output": "The skill explains that current upstream uses oh-my-agent / oma and .agents as the canonical layout, with regenerated vendor-specific views.",
      "assertions": [
        "The response says oh-my-agent or oma is the current upstream identity",
        "The response says .agents is canonical instead of .agent",
        "The response mentions regenerating vendor views via oma link or equivalent"
      ]
    },
    {
      "id": 6,
      "prompt": "I use Claude /team, /ultrawork, and /ultraqa. How do I make those usable in Antigravity with OMA?",
      "expected_output": "The skill maps team to /orchestrate or oma agent:parallel, ultrawork to /ultrawork or agent:parallel lanes, and ultraqa to /review or QA-focused /ultrawork while stating Antigravity custom spawning limits.",
      "assertions": [
        "The response maps team to /orchestrate or oma agent:parallel",
        "The response maps ultrawork to /ultrawork or parallel lanes",
        "The response maps ultraqa to /review or QA-focused /ultrawork",
        "The response states Antigravity custom spawning is limited or may need OMA CLI fallback"
      ]
    },
    {
      "id": 7,
      "prompt": "I use Claude /autopilot. How should Antigravity use the same intent with OMA?",
      "expected_output": "The skill maps autopilot intent to OMA /plan followed by /work, keeps .agents canonical, and explains that Antigravity may need OMA CLI fallback for explicit parallel spawning rather than a native Claude-style /autopilot command.",
      "assertions": [
        "The response maps autopilot intent to /plan followed by /work",
        "The response mentions .agents as canonical or oma link",
        "The response mentions /orchestrate or oma agent:parallel only as a conditional fallback for parallel lanes",
        "The response does not promise a native Antigravity /autopilot command unless the local projection exposes it"
      ]
    }
  ]
}

OHMG Installation and Layout

Current upstream identity

Product / repo: `oh-my-agent`
Common CLI name: `oma`
Canonical upstream repo: https://github.com/first-fluke/oh-my-agent

Install paths

Interactive install

curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash
# or
bunx oh-my-agent@latest
# or
bun install --global oh-my-agent

Then run the interactive flow and choose the preset that matches the project.

Verification

oma doctor
oma link

Canonical directory model

oh-my-agent is designed around `.agents/` as the source of truth.

Typical layout:

.agents/
├── agents/
├── skills/
├── workflows/
└── oma-config.yaml

Generated vendor views come from that canonical structure:

.gemini/agents/*.md
.claude/agents/*.md
.codex/agents/*.toml

Use this rule:

edit the canonical .agents/ content
regenerate vendor-facing files with oma link
avoid maintaining separate per-runtime copies by hand

Useful commands

oma doctor
oma link
oma dashboard
oma dashboard:web
oma agent:spawn backend "Build auth API" session-01
oma agent:parallel -i backend:"Auth API" frontend:"Login form"

Common drift fixes

1. Wrong product name in local docs (oh-my-ag instead of oh-my-agent) 2. Legacy .agent/ paths instead of .agents/ 3. Generated Gemini/Claude/Codex files not refreshed after edits 4. Assuming the dashboard replaces the orchestration model instead of monitoring it

Autonomous, Parallel, and Quality Workflows

This reference maps Claude Code OMC workflows (team, autopilot, ultrawork, ultraqa) to the portable OMA / oh-my-agent harness for Gemini and Antigravity.

Decision Table

Need	OMA workflow	CLI fallback	Antigravity note
Coordinated team execution	`/orchestrate "task"`	`oma agent:parallel -i backend:"API" frontend:"UI"`	Antigravity can consume `.agents/agents/`; explicit custom spawning may need OMA CLI fallback.
End-to-end autonomous build	`/plan "task"` then `/work`	Use `oma agent:parallel` only after the plan identifies independent lanes	Treat this as autopilot intent parity, not a guaranteed native `/autopilot` command.
Burst parallel implementation	`/ultrawork "task"`	`oma agent:parallel -i lane-a:"..." lane-b:"..."`	Use independent lanes; do not assume Claude-style shared state.
Parallel QA/review	`/review "target"` or `/ultrawork "QA target"`	`oma agent:parallel -i qa:"Tests" security:"Audit" performance:"Perf"`	Do not promise a native `/ultraqa` name unless the generated local workflow exposes it.

Source of Truth

Keep .agents/ canonical:

oma link
oma doctor

Generated vendor views such as .gemini/agents/*.md, .claude/agents/*.md, and .codex/agents/*.toml should be regenerated, not edited by hand.

Boundary

Use OMA for portable Gemini/Antigravity harness adoption. Route Codex-native workflow details to omx and Claude-native runtime details to omc.

Workflow and Command Packets

Current workflow surfaces

Use upstream oh-my-agent workflow language instead of legacy oh-my-ag snippets.

Workflow packets

/plan — planning and task breakdown
/work — step-by-step gated multi-agent execution
/orchestrate — CLI-based parallel execution
/ultrawork — higher-intensity quality workflow
/review — security / performance / accessibility review
/debug — structured debugging
/scm — SCM and Git workflow support

CLI packets

oma doctor
oma link
oma dashboard
oma dashboard:web
oma agent:spawn backend "Build auth API" session-01
oma agent:parallel -i backend:"Auth API" frontend:"Login form"

How to explain them

present workflow packets as the portable harness layer
present CLI commands as operator tools for verification, regeneration, spawning, and monitoring
do not promise every runtime exposes the same native UI or spawning mechanics
for Claude parity requests, map /team to /orchestrate or oma agent:parallel, /ultrawork to OMA /ultrawork, and /ultraqa to /review or a QA-focused /ultrawork

Response pattern

1. identify whether the user is Gemini-first, Antigravity-first, or portable-harness-first 2. give the exact install / link / verification commands 3. explain the native-vs-fallback dispatch rule 4. route Claude-first runtime depth to omc 5. route Codex-first runtime depth to omx

N:ohmg
D:Gemini / Antigravity entry for the portable oh-my-agent / OMA harness. Keep .agents as the source of truth, generate vendor views with oma link, and map Claude team/autopilot/ultrawork/ultraqa intents to OMA /orchestrate, /plan→/work, /ultrawork, /review, or oma agent:parallel without overclaiming Antigravity-native spawning.
G:ohmg oh-my-agent oma gemini antigravity .agents portable-harness orchestration team autopilot ultrawork ultraqa plan work review
U[5]:
1:Adopt oh-my-agent from Gemini CLI or Antigravity with .agents as canonical source
2:Regenerate Gemini Claude and Codex vendor views via oma link
3:Explain Gemini-native generated agents vs OMA CLI fallback
4:Map Claude /team /autopilot /ultrawork /ultraqa intents to OMA workflow packets
5:Route Claude-first depth to omc and Codex-first depth to omx
S[6]{n,action,details}:
1:install,Install OMA,curl install.sh or bunx oh-my-agent@latest or bun install --global oh-my-agent
2:link,Regenerate views,oma link then oma doctor
3:team,Coordinate work,/orchestrate "task" or oma agent:parallel -i role:"task"
4:autopilot,Autonomous build intent,/plan "task" then /work; only use /orchestrate or oma agent:parallel after the plan identifies parallel lanes
5:ultrawork,Parallel burst,/ultrawork "task" or independent oma agent:parallel lanes
6:ultraqa,QA parity,/review "target" or /ultrawork "QA target"; only call it /ultraqa when local workflow exposes that name
R[5]:
1:Use oh-my-agent / oma naming not old oh-my-ag
2:Keep .agents canonical and do not hand-edit generated vendor views
3:Antigravity can consume the harness but custom spawning may need OMA CLI fallback
4:Generated surfaces include .gemini/agents .claude/agents and .codex/agents
5:Dashboards are observability helpers not the whole orchestration model
E[3]{desc,in,out}:
1:{Antigravity team parity,I want Claude /team style work in Antigravity,Use .agents harness plus /orchestrate or oma agent:parallel and state the spawning boundary}
2:{QA parity,Need ultraqa on OMA,Use /review or QA-focused /ultrawork with qa/security/performance lanes}
3:{Autopilot parity,I use Claude /autopilot and want it in Antigravity,Use /plan then /work and state that native /autopilot is not guaranteed}

Related skills

Godot Gdscript PatternsGenerate production-grade GDScript following Godot best practices for scene management, save systems, and performance.13.2k38.5k

Game EngineInstantly bootstrap a tilt-controlled 2D maze game using Phaser and device orientation.11.9k37.5k

Game DeveloperGenerate clean ECS architecture, component patterns, and performant game systems that Claude or Cursor can expand into full Unity or custom engines.4.5k10.9k

Msw GeneralAdd a versatile set of general-purpose AI coding capabilities directly into Cursor, Claude Code, and similar agents.4.4k33

Msw DefaultplayerInstantly load a reliable default AI coding agent profile with proven prompts and behaviors.4.4k33

Msw ScriptingCreate reusable, programmable agent behaviors and custom scripting flows that integrate directly with Claude, Cursor and other coding agents.4.4k33

Game Developmentfrontendintegrationstesting