Add omg plugin — multi-agent orchestration (25 agents, 41 skills)

[TheTrustedAdvisor]

Summary

Adds omg as an external plugin — multi-agent orchestration for GitHub Copilot CLI and VS Code.

• 25 specialized AI agents (19 specialists + 6 orchestrators)
• 41 skills (lightweight capability triggers)
• Architecture: Agents orchestrate, skills provide capabilities
• Tested: 538 unit tests + 683 behavioral tests (100% pass rate)
• Benchmarked: 111% of OMC parity across 5 scenarios

What omg does

Say this	What happens
autopilot: build a REST API	Full lifecycle: plan, implement, test, verify
ralph: fix all lint errors	Keeps working until every criterion passes with proof
team 3: fix TypeScript errors	3 parallel agents on independent files
security review this repo	OWASP audit with severity ratings
research-to-pr: fix auth bug	Investigate, implement, cloud agent creates PR

Plugin details

• Repository: https://github.com/TheTrustedAdvisor/omg
• License: MIT
• Author: Matthias Falland (Microsoft Data Platform MVP)
• Install: copilot plugin install TheTrustedAdvisor/omg

Checklist

• External plugin entry in plugins/external.json
• Public repository with plugin.json, agents/, skills/
• MIT license
• README with installation and usage instructions
• Tested on Copilot CLI v1.0.21

[Copilot]

Pull request overview

Adds the omg external plugin entry to the repo’s external plugin registry, making it discoverable/consumable via the generated marketplace metadata.

Changes:

• Reformats existing keywords arrays in plugins/external.json for readability/consistency.
• Adds a new external plugin entry for omg (GitHub source + metadata like author/homepage/keywords).

[aaronpowell]

We don't accept external plugins from outside of GitHub/Microsoft repos, see #1172

[TheTrustedAdvisor]

Hi @aaronpowell, thanks for taking the time to review and for linking #1172 — after reading the full announcement, the trust and silent-drift reasoning makes complete sense, and it's a policy I'd want in place if I were maintaining this marketplace. No objection to the close.

A bit of context on where omg comes from, because I think it matters for the question I want to ask: it grew out of my day-to-day consulting work, where I kept running into the same friction — stitching together the flood of new Microsoft skills (Fabric, Purview, the data platform stack) with the architecture, security, and review skills I rely on for every engagement. No single source covers that combination, and manually wiring them together per project doesn't scale. omg is the automation of that stitching: multi-source aggregation into a normalised IR, then native Copilot output. The result is that data-platform consulting workflows which currently require a lot of manual glue become a single-command setup on GitHub Copilot — which I think is a genuinely useful direction for the ecosystem.

I'd like to ask for guidance on one structural point, though, because the suggested path ("contribute items directly to the repo") doesn't map cleanly onto what omg is:

The value of omg isn't really in the 41 individual skills or 25 agents as standalone items — those would each be perfectly reasonable atomic contributions. The value is in the orchestration layer on top: coordinated multi-agent modes (/team, ralph, ultrawork, autopilot), handoffs between specialists, and the meta-skills that route work across the roster. That layer only makes sense when the components exist together as a plugin, with cross-references intact.

If I atomise omg into individual PRs, the orchestration layer has to be dropped — and with it, the actual differentiator. I'd end up contributing 41 skills that look like everyone else's, while the thing that makes omg worth installing lives nowhere.

Is there a recommended path for plugins where the meta/orchestration layer is the primary value? For example:

• Is there a category of "orchestration plugins" that might warrant different handling?
• Would a partner-track review (with some form of commit/tag pinning + audit commitment) be an option to discuss?
• Or is the honest answer "host it yourself, use direct-URL install, Awesome Copilot isn't the right channel for this shape of project" — in which case I'd happily take that as a clear signal.

For context on the trust question specifically: I'm a Microsoft MVP (Data Platform), so there's a public identity and accountability trail if that's relevant to the partner-track conversation. Not pitching that as a free pass on the policy — the silent-drift concern applies to me exactly the same as anyone else — just mentioning it in case it's useful context for whichever path you'd suggest.

Either way, thanks for the clear policy write-up in #1172 — it's the kind of documentation that makes it easy for contributors to understand why, not just what, which I really appreciate.