Why Workloom?

Your team uses Claude, Codex, Gemini, and Copilot. You have 50 developers across 12 repositories. How many config files are you managing?

The answer is probably "too many" — and half of them are out of sync.

The Problem

AI tools have become essential to modern development. But managing AI configurations across teams is chaos:

New hire onboarding takes hours. Sarah joins the team. She needs to:

• Copy CLAUDE.md from Slack (which version?)
• Find the .codex/agents/ folder on GitHub
• Ask in #eng-ops for the "correct" Copilot settings
• Hope the instructions she follows aren't six months old

Configuration drift is silent. Three months later:

• The backend team uses Claude instructions v3
• Frontend still uses v2 (with the XSS prompt injection vulnerability)
• Mobile team copied v2, then modified it locally
• Nobody knows what production is actually running

Security is copy-paste. Your security team mandates:

"All MCP server configs must be reviewed before deployment"

But configs live in 47 different repos. How do you enforce this? Grep in CI? Hope people remember? File a JIRA ticket for each new repo?

Provider multiplicity compounds everything. You're not managing one config system. You're managing four:

• CLAUDE.md + .claude/settings.json for Claude
• AGENTS.md + .codex/config.toml for Codex
• gemini-prompt.yml for Gemini
• .github/copilot-instructions.md for Copilot

50 developers × 4 providers × 12 repos = 2,400 configuration touchpoints.

When a security patch needs to roll out, how long does it take to update everyone?

Before Workloom / After Workloom

Before	After
Copy CLAUDE.md from Slack thread	wl pull and you're configured
12 repos with diverging configs	One workspace, one source of truth
"Did anyone update the mobile team's config?"	Drift detection fails the build
Security review? File tickets and hope	Trust gates require approval for hooks/MCP
Production incident: "Which prompt version is deployed?"	Immutable revisions with full audit trail
Rollback = manual file editing + git archaeology	wl rollback --to=revision:42
Onboarding = 3 hours of setup	Onboarding = git clone && wl pull

Who Needs This?

Team Leads: You need to enforce standards without becoming a bottleneck. Publish a package once. 50 developers pull it automatically. Update it in one place. Track exactly who changed what and when.

Developers: You want to write code, not debug config files. wl pull should be as boring as npm install — it just works, every time, with no surprises.

Platform Engineers: You need CI gates that catch problems before production. wl sync --check in your build pipeline means drift = failed build = no surprises in prod.

Security Teams: You need approval workflows for dangerous operations. Hooks can execute arbitrary code. MCP servers can access databases. Workloom's trust gates ensure those configs can't land without explicit review.

What Makes It Different?

vs. Manual Copy-Paste:
Manual approaches don't version, don't track drift, don't enforce approval. One person's typo becomes everyone's CVE.

vs. Git Submodules:
Submodules give you versioning but not rendering. You still manage 4 provider formats. You still don't get drift detection or trust gates.

vs. Monorepo Scripts:
Scripts can copy files but they're brittle, repo-specific, and invisible to CI. Workloom is a proper package manager with immutable versions, content-addressed storage, and deterministic rendering.

vs. "Just Use a Template Repo":
Templates work for day 1. What about day 100? When your template evolves, how do you update 47 repos without breaking anyone? Workloom's workspace model handles this: update the workspace, everyone pulls the new revision, drift checks prevent silent breakage.

The Magic Moment

A developer joins your team. They clone the repo. They run:

wl pull

They see:

✓ Resolved 5 packages for workspace "platform-eng" (revision 28)
✓ Rendering for targets: root, apps/api, apps/web
  → Claude:  CLAUDE.md, .claude/settings.json, .claude/skills/security.md
  → Codex:   AGENTS.md, .codex/agents/reviewer.yml
  → Gemini:  gemini-instructions.yml
  → Copilot: .github/copilot-instructions.md
✓ Wrote 12 files, updated .loom/state.json

They're configured. They start coding. No Slack messages. No wiki searches. No "which version do I use?"

That's Workloom.

One Canonical Format, Rendered Everywhere

You write your AI workflow assets once — instructions, skills, agent definitions, prompts — in a provider-neutral format. Workloom renders them to the correct output format for each provider.

Change your Claude instructions? The update flows to Claude, Codex, Gemini, and Copilot automatically. One edit. Four outputs. Zero manual sync.

Immutable Versions, Instant Rollback

Every workspace revision is immutable and content-addressed. Deployed a bad prompt? Roll back:

wl rollback --to=revision:42

Workloom fetches revision 42, re-renders, and you're back to the known-good state in seconds. No git archaeology. No "who changed what in commit abc123?"

Trust Gates for Security

Hooks and MCP servers have dangerous capabilities. Workloom's trust system ensures they can't land without approval:

• Publish a package with a new MCP server → status: pending_review
• Security reviews it, validates the permissions
• Security approves → status: published
• Developers pull it → gated by trust level in workspace config

If a package tries to escalate privileges, the trust gate blocks it. Your audit trail shows exactly who approved what and when.

Monorepo Native

Workloom understands monorepos. One .loom/binding.toml can define multiple targets:

[targets.root]
path = "."
providers = ["claude"]

[targets.api]
path = "apps/api"
providers = ["claude", "codex"]

[targets.web]
path = "apps/web"
providers = ["claude", "copilot"]

Each target gets its own rendered configs. Your API team uses different tools than your web team? No problem. One workspace, multiple targets, deterministic rendering.

Built for CI

Drift detection is a first-class feature:

wl sync --check

This command:

1. Fetches your workspace's desired state
2. Compares it to local files
3. Exits non-zero if drift is detected

Add it to CI and you'll never ship mismatched configs again. Drift becomes a build failure, not a production incident.

Ready to Stop Managing Config Files?

Jump to Getting Started and see Workloom in action. In 5 minutes you'll have versioned, drift-checked AI configs across your entire team.

Or: Read the Architecture guide to understand how Workloom's content-addressed storage and rendering system works under the hood.

Or: Check out the Team Lead Guide to see how to publish, review, and manage packages for your organization.