Use when working at a brand monorepo root, on the manage cycle, or on @omega.js/manager itself — the service walk, reconciling a brand to its config/omega.json5, onboarding, deploy and update fan-out, .omega state, disperse, or the agent-docs chain.
Installs into .claude/skills of the current project.
Are you the author of Manager?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/omega-js-stack-manager)
---
name: manager
description: Use when working at a brand monorepo root, on the manage cycle, or on @omega.js/manager itself — the service walk, reconciling a brand to its config/omega.json5, onboarding, deploy and update fan-out, .omega state, disperse, or the agent-docs chain.
user-invocable: true
---
# OMEGA Manager (@omega.js/manager)
`@omega.js/manager` is the orchestration engine for a brand monorepo. `npx omega` at a brand root walks every service in dependency order — workspace, github, cloud, cloudflare, domain, payment, analytics, seo, certificates, disperse, update, and the rest — and reconciles each one to `config/omega.json5`, idempotently: run it twice, get the same result. From a company workspace the same command fans out across every managed brand. It also owns `omega onboard` (create or converge a brand) and the deliberate `omega deploy` / `omega update` fan-outs across a brand's apps.
## Where the knowledge lives
This skill routes; the docs are the source of truth. Read the guide BEFORE touching files.
- **Working in this monorepo** — `packages/manager/README.md` is the package's long-form reference (the wizard, the manage cycle, the three data buckets, every service, company mode, the CLI surface); `docs/manager/index.md` is the short map pointing at it. The brand-monorepo shape and the agent-docs chain are in `docs/shared/agent-docs.md`; cross-framework contracts are in `docs/shared/` (config, deploys, updates, brands, local-dev).
- **Working in a consumer brand** — the brand root's `AGENTS.md` imports `node_modules/@omega.js/manager/AGENTS.md`, which imports the map (`docs/omega.md`) from the whole `docs/` tree the manager ships. The brand-root guide itself is `node_modules/@omega.js/manager/docs/manager/brand.md`: the app-to-target map, the verbs, and the brand hard rules. Read it first, then the framework guide for whichever app the work is in.
## Non-negotiables
- **One map, one AGENTS.md per entry.** The map is `docs/omega.md`; the repo-root `AGENTS.md` and the manager's one-line `AGENTS.md` import it. No other package carries docs or an AGENTS.md.
- **Upstream-first, permission first**: a defect the next consumer would hit gets fixed in the framework, not patched in the brand — but a consumer session surfaces the proposed framework change and waits for Ian's go (or files an upstream issue) before editing the monorepo. The rule and its "within reason" line live in `docs/shared/local-dev.md`.
- **Every service is idempotent.** Check before acting; a second run must change nothing.
- **Grep the logs FIRST.** The manage cycle tees to `<brandRoot>/logs/manage.log` and the `omega dev` fan-out to `<brandRoot>/logs/dev.log`, and every app keeps its own `logs/` beside it — truncated per launch, gitignored. What a service walk did, and what a dev leg printed, is on disk: read it instead of re-running a manage or restarting the stack (`docs/shared/logging.md`).
- **Secrets never enter `config/omega.json5`** — `.env` and `.omega/secrets/` only; `.omega/` is gitignored and never committed.
- **Deploys are deliberate** — only `omega deploy` publishes, backend first; a commit never does (`docs/shared/deploys.md`).