npm is not the problem.
The release workflow is.

The gap

What npm doesn't do
for you.

Every time you release, you're manually handling things npm never promised to handle.

• Find every package in the correct order
• Understand local dependency relationships
• Install, build, and test in the right sequence
• Avoid publishing .env files and secrets
• Bump versions across packages without skipping one
• Push once after all publishes succeed
• Return clear exit codes for CI and agents
• Keep a record of what changed and what shipped

For code agents — 2.30.0

A stable contract for
agents and the developers overseeing them.

Code agents are good at commands, but bad at guessing release state. xops gives them a stable contract: discover the graph, resolve intent, return JSON plans, avoid hidden prompts, execute in dependency order, journal local changes, and report what happened.

• ✓
  Never hangNon-interactive runs exit with a useful code, not wait forever — see exit code 4 in Install → exit codes.
• ✓
  Plan before mutateInstall, publish, push, and dependency fixes are explainable before they run.
• ✓
  Machine-readable firstPlain-English ask is for humans; JSON plans and stable exit codes are for agents.
• ✓
  One graph, one release pathThe package graph and stack file become the release path, instead of one-off publish scripts.
• ✓
  Native tools, safer orchestrationUnder the hood it is still npm and git. xops adds graph discovery, safety checks, ordering, and recovery context.
• ✓
  Local dev stays localKeep local file: development links. xops can translate them for npm publish and restore them afterward.
• ✓
  Recovery is part of releaseLocal file changes are journaled, external effects are reported, and the developer overseeing the agent gets a handoff, not a chat log to decode.

Full contract — what an agent can run alone vs. what needs your --yes: Agents.

Before vs after

What a real multi-package
release looks like.

Next direction — not yet shipped

Real release work isn't
one command. It's a chain.

Releasing upstream usually means installing/updating downstream consumers, building and testing them, releasing downstream if needed, writing version-tagged feedback, and pushing the final repo state. xops should eventually understand that chain instead of only running the command in front of it — remembering the last release, knowing the previous release for each package, and recommending the next step. None of this is available today; it's the direction, not a feature list.

The bigger gap — in progress

Release was the first workflow.
It is not the only one.

Once xops made release safe, the next problem became obvious: the same fragmentation exists everywhere else in the repo.

Tests live in one script. Linters in another. Dependency bots in config files. CI in YAML. API tests in Postman or OpenAPI. Security tools in scanners. Metadata deployment in MaGit. Mongo safety utilities in utilitix. Deployment and observability in provider-specific files.

Humans can inspect all of that slowly. Code agents need a deterministic map. xops gives both of them one — see Operations.

The agentic era — in progress

A shell is not enough
for a code agent.

Code agents can run shell commands, but they do not automatically understand the operating rules of a repository. They need to know what exists, what is safe, what is risky, what is already configured, what is missing, what requires approval, what changed, and what failed.

That is the gap xops fills. xops gives the repository a machine-readable operating contract, while keeping the human in control of risky actions. See Agents → agent economics.