oh-my-agent Ships Five Major Versions in Seven Days: oma-security Replaces deepsec

Seven days, five major versions, from 15.10.0 all the way to 20.0.0. This wave of oh-my-agent updates didn't take the compatibility-layer route — it cut the old paths outright. Official numbers: 81 commits, 840 files, +70,280 / -32,120 lines, and the AgentMemory rework alone ran 1,095 tests. This isn't a patch job; it's a structural refactor with migration costs.

oma-security Replaces deepsec, With No Alias Left Behind

The most notable change is the security module rename. oma-deepsec becomes oma-security, the slash command /deepsec becomes /security, and there is no compatibility alias — the old syntax simply stops working.

The new module has a broader scope than its predecessor: it routes work from source, skills, MCP, and a restricted web runtime to target-specific engines, preserves the engine's forensic evidence, and requires independent verification before confirming a vulnerability or triggering a CI gate. Deepsec remains the default source-scanning engine. The whole skill ships with 11 resource files, including a 408-line findings contract.

The signal this design sends is clear: the "confirmation" step in security scanning is no longer a single engine talking to itself — it needs verification independent of the detection stage. For teams using oma as a CI gate, the logic for judging false negatives and false positives shifts along with it.

One Global Data Home Directory, Copy-First Migration

The second structural change is the data layout. OMA_HOME now points to a unified global data home directory (defaulting to ~/.oma), pulling definitions, state, scheduling, and backups all under one roof.

The migration strategy is copy-first, with conflict checks and checks on running state. The key point: old paths are no longer read as a runtime fallback. That means if your project still has historical state locally, the runtime won't automatically pick it up after upgrade — you must explicitly run oma state migrate --runtime.

This kind of "clean cut" carries real risk in a toolchain — parallel multi-project work, CI caches, and developers switching machines will all trip over it. But long-term, consolidating scattered state into a single home directory genuinely reduces voodoo problems like "why does this run locally but not in CI."

AgentMemory Isolation and Auditable Agent Decisions

AgentMemory's writes, recalls, retries, and imports are now scope-isolated by originating project and profile, and responses from shared servers are filtered by ownership. Installation and updates automatically prepare the default AgentMemory provider unless the project explicitly opts out or switches to another provider.

Another change that's easy to overlook but has outsized impact: agent decisions are now recorded as state events (b4d76a71), so choices made during a run can be reviewed after the fact. Combined with the security module's independent-verification requirement, it's clear oma is moving toward "auditable agent orchestration" rather than just emphasizing degrees of automation.

MCP (Model Context Protocol) here refers to one of the three target categories that oma routes workloads to, alongside source and skills. MCP is a protocol that lets AI applications connect to external tools and data sources in a standardized way; agents use it to invoke capabilities packaged as servers. In oma-security's workflow, scan targets get routed to the corresponding specialized engine, and the MCP path means the objects of security review aren't just static files but also external services reached at runtime through MCP. This also explains why the new module emphasizes a "restricted web runtime" — when agents can proactively initiate network or tool calls, the attack surface is larger than pure source scanning, so an additional independent verification layer is needed beyond detection to confirm a vulnerability really exists rather than being noise generated by the toolchain itself.

Extensible Commit Hooks: oma No Longer Overwrites Your Config

The managed commit-msg hook now executes every executable file under .githooks/commit-msg.d/ in filename order, rejecting the commit on any non-zero exit.

The real highlight: oma never writes to that directory. So a commitlint invocation can survive an oma update. This addresses a very typical pain point in toolchains — a self-updating tool wiping out your carefully configured hooks. oma hands the extension point to users and keeps only the scheduling authority for itself.

oma-dev-workflow also brings a set of toolchain profiles: Python, JS/TS, Dart/Flutter, Dockerfile, and local commitlint, with guidance on reusing project validation tasks.

Git's commit-msg hook is a local script triggered after the commit message is written but before the commit actually lands, commonly used to validate message format. The .githooks/commit-msg.d/ pattern of "directory + execute in filename order" is a common Unix configuration-management convention: define an extension point as a directory, and any executable placed in it following the naming rules gets invoked in sequence, aborting on any non-zero return. This lets users and third-party tools each deploy their own rules without interfering with one another. oma's promise never to write to that directory effectively hands full ownership of hook contents to the user, keeping itself responsible only for ordered scheduling — which is the fundamental reason it can coexist long-term with external validators like commitlint without being clobbered by oma update.

Bugs Fixed: JSON Output, Schedule Sync, and Hook Deduplication

A few fixes worth calling out on their own:

• oma retro --json used to print banners and spinners before the JSON. For anyone scripting parsers, that's a bug that outright breaks the output format; now it emits a single valid document, and empty windows work too.
• schedule sync crashed when a manifest line was missing a required field, causing all healthy tasks to go stale together. Now malformed lines are dropped and reported, and schedule list names them.
• Concurrent hook deduplication could let a race publisher's freshly acquired claim expire. The fix re-checks the clock after reading, and tolerates clock rollback only within the TTL.
• Orphan cleanup no longer touches internal services like AgentMemory and Serena maintenance, scoped strictly to the agent scheduling namespace.
• The design workflow route now requires a visual target, so "API design" no longer misfires the design workflow.

Also, help text once showed the --older-than default as the mangled 90ds with a duplicated unit; standalone skill installs now carry the shared guidance they reference (#866), and pinned local Serena bridge entries get fixed while preserving user environment and server options.

Slimming Down and Docs: Plugin Package Drops 471 Duplicate Files

On size optimization, the full plugin package now shares a single package-level resource tree, cutting 471 duplicate files outright. The cost is that the root plugin skill depends on that shared tree, so installing via the OMA preset is recommended over npx skills or APM.

The command surface got a cleanup pass too: internal entries are hidden from oma describe and help but still runnable; 25 previously undescribed command groups gained descriptions; skills matrix was renamed to oma skill matrix, and the plural form gets rejected.

Docs are now generated from source: the CLI registry is rendered by oma describe, the skill catalog by SKILL.md frontmatter, and both have a --check mode to report stale blocks. The docs site gained mermaid diagrams for routing, ultrawork, ralph, and config resolution, plus decision tables and a glossary, and 11 language versions and 12 README translations were synced.

One "retraction-style" correction is worth noting: the ralph judge is now described as prompted rather than independent, because nothing is checking the spawn. This kind of proactive correction of overstated claims in one's own docs is rare in open-source tooling.

a skill's frontmatter refers to the metadata block wrapped in --- at the top of a SKILL.md file, typically declaring the skill's name, description, version, and dependencies — similar to YAML front matter in a static site generator. By having oma render the skill catalog directly from this frontmatter, the catalog page and the skill definition share a single data source, eliminating the need for a second hand-maintained manifest. Combined with rendering the CLI registry from oma describe, both major doc sources become machine-generatable artifacts, and --check mode is used in CI to compare the committed docs against freshly regenerated output, flagging stale blocks the moment source changes outpace doc updates — preventing docs from drifting across versions.

What You Need to Do to Upgrade

Three actions, none optional:

1. Run oma state migrate --runtime to migrate project-local state; the runtime reader no longer loads it.
2. Replace /deepsec with /security in your scripts and muscle memory.
3. Replace oma skills matrix with oma skill matrix.

Installation is unchanged:

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.ps1 | iex

Project URL: https://github.com/first-fluke/oh-my-agent . The team also previewed the next direction: tightening the ralph judge so spawns are verified rather than just prompted.

The project bills itself as "for teams that orchestrate more than they prompt." Judging by the moves across these five versions, that's not a slogan — cutting compatibility, consolidating state, adding audit — every step heads deeper into engineering-grade orchestration. The cost is that upgrades are no longer frictionless; the reward is behavior that's more predictable and more inspectable.

One-line Summary

oh-my-agent's five-version refactor: cut compatibility, consolidate state, add audit — upgrades require explicit migration.

Paragraph Summary

In seven days, oh-my-agent went from 15.10.0 to 20.0.0, completing a structural refactor across 81 commits and 840 files with a net gain of roughly 38k lines — not a compatibility-style patch. Three core changes: the security module oma-deepsec becomes oma-security, /deepsec becomes /security with no alias, and vulnerabilities now require independent verification before confirmation; OMA_HOME consolidates into a global data home directory, old paths no longer serve as runtime fallbacks, and oma state migrate --runtime is mandatory; AgentMemory is isolated by project and profile, and agent decisions are logged as reviewable state events. Additionally, commit hooks extend via .githooks/commit-msg.d/ with oma never overwriting user config, the plugin package shares a resource tree that cuts 471 duplicate files, and docs are source-generated with --check validation.