Account Rotation

DevOps discipline for AI coding agents: shape the work, track it as a graph, and get each change judged by a fresh agent session that didn't write it.

Install · The loop · Goals · Try it · Skills

AgentOps provides optional skills and a CLI (ao). The same SKILL.md skills work with coding agents (Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Pi and others) and personal assistants (OpenClaw, Grok Bot). You state intent as behavior in your domain's words. The skills carry it through one change (Plan → Implement → Validate, an RPI) or, for bigger work, a goal made of many RPIs tracked in Beads, a dependency-aware issue tracker.

Why use AgentOps?

Quickstart

Pick one method per agent: a plugin plus npx on the same agent gives you every skill twice.

Claude Code

claude plugin marketplace add boshu2/agentops
claude plugin install agentops@agentops-marketplace
claude plugin details agentops@agentops-marketplace

Check that agentops appears in the plugin inventory. The bundle includes skills, four agents and tool-call guards.

Codex

codex plugin marketplace add boshu2/agentops
codex plugin add agentops@agentops-marketplace
codex plugin list --json

Check that agentops appears in the inventory. Skills use the agentops: prefix; custom roles and read limits have separate setup.

Everything else (Cursor, OpenCode, Gemini CLI, Pi, OpenClaw, Grok Bot)

With Node.js installed, run from your project directory, then pick your agents and skills:

npx skills@latest add boshu2/agentops

Add -g for a user-level install. In scripts, name the agents: npx skills@latest add boshu2/agentops -g -a cursor opencode -y (-y without -a can install into every agent the installer knows). Installer targets include cursor, opencode, gemini-cli, antigravity, pi, grok (Grok Build) and openclaw. Grok Bot has no installer target; add the same SKILL.md folders through its skill settings. Some skills need extra tools (install guide); what each host has been tested for is in host coverage and limits.

Start a new session so the skills load. Most skills need only your coding agent; Validate also needs the ao CLI. Invocation names vary by agent: this README shows Claude Code's /agentops: ; Codex uses $agentops: .

The operational loop

Each change is shaped, built and judged. You (or Plan) write intent as behavior (BDD), using one word per concept (DDD's ubiquitous language). For a system that calls queued work a Job, in Gherkin:

Feature: Job redelivery is idempotent
  A Job is one unit of queued work. Delivering it again never repeats its side effect.

  Scenario: A completed Job is delivered again
    Given Job "J-42" completed and charged the customer $20
    When the worker receives Job "J-42" again
    Then it returns the completed result of "J-42"
    And the customer has been charged $20 exactly once

  Scenario: A Job that failed before charging is delivered again
    Given Job "J-43" failed before charging the customer $20
    When the worker receives Job "J-43" again
    Then Job "J-43" completes
    And the customer has been charged $20 exactly once

The feature defines the domain term once; each scenario has concrete data, one action and an observable result. Keep scenarios in the issue or conversation; no .feature file is required.

Enter at the step you need; an existing change goes straight to Validate. The author never approves its own work. Merging and releasing follow your repo's rules.

Goals

rpi runs Plan → Implement → Validate for one outcome without check-ins (your agent's permission prompts still apply) and stops at acceptance, a blocker or a spent limit. Bigger work becomes a goal (experimental; needs Beads: brew install beads, then bd init in your repo):