The tools are not the problem.
The missing contract is.

The gap

What repo tools do not
do together.

Each native tool does its own job. The hard part is the workflow between them.

• Map packages, scripts, tools, configs, and ownership boundaries
• Know whether npm, pnpm, git, GitButler, CI, or a local script owns the next step
• Run package work in dependency order without rediscovering the graph
• Explain which actions are read-only, local writes, publishes, pushes, or setup
• Recommend missing capabilities only from repository evidence
• Keep risky setup and external effects behind explicit approval
• Return stable exit codes and JSON plans for CI and code agents
• Record what changed, what shipped, and what can be undone locally

For code agents

A stable contract for
agents and the developers overseeing them.

Code agents are good at commands, but bad at guessing repository state. xops gives them a stable contract: discover the repo, resolve intent, return JSON plans, avoid hidden prompts, execute in the right context, 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.

Release proved the gap

What a real multi-package
release looks like.

Native tools, one contract

xops is not another
tool to replace your tools.

The point is not to hide npm, git, GitButler, tests, scanners, or CI. The point is to stop asking every developer and every agent to rediscover the rules of the repo from scratch. xops detects the native owners, routes to them, and adds the missing contract: context, order, safety class, approval behavior, journal, and report.

The bigger gap

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

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.