Validate · render · sync
One manifest. Validated, rendered and synced config for every AI coding assistant.
Write your rules once in workloom.workspace.json. `wl validate` checks the manifest and its trust gates, `wl render` shows the exact files each provider will get, and `wl sync` writes only the files Workloom owns. `wl sync --check` fails CI when anything drifts.
- target-root / claudeCLAUDE.mdpolicy=committed_projectionwrite=manual-review
- target-root / codexAGENTS.mdpolicy=committed_projectionwrite=manual-review
- target-web / copilotapps/web/.github/copilot-instructions.mdpolicy=committed_projectionwrite=manual-review
- target-api / claudeservices/api/CLAUDE.mdpolicy=committed_projectionwrite=manual-review
- target-api / geminiservices/api/.gemini/settings.jsonpolicy=committed_projectionwrite=manual-review4 warnings
Summary: 5 plan(s), 5 file(s), 4 diagnostic(s) · dry-run: no files written
What Workloom does
- 01
Validate the manifest and its trust gates
`wl validate` checks workloom.workspace.json against the schema, then runs the trust gates over a render plan and lists what they would block.
- 02
Deterministic render plans
See every file each provider will get, with its projection policy, ownership and write mode, before anything is written.
- 03
Sync with ownership checks
`wl sync` writes only the projections the trust gate allows, atomically, and changes or removes only files Workloom owns.
- 04
Drift checks in CI
`wl sync --check` writes nothing and exits non-zero on drift; `wl status`, `wl diff` and `wl restore` show and repair it.
- 05
Every provider from one manifest
Claude, Codex and GitHub Copilot files from the same packages, per target, so a monorepo can give each package path its own providers.
- 06
Trust gates
Hooks, MCP servers, tool permissions and telemetry-emitting assets are blocked until the required approval exists.
- 07
Home profiles
`wl home` installs exact-pinned profiles into ~/.claude, ~/.codex, ~/.gemini and ~/.config under the same never-clobber rules.
- 08
A registry for packages
Versioned packages with channels, approval states, yank and deprecate, and a scan on every published version.
- 09
CI policy and service accounts
Each workspace says what CI should fail on, and service accounts give pipelines their own wl_ token.
- 10
Advisory review
An optional, org opt-in LLM review of package content that reports findings and never gates publishing.
- 11
Signed webhooks
Organizations subscribe a URL to audit event types and get HMAC-signed deliveries with retries.
- 12
Telemetry and debug bundles
Usage events carry hashed workspace and org IDs and no content; debug bundles are redacted and made only when you ask.
From a manifest to files on disk
- Step 1
Describe
`wl init` writes a workloom.workspace.json template (it refuses to overwrite one unless you pass --force). Fill in the binding, the targets, and each target’s providers and packages.
- Step 2
Validate
`wl validate workloom.workspace.json` checks the manifest against the schema, then reports trust gate diagnostics: denied hooks and MCP servers, and assets whose trust class exceeds the workspace maximum.
- Step 3
Render
`wl render -w workloom.workspace.json --dry-run` prints the render plan per target and provider: path, projection policy, ownership and write mode. Nothing touches disk.
- Step 4
Sync
`wl sync -w workloom.workspace.json` writes the projections the trust gate allows and records the drift baseline. Committed projections need a local approval first: `wl sync --approve-local`.
Stop hand-editing four config files per repository
Keep one workspace manifest per repository, render it for every provider your team uses, and let CI tell you when a projection drifts.