Write once.
Ship to every agent.

Maintain a single .agloom/ source of truth for your instructions, skills, sub-agents, slash commands, permissions and MCP servers. Run one command. Every supported assistant gets what it reads natively.

Source on GitHub Read the docs

Project local

~/your-project/
├─ .agloom/
│  ├─ agents/
│  │  └─ reviewer.md
│  ├─ commands/
│  │  └─ test.md
│  ├─ docs/
│  │  └─ codestyle.md
│  ├─ overlays/
│  │  └─ claude/
│  │     └─ commands/
│  │        └─ deploy.md
│  ├─ config.yml
│  ├─ mcp.yml
│  └─ permissions.yml
└─ AGLOOM.md

Plugin git

git:acme/agloom-team-base
├─ agents/
│  └─ architect.md
├─ docs/
│  └─ architecture.md
├─ skills/
│  └─ git-commit/
│     └─ SKILL.md
└─ plugin.yml

~/your-project/
├─ .agloom/
├─ .claude/
│  ├─ agents/
│  │  ├─ architect.md
│  │  └─ reviewer.md
│  ├─ commands/
│  │  ├─ deploy.md
│  │  └─ test.md
│  ├─ docs/
│  │  ├─ architecture.md
│  │  └─ codestyle.md
│  ├─ skills/
│  │  └─ git-commit/
│  │     └─ SKILL.md
│  └─ settings.json
├─ .mcp.json
├─ AGLOOM.md
└─ CLAUDE.md

~/your-project/
├─ .agloom/
├─ .codex/
│  ├─ agents/
│  │  ├─ architect.md
│  │  └─ reviewer.md
│  ├─ docs/
│  │  ├─ architecture.md
│  │  └─ codestyle.md
│  ├─ rules/
│  │  └─ permissions.rules
│  ├─ skills/
│  │  ├─ git-commit/
│  │  │  └─ SKILL.md
│  │  └─ test/
│  │     └─ SKILL.md
│  └─ config.toml
├─ AGENTS.md
└─ AGLOOM.md

~/your-project/
├─ .agloom/
├─ .gemini/
│  ├─ agents/
│  │  ├─ architect.md
│  │  └─ reviewer.md
│  ├─ commands/
│  │  └─ test.toml
│  ├─ docs/
│  │  ├─ architecture.md
│  │  └─ codestyle.md
│  ├─ policies/
│  │  └─ permissions.toml
│  ├─ skills/
│  │  └─ git-commit/
│  │     └─ SKILL.md
│  └─ settings.json
├─ AGLOOM.md
└─ GEMINI.md

~/your-project/
├─ .agloom/
├─ .opencode/
│  ├─ agents/
│  │  ├─ architect.md
│  │  └─ reviewer.md
│  ├─ commands/
│  │  └─ test.md
│  ├─ docs/
│  │  ├─ architecture.md
│  │  └─ codestyle.md
│  └─ skills/
│     └─ git-commit/
│        └─ SKILL.md
├─ AGENTS.md
├─ AGLOOM.md
└─ opencode.json

See how every canonical file maps to its native slot — project structure guide →

For teams

Built for enterprise teams.
Scaling AI tooling across the entire organization.

Agloom was designed around the assumption that engineering organisations don't have one repo — they have dozens, sometimes hundreds. The plugin system turns shared conventions into a versioned dependency you publish once, pin per repo, and roll out across your fleet.

One canonical source per repo.

Every developer sees the same instructions, skills, and sub-agents — no matter which assistant they run today. Drift between CLAUDE.md and AGENTS.md becomes structurally impossible because both files are generated from the same source.
Reusable plugins across the fleet.

Package your team's conventions, review checklists, and deployment skills as plugins. Each project references the plugins it needs from config.yml and pins a version. Publish a new tag to roll updates out across the fleet; keep laggards on the old version until they're ready to migrate.
Project-scoped, never machine-scoped.

Agloom only reads from and writes to your project directory. It never touches ~/.claude/, ~/.codex/, or any global config. Reproducible across developer machines, CI runners, and contractor laptops.

Local project AGLOOM.md, .agloom/

highest

plugin: acme/android-stack @main

plugin: acme/conventions @v1.2.0

plugin: acme/base @v3.1.0

lowest

Merged .claude/settings.json


          {
          
        

            "permissions": {
          1
        

              "allow": [
          1
        

                "Read", "Grep",
          1
        

                "Bash(git log:*)",
          2
        

                "Bash(./gradlew:*)"
          3
        

              ],
          1
        

              "deny": ["Bash(rm -rf:*)"]
          1
        

            },
          1
        

            "hooks": {
          3
        

              "PostToolUse": [{ "matcher": "Edit", … }]
          3
        

            },
          3
        

            "env": { "PROJECT_NAME": "billing-service" }
          4
        

          }

Every key is traceable to the layer that contributed it. Later layers override earlier ones by key, with deep-merge for objects and replace for arrays — with opt-in patch operations.

The tax you're paying

Every assistant wants its own format.
You're maintaining all of them.

Modern engineering teams rarely standardise on a single AI assistant. Each tool reads its own instruction file, its own skills directory, its own settings format. The longer this goes on, the more they drift apart — and the more time your team spends keeping them in sync by hand.

Feature	Agloom	Claude	Codex	Gemini	OpenCode
Instructions file	AGLOOM.md	CLAUDE.md	AGENTS.md	GEMINI.md	AGENTS.md
Skills directory	.agloom/skills/	.claude/skills/	.agents/skills/	.gemini/skills/	.opencode/skills/
Sub-agents	.agloom/agents/	.claude/agents/	.codex/agents/*.toml	.gemini/agents/	.opencode/agents/
Slash commands	.agloom/commands/	.claude/commands/	via skills	.gemini/commands/*.toml	.opencode/commands/
MCP configuration	.agloom/mcp.yml	.mcp.json	.codex/config.toml	.gemini/settings.json	via opencode.json
Settings / permissions	.agloom/permissions.yml	.claude/settings.json	.codex/rules/*.rules	.gemini/policies/*.toml	via opencode.json
Reusable plugins	Canonical format	own format	own format	own format	own format
Variable interpolation	env · path · variables	env only	env only	env only	env only

The Agloom column is written by you. Every other column is generated by agloom transpile. See the full adapter reference →

Interpolation

One canonical file.
Values resolved per agent at transpile time.

Three namespaces of interpolation inside canonical files. ${env:VAR} pulls from your .env and process environment. ${agloom:VAR} expands to agent-aware paths — SKILLS_DIR becomes .claude/skills for Claude, .opencode/skills for OpenCode. ${values:VAR} reaches into plugin and project variables declared in config.yml. Agent-specific blocks and frontmatter overrides let each adapter get exactly the instructions it needs.

.agloom/agents/release-manager.md

---
name: release-manager
description: Drives releases for ${env:PROJECT_NAME}
model: zai-org/GLM-5-FP8
override:
  claude:
    model: ${env:CLAUDE_DEFAULT_MODEL}
  codex:
    model: gpt-5-codex
  gemini:
    model: gemini-2.5-pro
---
 
You are the release manager for the ${values:team_name} team.
 
## Release checklist
 
1. Build the project: `${values:command_build}`
2. Run the test suite: `${values:command_test}`
3. Publish the package: `${values:command_publish}`
 
Runbooks live in `${agloom:DOCS_DIR}/release-notes/`.
 
<!-- agent:claude -->
 
Use the `Bash` tool to execute each step. Before publishing, call
`AskUserQuestion` to confirm the version and changelog with the human.
 
<!-- /agent:claude -->
 
<!-- agent:codex -->
 
Commands run in the Codex sandbox. If a release step needs network
access, request explicit approval before executing it.
 
<!-- /agent:codex -->
 
<!-- agent:gemini -->
 
Use the `run_shell_command` tool for every step. After `build`,
summarise the log in three lines or fewer before moving on to `test`.
 
<!-- /agent:gemini -->

.agloom/config.yml

adapters: [claude, codex, gemini, opencode]
 
variables:
  team_name: "platform"
  command_build: "pnpm run build"
  command_test: "pnpm run test"
  command_publish: "pnpm publish --access public"

.env

PROJECT_NAME=billing-service
CLAUDE_DEFAULT_MODEL=claude-opus-4-6

---
name: release-manager
description: Drives releases for billing-service
model: claude-opus-4-6
---
 
You are the release manager for the platform team.
 
## Release checklist
 
1. Build the project: `pnpm run build`
2. Run the test suite: `pnpm run test`
3. Publish the package: `pnpm publish --access public`
 
Runbooks live in `.claude/docs/release-notes/`.
 
Use the `Bash` tool to execute each step. Before publishing, call
`AskUserQuestion` to confirm the version and changelog with the human.

---
name: release-manager
description: Drives releases for billing-service
model: gpt-5-codex
---
 
You are the release manager for the platform team.
 
## Release checklist
 
1. Build the project: `pnpm run build`
2. Run the test suite: `pnpm run test`
3. Publish the package: `pnpm publish --access public`
 
Runbooks live in `.codex/docs/release-notes/`.
 
Commands run in the Codex sandbox. If a release step needs network
access, request explicit approval before executing it.

---
name: release-manager
description: Drives releases for billing-service
model: gemini-2.5-pro
---
 
You are the release manager for the platform team.
 
## Release checklist
 
1. Build the project: `pnpm run build`
2. Run the test suite: `pnpm run test`
3. Publish the package: `pnpm publish --access public`
 
Runbooks live in `.gemini/docs/release-notes/`.
 
Use the `run_shell_command` tool for every step. After `build`,
summarise the log in three lines or fewer before moving on to `test`.

---
name: release-manager
description: Drives releases for billing-service
model: zai-org/GLM-5-FP8
---
 
You are the release manager for the platform team.
 
## Release checklist
 
1. Build the project: `pnpm run build`
2. Run the test suite: `pnpm run test`
3. Publish the package: `pnpm publish --access public`
 
Runbooks live in `.opencode/docs/release-notes/`.

Learn how interpolation works end-to-end — variables guide →

Plugins

Three lines of config.
A whole team's worth of conventions.

A plugin is a directory with a plugin.yml manifest and the same structure as a local project. Reference it by git URL or local path, optionally passing values for variables the plugin declares. Plugins stack in declaration order — later plugins and the local project override earlier ones.

Before .agloom/config.yml

adapters:
  - claude
  - codex
  - gemini
  - opencode
 
plugins:
  - git@github.com:acme/agloom-base#v3.1.0
  - git: git@github.com:acme/agloom-conventions
    ref: v1.2.0
    values:
      team_name: "platform"
  - ../shared/android-stack

After resulting layout

~/your-project/
├─ .agloom/
│  ├─ config.yml
│  └─ overlays/claude/.claude/settings.json
├─ .claude/
│  ├─ agents/
│  │  ├─ android-lint.md← android-stack
│  │  ├─ architect.md← agloom-base
│  │  └─ code-reviewer.md← agloom-conventions
│  ├─ skills/
│  │  ├─ android-build/← android-stack
│  │  ├─ git-commit/← agloom-base
│  │  └─ pr-review/← agloom-conventions
│  └─ settings.json
├─ .codex/ …
├─ .gemini/ …
├─ .opencode/ …
├─ AGENTS.md
├─ AGLOOM.md← authored by you
├─ CLAUDE.md
└─ GEMINI.md

Plugins can declare typed variables (description, default, required, sensitive). Sensitive values must come from environment variables — Agloom rejects inline secrets so they never end up in commits. Learn more about plugins →

Formatting

Ship canonical files that look canonical.

Agloom ships with agloom format — a pre-configured wrapper around prettier and markdownlint. It targets .agloom/**/* and **/AGLOOM.md by default. No config to install, no linter plugins to wire up. Run it as a pre-commit hook or manually before agloom transpile.

zsh — ~/your-project

$ agloom format

# write mode (default)

$ agloom format --check

# CI mode, exits non-zero if unformatted

Before AGLOOM.md

#   My Project
 
 
## Stack
 
*  TypeScript
*   React
-  PostgreSQL
 - Next.js 14
 
## Conventions
-  Server components by default.
*  Prisma for all queries.
## Boundaries
- Never skip strict mode.
- No raw SQL in `generated/`.

After AGLOOM.md

# My Project
 
## Stack
 
- TypeScript
- React
- PostgreSQL
- Next.js 14
 
## Conventions
 
- Server components by default.
- Prisma for all queries.
 
## Boundaries
 
- Never skip strict mode.
- No raw SQL in `generated/`.

Supports .md, .json, .yaml, .toml. Configurable via .prettierrc.*, .markdownlint.*, or a prettier / markdownlint section in .agloom/config.yml. Full formatting guide →

Is this for you?

Honest about the fit.

Use Agloom when

Your project (or your team's projects) uses two or more AI coding assistants.
Your team wants to standardise instructions, skills, and conventions across agents.
You have reusable skills, sub-agents, or commands that should be shared between projects.
You want a plugin system to distribute team-wide configurations across your fleet.
You need reproducibility across developer machines and CI without leaking personal preferences.

Skip Agloom when

Your project uses only one AI coding assistant and you're confident you won't add a second.
You have no need for shared configurations across projects.
Editing the tool's native files directly is fast enough for your workflow.

Agloom is overhead in exchange for leverage. If you don't have the leverage to gain, the overhead isn't worth it.

FAQ

Questions you might have.

Does Agloom replace Claude Code, Codex, Gemini, or OpenCode?

No. Agloom only generates the config files those tools read. Each assistant runs exactly the same way it does without Agloom — Agloom just makes sure their config files stay in sync with one canonical source. Install Agloom, uninstall it, switch assistants freely. The generated files are standard native configs.

Does Agloom touch global config like ~/.claude/, ~/.codex/, or ~/.config/gemini/?

Never. Agloom is strictly project-scoped. It only reads from and writes to your project directory. Your personal preferences, machine-wide tool settings, and home-directory configuration stay completely out of scope. Switching to Agloom in one project does not affect any other project or your global setup.

Install Agloom and try it on your project.

Read the docs → · View on GitHub →

Write once.Ship to every agent.

One canonical source per repo.

Reusable plugins across the fleet.

Project-scoped, never machine-scoped.

Every assistant wants its own format.You're maintaining all of them.

Three lines of config.A whole team's worth of conventions.