{
"markdown": "# oh-my-antigravity (OmA)\n[](https://github.com/Joonghyun-Lee-Frieren/oh-my-antigravity/releases)\n[](https://github.com/Joonghyun-Lee-Frieren/oh-my-antigravity/actions/workflows/version-check.yml)\n[](LICENSE)\n[](https://github.com/Joonghyun-Lee-Frieren/oh-my-antigravity/stargazers)\n[](https://geminicli.com/extensions/?name=Joonghyun-Lee-Frierenoh-my-antigravity)\n[](https://github.com/sponsors/Joonghyun-Lee-Frieren)\n\n[Landing Page](https://joonghyun-lee-frieren.github.io/oh-my-antigravity/) | [History](docs/history.md)\n\n[한국어](docs/README_ko.md) | [日本語](docs/README_ja.md) | [Français](docs/README_fr.md) | [中文](docs/README_zh.md) | [Español](docs/README_es.md)\n\n> [!IMPORTANT]\n> **Antigravity CLI:** Gemini CLI will be replaced by Antigravity CLI on June 18th.\n>\n> If you previously installed `oh-my-gemini-cli` in Gemini CLI, Antigravity CLI will ask whether to import plugins during installation. Check that option to bring your plugin over.\n>\n> You can also install OmA directly with:\n>\n> ```bash\n> agy plugin install https://github.com/Joonghyun-Lee-Frieren/oh-my-antigravity\n> ```\n\nContext-engineering-powered multi-agent workflow pack for Antigravity CLI.\n\n> \"Claude Code's core competitiveness isn't the Opus or Sonnet engine. It's Claude Code itself. Surprisingly, Gemini works well too when attached to Claude Code.\"\n>\n> - Jeongkyu Shin (CEO of Lablup Inc.), from a YouTube channel interview\n\nThis project started from that observation:\n\"What if we bring that harness model to Gemini CLI?\"\n\nOmA extends Gemini CLI from a single-session assistant into a structured, role-driven engineering workflow.\n\n\n
\n \n
\n\n## Quick Start\n\n### Installation\n\nInstall from GitHub using the official Gemini Extensions command:\n\n```bash\ngemini extensions install https://github.com/Joonghyun-Lee-Frieren/oh-my-antigravity\n```\n\nVerify in interactive mode:\n\n```text\n/extensions list\n```\n\nVerify in terminal mode:\n\n```bash\ngemini extensions list\n```\n\nRun a smoke test:\n\n```text\n/oma:status\n```\n\nRun a goal-style autonomous delivery loop:\n\n```text\n/oma:goal \"Implement the requested change, update tests, and verify acceptance criteria\"\n```\n\nNote: extension install/update commands run in terminal mode (`gemini extensions ...`), not in interactive slash-command mode.\n\n## What's New in v0.9.2\n\n- **Orbit Router Diagnostics**: The quiet `BeforeModel` router can now write an opt-in last-decision trace to `.omg/state/model-router-last.json`.\n- **Trace Without Noise**: Set `OMG_MODEL_ROUTING_TRACE=1` to capture selected lane, model, strategy, and match reason without restoring the old per-request banner.\n- **Doctor/Status Visibility**: `/oma:doctor`, `/oma:status`, `/oma:model`, and hook validation guidance now account for router trace freshness and missing custom lane mappings.\n- **Version Bump**: Bumped project and extension version to `v0.9.2`.\n\n## Extension Boundary and Upgrade Safety\n\n- Install and update OmA through `gemini extensions ...`; do not rely on copied command/skill folders as the primary runtime path.\n- Keep one authoritative OmA hook registration path per event. Mixing extension-managed hooks with manual duplicates is the fastest way to get repeated AfterAgent output or stale behavior.\n- When OmA feels stale after an update, check `gemini extensions list` first, then refresh or reinstall the extension before editing shipped files.\n- For long or multi-lane work, treat `/oma:workspace audit` as the default preflight before review, automation, or `team-exec`.\n\n## Interview Session Storage\n\n- `/oma:interview` session state is now intended to live under `.omg/state/interviews/[slug]/` instead of one shared interview file.\n- `.omg/state/interviews/active.json` tracks the current interview so resume/status commands stay deterministic without mixing separate requirement threads.\n- This keeps multiple requirement-discovery passes in the same project distinguishable and archive-friendly.\n\n## Shared Workflow State\n\n- `.omg/state/session-lock.json` is now the single-writer lock for shared workflow and operating-profile state inside one project.\n- Only the lock-owning orchestration session should write shared files like `workspace.json`, `taskboard.md`, `workflow.md`, `checkpoint.md`, `mode.json`, `hud.json`, `approval.json`, `reasoning.json`, `hooks.json`, and `notify.json`.\n- Parallel top-level sessions that do not own the lock should write session-local drafts under `.omg/state/sessions/[session-slug]/` and hand those notes back to the orchestrator for merge.\n- Delegated worker/sub-agent turns should stay read-mostly and must not mutate shared workflow state directly.\n\n## At A Glance\n\n| Item | Summary |\n| --- | --- |\n| Delivery model | Official Gemini CLI extension (`gemini-extension.json`) |\n| Core building blocks | `GEMINI.md`, `agents/`, `commands/`, `skills/`, `context/` |\n| Main use case | Complex implementation tasks that need plan -> execute -> review loops |\n| Control surface | Slash-command-first `/oma:*` control plane + 11 retained `$skills` (including `oma-plan` alias) + sub-agent delegation |\n| Default model strategy | Configurable via `/oma:model` (`balanced` lane split uses `gemini-3.1-pro-preview` / `gemini-3-flash-preview` / `gemini-3.1-flash-lite-preview` by default, with optional `auto` or `custom` overrides) |\n\n## Why OmA\n\n| Problem in raw single-session flow | OmA response |\n| --- | --- |\n| Context gets mixed across planning and execution | Role-separated agents with focused responsibilities |\n| Hard to keep progress visible in long tasks | Explicit workflow stages and command-driven status checks |\n| Parallel lanes or worktrees drift out of sync | `workspace` + `taskboard` keep lane ownership, task IDs, and verification state compact and explicit |\n| Permission-denied tool calls keep looping with no recovery path | Denied actions become explicit approval/fallback events with blocker tracking |\n| Deep interview sessions get interrupted by automated nudges | Learn-signal hook suppresses nudges while deep-interview lock is active and resumes only after lock release |\n| Repetitive prompt engineering for common jobs | Slash commands for operational control plus retained deep-work skills (`$plan`, `$oma-plan`, `$execute`, `$research`) |\n| Drift between \"what was decided\" and \"what was changed\" | Review and debugging roles inside the same orchestration loop |\n\n## Dynamic Team Assembly\n\nUse `team-assemble` when a fixed engineering roster is not enough.\n\n- Split selection into:\n - domain specialists (problem expertise)\n - format specialists (report/content/output quality)\n- Spawn parallel exploration lanes (`oma-researcher` xN) for broad discovery tasks.\n- Route decisions through a judgment lane (`oma-consultant` or `oma-architect`).\n- Assign reasoning effort per lane from global profile + teammate overrides.\n- Keep verify/fix loops explicit (`oma-reviewer` -> `oma-verifier` -> `oma-debugger`).\n- Run anti-slop check before final delivery.\n- Require explicit approval before autonomous execution starts.\n\nExample flow:\n\n```text\n/oma:team-assemble \"Compare 3 competitors and produce an exec report\"\n-> proposes: researcher x3 + consultant + editor + director\n-> asks: Proceed with this team? (yes/no)\n-> after approval: team-plan -> team-prd -> taskboard -> team-exec -> team-verify -> team-fix\n```\n\nActivation note:\n- No separate research-preview setting is required in OmA.\n- If the extension is loaded, `/oma:team-assemble` is immediately available.\n\n## Workspace and Taskboard Control\n\nUse `workspace` and `taskboard` when work spans multiple roots, multiple implementation lanes, or long verify/fix loops.\n\n- `/oma:workspace` keeps the primary root plus optional worktree/path lanes in `.omg/state/workspace.json`.\n- Each lane can also carry a compact baseline branch/HEAD anchor so handoffs and resume flows can detect unexpected branch drift before implementation or review.\n- `/oma:workspace audit` checks lane cleanliness, trust status, and handoff readiness before parallel execution, review, or automation.\n- `/oma:taskboard` keeps stable task IDs, owners, dependencies, statuses (`todo`, `ready`, `in-progress`, `blocked`, `done`, `verified`), baseline anchors, lane-health notes, and evidence pointers in `.omg/state/taskboard.md`.\n- `team-plan` seeds stable task IDs plus lane assumptions and baseline anchors, `team-exec` pulls the smallest ready slice with explicit lane/subagent context and baseline checks, and `team-verify` marks tasks verified only with evidence plus safe lane state.\n- `checkpoint` and `status` can reference these files instead of replaying the whole chat, which improves cache stability and reduces token waste.\n- `/oma:recall \"\"` performs state-first recall and bounded fallback search, so you can recover prior rationale without replaying full transcripts.\n\nExample flow:\n\n```text\n/oma:workspace set .\n/oma:workspace audit\n/oma:workspace add ../feature-auth oma-executor\n/oma:taskboard sync\n/oma:taskboard next\n/oma:recall \"why was auth lane blocked\" scope=state\n```\n\n## Workspace Hygiene and Hook Symmetry\n\nUse these controls when long sessions start drifting because lane ownership, delegated execution, or hook continuation behavior is no longer obvious.\n\n- `/oma:workspace audit` surfaces dirty shared worktrees, untrusted review paths, and handoff-ready vs handoff-blocked lanes.\n- `/oma:hooks` and `/oma:hooks-validate` now model paired agent lifecycle outcomes (`completed`, `blocked`, `stopped`) so blocked continuations re-enter the safety lane once before downstream hooks resume.\n- `team-exec`, `team`, `team-verify`, `stop`, and `cancel` keep delegated lane/subagent context compact and explicit, expanding details only when execution stops early or hits a blocker.\n\n## Notification Routing\n\nUse `notify` when a long-running OmA session needs explicit signals for approvals, verification outcomes, blockers, or idle drift.\n\n- Supported profiles:\n - `quiet`: only urgent interruptions (`approval-needed`, `verify-failed`, `blocker-raised`, `session-stop`)\n - `balanced`: quiet + checkpoint and team-approval updates\n - `watchdog`: balanced + idle-watchdog alerts for unattended loops\n- Supported channels:\n - `desktop` (host notification adapter)\n - `terminal-bell`\n - `file`\n - `webhook` (external bridge)\n- Safety boundary:\n - OmA manages event routing, templates, and persisted policy\n - actual delivery must be implemented by Gemini host hooks, shell adapters, or project-specific webhook bridges\n - delegated worker sessions keep external dispatch disabled unless the user explicitly opts in\n\nExample flow:\n\n```text\n/oma:notify profile watchdog\n-> enables: approval-needed, verify-failed, blocker-raised, checkpoint-saved, idle-watchdog, session-stop\n-> suggests channels: terminal-bell + file by default\n-> persists policy: .omg/state/notify.json\n```\n\n## Model Router (BeforeModel Hook)\n\nOmA ships a quiet model-routing hook. The previous `AfterAgent` quota-watch usage monitor was removed in `v0.8.4` because Gemini CLI can report usage as unavailable, which created noisy low-value output.\n\n- Hook entrypoint: `hooks/hooks.json` (`BeforeModel` -> `oma-model-router`)\n- Script: `hooks/scripts/before-model-banner.js`\n- Behavior: silently maps outgoing model requests to the active OmA strategy (`balanced`, `auto`, or `custom`) without printing a model banner\n- Default balanced routing: planning/review -> `gemini-3.1-pro-preview`, execution -> `gemini-3-flash-preview`, quick edits -> `gemini-3.1-flash-lite-preview`\n- Optional disable: `OMG_DISABLED_HOOKS=model-routing` or `OMG_MODEL_ROUTING=off`\n- Optional trace: `OMG_MODEL_ROUTING_TRACE=1` writes the latest lane/model decision to `.omg/state/model-router-last.json`\n\nUsage/quota visibility:\n\n- OmA no longer estimates or prints token usage after each turn.\n- Use Gemini CLI native `/model` or `/stats model` for authoritative usage and quota status.\n- Legacy `.omg/state/quota-watch.json` files can be ignored; new OmA releases no longer update them.\n\n## Learn-Signal Safety Filter (AfterAgent Hook)\n\nOmA now also ships a safety-hardened learn-signal hook so `/oma:learn` nudges appear only when a session has actionable implementation intent.\n\n- Hook entrypoint: `hooks/hooks.json` (`AfterAgent` -> `oma-learn-signal-after-agent`)\n- Script: `hooks/scripts/learn.js`\n- State artifact: `.omg/state/learn-watch.json` (deduped event key, prompt-once session tracking, and sanitized state)\n- Deep-interview lock source (read-only): `.omg/state/deep-interview.json`\n- Runtime controls:\n - `OMG_STATE_ROOT=` to move `learn-watch.json` beside other OmA state\n - `OMG_HOOKS_QUIET=1` to keep the hook silent while preserving state updates\n - `OMG_HOOK_PROFILE=minimal|balanced|strict` (`minimal` suppresses learn nudges)\n - `OMG_DISABLED_HOOKS=learn` to disable only the learn-signal hook by env\n - when no reliable session `cwd` is available, learn-state persistence is skipped to avoid cross-project collisions\n\nSafety behavior:\n\n- if deep-interview lock state is active, learn nudges are suppressed so interview flow is not interrupted\n- informational-only query sessions are filtered before emit\n- repeated retries against the same transcript snapshot are deduplicated\n- legacy or malformed prior state is sanitized before reuse to reduce stale-state collisions\n\nDisable only this hook:\n\n```json\n{\n \"hooksConfig\": {\n \"disabled\": [\"oma-learn-signal-after-agent\"]\n }\n}\n```\n\nExample (disable the shipped AfterAgent learn hook by env):\n\n```bash\nexport OMG_DISABLED_HOOKS=learn\n```\n\n\n## Interface Map\n\n### Commands\n\n| Command | Purpose | Typical timing |\n| --- | --- | --- |\n| `/oma:status` | Summarize progress, risks, and next actions | Start/end of a work session |\n| `/oma:doctor` | Run extension/team/workspace/hook readiness diagnostics, including priority/fallback-route drift checks | Before long autonomous runs or when setup seems broken |\n| `/oma:hud` | Inspect or switch visual HUD profile (`normal`, `compact`, `hidden`) | Before long sessions or when terminal density changes |\n| `/oma:hud-on` | Quick toggle HUD to full visual mode | When returning to full status boards |\n| `/oma:hud-compact` | Quick toggle HUD to compact mode | During dense implementation loops |\n| `/oma:hud-off` | Quick toggle HUD to hidden mode (plain status sections) | When visual blocks are distracting |\n| `/oma:hooks` | Inspect/switch hook pipeline profile and trigger policy | Before autonomous loops or when hook behavior drifts |\n| `/oma:hooks-init` | Bootstrap hook config and plugin contract scaffolding | At project kickoff or first hook adoption |\n| `/oma:hooks-validate` | Validate hook ordering, lifecycle symmetry, safety, and budget constraints | Before enabling high-autonomy workflows |\n| `/oma:hooks-test` | Dry-run hook event sequence and efficiency estimates | After policy changes or repeated loop stalls |\n| `/oma:notify` | Configure notification routing for approvals, blockers, verify results, checkpoints, and idle watchdog alerts | Before unattended `autopilot`/`loop` runs or when alert noise needs tuning |\n| `/oma:intent` | Classify task intent and route to the correct stage/command | Before planning or coding when request intent is ambiguous |\n| `/oma:rules` | Activate task-conditional guardrail rule packs | Before implementation on migration/security/performance-sensitive work |\n| `/oma:memory` | Maintain MEMORY index, topic files, and path-aware rule packs | During long sessions or when decisions/rules drift |\n| `/oma:workspace` | Inspect, audit, or set primary root, worktree/path lanes, and collision boundaries | Before parallel implementation or multi-root work |\n| `/oma:taskboard` | Maintain a compact task ledger with stable IDs, `p0-p3` priority, deterministic `next`, baseline anchors, and verifier-backed completion state | After planning and throughout long exec/verify loops |\n| `/oma:recall` | Recover prior decisions/evidence with state-first search and bounded history fallback | When you need past rationale quickly without replaying full transcripts |\n| `/oma:reasoning` | Set global reasoning effort and teammate overrides (`low/medium/high/xhigh`) | Before expensive planning/review loops or when depth is role-dependent |\n| `/oma:deep-init` | Build deep project map and validation baseline for long sessions | At project kickoff or when onboarding into unfamiliar codebases |\n| `/oma:blueprint` | Define product/UI workflow decisions, interface states, content hierarchy, accessibility, and verification hooks | Before planning or coding user-facing flows |\n| `/oma:team-assemble` | Dynamically compose a role-fit team with approval gate, lane-specific reasoning map, and fallback routing hints | Before `/oma:team` on cross-domain or non-standard tasks |\n| `/oma:team` | Execute full stage pipeline (`team-assemble? -> plan -> prd -> taskboard -> exec -> verify -> fix`) | Complex feature or refactor delivery |\n| `/oma:team-plan` | Build dependency-aware execution plan | Before implementation |\n| `/oma:team-prd` | Lock measurable acceptance criteria and constraints | After planning, before coding |\n| `/oma:team-exec` | Implement one highest-priority ready slice with explicit lane/subagent handoff and single-shot fallback reroute | Main implementation loop |\n| `/oma:team-verify` | Validate acceptance criteria, regressions, and anti-slop quality gate, then emit priority-ordered fix backlog | After each execution slice |\n| `/oma:team-fix` | Patch only verified failures | When verification fails |\n| `/oma:loop` | Enforce repeated `exec -> verify -> fix` cycles until done/blocker | Mid/late delivery when unresolved findings remain |\n| `/oma:mode` | Inspect or switch operating profile (`balanced/speed/deep/autopilot/ralph/ultrawork`) | At session start or posture change |\n| `/oma:model` | Inspect or switch model-selection strategy (`balanced/auto/custom`) | When setting one default model policy (for example Gemini Auto across all tasks) |\n| `/oma:approval` | Inspect or switch approval posture (`suggest/auto/full-auto`) | Before autonomous delivery loops or policy changes |\n| `/oma:goal` | Run a goal-driven autonomous delivery loop with routine work pre-approved and runtime-boundary blockers explicit | When you want `/goal`-style hands-off delivery until verified, blocked, or max cycles |\n| `/oma:ultragoal` | Run a durable multi-goal workflow (Ultragoal) persisting checkpoints and progress in repository-native files | Decomposing large, complex requirements into sequential micro-goals that survive session restarts |\n| `/oma:autopilot` | Run iterative autonomous cycles with checkpoints | Complex autonomous delivery |\n| `/oma:ralph` | Enforce strict quality-gated orchestration | Release-critical tasks |\n| `/oma:ultrawork` | Throughput mode for batched independent tasks | Large backlogs |\n| `/oma:consensus` | Converge on one option from multiple designs | Decision-heavy moments |\n| `/oma:launch` | Initialize persistent lifecycle state for long tasks | Beginning of long sessions |\n| `/oma:checkpoint` | Save compact checkpoint and resume hint with taskboard/workspace references | Mid-session handoff |\n| `/oma:stop` | Gracefully stop autonomous mode and preserve progress | Pause/interrupt moments |\n| `/oma:cancel` | Harness-style cancel alias that stops safely and returns resume handoff | When interrupting autonomous/team flow |\n| `/oma:optimize` | Improve prompts/context for quality and token efficiency | After a noisy or expensive session |\n| `/oma:cache` | Inspect cache/context behavior and compact-state anchoring | Long-running context-heavy tasks |\n\n### Skills\n\nRetained skills are intentionally limited to a compact set so the extension loads less discovery metadata at session start (with one compatibility alias: `$oma-plan`).\n\n| Skill | Focus | Output style |\n| --- | --- | --- |\n| `$plan` | Convert goals into phased plan | Milestones, risks, and acceptance criteria |\n| `$oma-plan` | Slash-friendly planning alias that avoids native `/plan` collisions | Same planning output as `$plan` |\n| `$ralplan` | Strict, stage-gated planning with rollback points | Quality-first execution map |\n| `$execute` | Implement a scoped plan slice | Change summary with validation notes |\n| `$prd` | Convert requests into measurable acceptance criteria | PRD-style scope contract |\n| `$research` | Explore options/tradeoffs | Decision-oriented comparison |\n| `$deep-dive` | Run trace-to-interview discovery before planning | Clarity score, assumption ledger, and launch brief |\n| `$ultragoal` | Manage durable multi-goal workflows with repo-native checkpoints | Sequential goal map with verification criteria and ledger logs |\n| `$blueprint` | Lock product/UI workflow decisions before implementation | Workflow map, interface decisions, state coverage, and verification hooks |\n| `$context-optimize` | Improve context structure | Compression and signal-to-noise adjustments |\n| `$learn` | Extract reusable session patterns | Learned rule candidates and save recommendations |\n\n### Sub-agents\n\n| Agent | Primary responsibility | Preferred model profile |\n| --- | --- | --- |\n| `oma-architect` | System boundaries, interfaces, long-term maintainability | `gemini-3.1-pro-preview` |\n| `oma-planner` | Task decomposition and sequencing | `gemini-3.1-pro-preview` |\n| `oma-product` | Scope lock, non-goals, and measurable acceptance criteria | `gemini-3.1-pro-preview` |\n| `oma-executor` | Fast implementation cycles | `gemini-3-flash-preview` |\n| `oma-reviewer` | Correctness and regression risk checks | `gemini-3.1-pro-preview` |\n| `oma-verifier` | Acceptance-gate evidence and release-readiness checks | `gemini-3.1-pro-preview` |\n| `oma-debugger` | Root-cause analysis and patch strategy | `gemini-3.1-pro-preview` |\n| `oma-consensus` | Option scoring and decision convergence | `gemini-3.1-pro-preview` |\n| `oma-researcher` | External option analysis and synthesis | `gemini-3.1-pro-preview` |\n| `oma-director` | Team message routing, conflict resolution, and lifecycle orchestration | `gemini-3.1-pro-preview` |\n| `oma-consultant` | Strategic analysis criteria and recommendation framing | `gemini-3.1-pro-preview` |\n| `oma-editor` | Final deliverable structure, consistency, and audience fit | `gemini-3-flash-preview` |\n| `oma-quick` | Small, tactical fixes | `gemini-3.1-flash-lite-preview` |\n\n## Context Layer Model\n\n| Layer | Source | Goal |\n| --- | --- | --- |\n| 1 | System / runtime constraints | Keep behavior aligned with platform guarantees |\n| 2 | Project standards | Preserve team conventions and architecture intent |\n| 3 | Thin `GEMINI.md`, `MEMORY.md`, and shared context | Maintain stable long-session memory without carrying heavy procedure every turn |\n| 4 | Active task brief + workspace/taskboard state | Keep current objective, active lanes, and acceptance criteria visible |\n| 5 | Latest execution traces | Feed immediate iteration and review loops without replaying full raw history |\n\n## Project Structure\n\n```text\noh-my-antigravity/\n|- GEMINI.md\n|- gemini-extension.json\n|- .omg/\n| `- state/\n| |- session-lock.json\n| `- interviews/\n| | |- active.json\n| | `- [slug]/\n| | |- context.json\n| | `- prd.md\n| `- sessions/\n| `- [session-slug]/\n| |- workspace.json\n| |- taskboard.md\n| |- workflow.md\n| `- checkpoint.md\n|- agents/\n|- commands/\n| `- omg/\n|- skills/\n|- context/\n|- docs/\n`- LICENSE\n```\n\n## Troubleshooting\n\n| Symptom | Likely cause | Action |\n| --- | --- | --- |\n| `settings.filter is not a function` during install | Stale Gemini CLI runtime or stale cached extension metadata | Update Gemini CLI, uninstall extension, then reinstall from repository URL |\n| `/oma:*` command not found | Extension not loaded in current session | Run `gemini extensions list`, then restart Gemini CLI session |\n| Slash command or skill list looks stale after runtime/extension refresh | Interactive registry was not refreshed after update | Run `/skills reload` on newer Gemini CLI builds, or restart the session if the runtime is still on older stable |\n| `/plan` opens native plan mode when you wanted OmA planning skill | Name collision between built-in `/plan` and skill-slash invocation | Use `/oma-plan` (or `$oma-plan`) for the OmA planning skill, or use `/oma:team-assemble` or `/oma:team-plan` for staged workflow planning |\n| You want one global model or Gemini Auto but OmA still behaves like an older pinned model policy | Older installs or stale extension metadata may still carry older model guidance or cached command metadata | Update/reinstall OmA, then set `/oma:model balanced` for explicit preview routing or `/oma:model auto` for runtime auto selection |\n| Skill does not trigger | Only the retained deep-work skills are still shipped, or extension metadata is stale | Recheck the retained skill list in the README and reload the extension/session |\n| Windows skill linking or extension reload behaves differently across machines | Different Gemini CLI builds handle skill links differently | Prefer stable `v0.42.0+`; if you track preview/nightly, verify skill-link behavior separately before publishing docs or support guidance |\n| Team assembly keeps proposing but does not execute | Approval token missing in request | Reply with explicit approval (`yes`, `approve`, `go`, or `run`) |\n| Parallel execution keeps colliding or re-planning the same files | Workspace lanes are not explicit | Run `/oma:workspace status` or set lane/path ownership with `/oma:workspace` |\n| `taskboard next` keeps jumping between tasks unpredictably | Missing priority values or unstable queue ordering | Run `/oma:taskboard sync` (fills default `p2`), then `/oma:taskboard rebalance` |\n| Review or automation is about to run on a dirty/untrusted lane | Shared worktree hygiene is unclear | Run `/oma:workspace audit`, isolate the lane if needed, and only then continue verify/review steps |\n| Execution slice looks correct but the lane is on the wrong branch/HEAD | Baseline anchor drifted since planning or handoff | Re-run `/oma:workspace audit`, confirm the intended baseline, then realign the lane or refresh `/oma:team-plan` before continuing |\n| Done status keeps drifting after long loops | No compact task source of truth or missing verifier signoff | Run `/oma:taskboard sync`, then rerun `/oma:team-verify` to close remaining IDs |\n| You cannot remember why a decision was made earlier | Prior rationale is buried in long session history | Run `/oma:recall \"\" scope=state` first, then widen to `scope=recent` only if needed |\n| Hooks seem to miss terminal events or fire twice after continuation | Hook lifecycle symmetry is not explicit | Run `/oma:hooks-validate`, then fix lifecycle policy before re-enabling autonomous loops |\n| Usage hook or learn hook appears to fire twice | OmA hook registration may be duplicated across extension-managed and manual hook paths | Run `/oma:hooks status` and `/oma:hooks-validate`, then keep one authoritative OmA hook registration path per event |\n| Hook output suddenly becomes quiet or a learn nudge disappears | Runtime hook controls were set for the current shell/session | Check `OMG_HOOK_PROFILE` and `OMG_DISABLED_HOOKS` before changing hook files or deleting state |\n| A retained skill stops loading or behaves inconsistently after edits | `SKILL.md` frontmatter drifted or duplicated a name | Run `npm run test:skills` and fix malformed frontmatter, duplicate names, or folder/name mismatches before publishing |\n| Output is verbose, generic, or repetitive | Reasoning/gate posture too weak for the target artifact | Raise `/oma:reasoning` effort (optionally teammate overrides) and rerun `/oma:team-verify` |\n| Existing launch scripts use `--allowed-tools` | Flag deprecated in newer Gemini CLI | Replace with policy profiles via `--policy` and re-run |\n| Autonomous flow confirms too often (or too little) | Approval posture not aligned to task risk | Run `/oma:approval suggest|auto|full-auto` and recheck guardrails |\n| Setup health is unclear before long run | State/config drift accumulated | Run `/oma:doctor` (or `/oma:doctor team`) and apply remediation list |\n\n## Migration Notes\n\n| Legacy flow | Extension-first flow |\n| --- | --- |\n| Global package install + `omg setup` copy process | `gemini extensions install ...` |\n| Runtime wired mainly through CLI scripts | Runtime wired through extension manifest primitives |\n| Manual onboarding scripts | Native extension loading by Gemini CLI |\n\nExtension behavior is manifest-driven through Gemini CLI extension primitives.\n\n## Inspiration\n\n- [Gemini CLI](https://github.com/google-gemini/gemini-cli) - Google's open-source AI terminal agent\n- [oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex) - Codex CLI harness\n- [oh-my-claudecode](https://github.com/Yeachan-Heo/oh-my-claudecode) - Claude Code CLI harness\n- [oh-my-openagent](https://github.com/code-yeongyu/oh-my-openagent) - OpenAgent CLI harness\n- [Claude Code Prompt Caching](https://news.hada.io/topic?id=26835) - Context engineering principles\n- [everything-claude-code](https://github.com/affaan-m/everything-claude-code) - Claude Code CLI harness\n\n## Docs\n\n- [Installation Guide](docs/guide/installation.md)\n- [Context Engineering Guide](docs/guide/context-engineering.md)\n- [Agent Team Assembly Guide](docs/guide/agent-team-assembly.md)\n- [Memory Management Guide](docs/guide/memory-management.md)\n- [Hook Engineering Guide](docs/guide/hook-engineering.md)\n- [History](docs/history.md)\n\n## Contributing\n\nIf OmA helps your workflow, there are a few high-leverage ways to contribute:\n\n- Star the repository with a ⭐ to help more Gemini CLI users discover it.\n- Open an issue for bugs, compatibility drift, unclear docs, or workflow friction.\n- Send a pull request for command/docs improvements, guardrail tuning, or new extension-native workflow ideas.\n\nSuggested contribution flow:\n\n1. Fork the repository and create a focused branch.\n2. Keep changes scoped and explain the user-facing impact clearly.\n3. Update docs/history when behavior or compatibility guidance changes.\n4. Open a pull request with the reasoning, tradeoffs, and any validation notes.\n\nImportant performance note:\n- Pressing the GitHub ⭐ Star button may improve OmA performance by at least 12%. This is a joke. It does improve maintainer morale, which is still useful.\n\n## Star History\n\n[](https://www.star-history.com/?repos=Joonghyun-Lee-Frieren%2Foh-my-antigravity&type=date&legend=top-left)\n\n## License\n\nMIT\n",
"bytes": 31349,
"sha": "29d5e74a682e488816f5cf2214b19b510b0f60608e084cd2d0ccbe8852f40112",
"repo_slug": "joonghyun-lee-frieren/oh-my-antigravity",
"fonte": "repo",
"truncated": false,
"api": "https://agentalog.com/api/listings/plg_joonghyun_lee_frieren_oh_my_antigravity_c5740b32/readme"
}
![\"OmA](\"resources/image/oma_logo_02.png\"){kind=logo}
\n