OpcOS · open framework · MIT

An operating system for your AI coding agents

One governance source, a component registry, and install discipline — shared across Claude Code, Codex, Gemini/Antigravity, and any AGENTS.md-compatible tool.

The problem

Use AI agents seriously for a few months and three failure modes appear on every machine.

Sprawl

Nobody knows what's installed

Skills, MCP servers, plugins, offline engines, and scheduled pipelines pile up across half a dozen dot-folders. "What does this machine have, and why?" has no answer.

Drift

Every tool has its own rules

You fix a working rule in one tool's config and forget the others. Three agents now follow three different constitutions — and behave accordingly.

Duplication

Copies fork, upstream moves on

The same skill exists as a copy in two tools and a hand-edited fork in a third. Upstream ships a fix; none of your copies get it, and nobody notices.

The architecture

Seven layers. The bottom two live inside one git repo; everything above is heavier, lives outside — and every piece of it is cataloged in the registry.

7
Productsthe repos your agents actually build
your-productyour-site
6
Pipelines & Automationscheduled systems that run on their own
nightly-reportpublish-jobs
5
Offline Toolslocal engines: TTS, rendering, transcription
your-tts-toolrender-engine
4
MCP Serversbridges from tools to capabilities
browser-mcpdata-mcpdocs-mcp
3
Plugins & Skillsskills / agents / commands / hooks
your-company-skillsreview-pack
2
Governanceone core rules file, deployed to every tool
core.mddist/*
1
AI Toolsthe harnesses where you actually chat
Claude CodeCodexGemini

OpcOS is not an agent and not an app. It is the repo + the discipline that keeps all seven layers coherent: write a capability once, use it in every tool, on every machine.

The system

Five mechanisms, each small on its own. Together they make agent sprawl impossible to sustain.

Parity

Governance, 1 source → N tools

One AGENTS.md-style rules file is the source of truth. A hook injects it where hooks exist; an adapter table deploys derived copies everywhere else. Fix a rule once — every agent inherits it.

Catalog

The component registry

Every plugin, MCP server, offline tool, pipeline, and product has a registry entry: priority (core → deprecated), storage class, purpose, and the exact install command. One file answers "what should a new machine install?"

Gate

adopt-repo discipline

Bringing anything external in follows six phases — research, analyze, advise, human gate, install, record. Rubric-scored, license-checked, provenance-tracked. Nothing gets installed off the books.

Audit

system-audit

Every month or two: fan out read-only scans over the whole machine, diff reality against the registry, flag duplicates and drift, clean up behind a human gate — soft-delete only, 30-day trash.

GC

config-gc

Garbage collection for agent config: orphaned skills, broken junctions, dead memory files, unused MCP entries, stale caches. Capped candidate lists, append-only log, never touches the source.

Law

The storage law

One rule decides where every component lives, so "where should this go?" never gets re-litigated — and heavy tools never get "tidied" into broken paths.

Modify the content → copy it into the repo.   Use it verbatim / path-bound / has a runtime → clone it outside, keep patches in vendor-adapt/.   Has a first-party store → install from the store, only record it. — the 3-branch storage law, recorded in every registry entry

Quickstart

Clone the framework, make the three templates yours, and generate your first registry views.

# 1. clone and make it yours
git clone https://github.com/ducnguyen221/opcos my-opcos
cd my-opcos

# 2. adapt governance/core.template.md  -> your core rules (AGENTS.md structure)
# 3. adapt bootstrap/install.template.ps1 -> run once per machine
# 4. describe your machine in registry.json (start from registry/registry.example.json)

powershell -File bootstrap\build-registry.ps1   # generates REGISTRY.md + docs/registry.html

Read more