
AgentOps
DevOps discipline for AI coding agents.

Install · The loop ·
Goals · Try it · Skills ·
Make it yours · Evidence ·
Beyond AgentOps
DevOps makes software delivery repeatable through shared practices, automated
checks and feedback. AgentOps brings that discipline to agentic coding sessions:
paved paths your agents can follow from intent to checked results, with memory
to carry useful context into the next task.
Those paths combine skills with the ao CLI
and your existing engineering tools. Plan clarifies the
expected behavior; Test helps check it;
Validate adds independent judgment where needed.
Skills guide the agent's decisions; executable gates check specific contracts.
Beads preserves the work graph, decisions,
results and project memories. Memory curates supported
findings into linked project knowledge, connecting lessons to the work and
sources behind them. The next session can use that record instead of starting over.
The skills are a kit, and you are expected to change it. Each skill is one
Markdown file of instructions. Keep the ones that fit how you work, rewrite the
ones that almost fit, delete the rest, and add skills you write yourself or find
in other libraries. What you end up with is your own operating model for agents,
which is the reason this project exists. Make it yours shows
how.
Use these paths with Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Pi and
other coding agents, or personal assistants such as OpenClaw and Grok Bot.
Start with one useful task; follow the operational loop
for a change or the goal workflow for work across sessions. When you
need a larger software factory, extend the same practices
with Gas City or tools from the Agentic Coding Flywheel.
Why use AgentOps?
A software factory
makes engineering practices reusable through tools, guidance and repeatable
workflows. AgentOps brings that approach into the coding session: clear intent,
automated checks, recorded decisions and a feedback loop into later work. Pick
the path your task needs and use the same practices when you change agents.
Behavior-driven development (BDD)
starts by agreeing on what the software should do in a concrete situation.
For retries, that could mean: “If a completed job arrives again, return its
result and charge the customer only once.” The same behavior guides the
implementation, its tests and any review. Plan helps you
settle those expectations before the agent starts editing.
| When you need to… | AgentOps adds |
|---|
| Decide what to do with an incoming report | Triage reproduces a bug report, external PR or alert, checks for duplicates and earlier decisions, and recommends an outcome with the evidence behind it. Accepted work gets a brief an agent can act on without the original conversation. |
| Get the agent to build what you meant | Plan makes the expected behavior clear enough to implement and test. Domain keeps the same names for concepts in the request, code and tests. |
| Fix a design that makes every change expensive | Architecture finds where the structure makes change costly and compares at least two interface designs by the call sites they produce. Refactor then makes the chosen change without changing behavior. |
| Build a tool that agents can use | Ergonomics checks whether an agent can find a CLI, API or MCP tool, read its output and recover from its errors, with the exact command and output behind each finding. |
| Keep a project moving after the chat ends | Interview settles a large goal with you. Beads preserves its intent, decisions and results in a searchable work graph, with persistent project memories for later sessions. Navigate identifies ready work, blockers and gaps in the goal. |
| Check whether the finished change meets the request | Test helps write checks for the intended behavior. Ordinary changes finish on checks and CI; Validate adds one fresh review when requested, hard to undo, or uncovered by a deterministic check. |
| Turn earlier work into useful context | Research traces the code and cites what it finds. Memory can draw on Beads handoffs, Git changes and check results to explain a decision in a report, or curate supported lessons into reviewed project documents. Later agents can recall the lesson and follow its sources. |
| Make a useful method repeatable | Skill Builder turns supported expertise into guidance with clear inputs, actions and limits. Skill Eval measures whether that guidance helps a named task, so it can be retained, revised or removed. |
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; a few use the ao CLI when it is installed. Invocation names
vary by agent: this README shows Claude Code's /agentops:<skill>; Codex uses
$agentops:<skill>.
The operational loop
Each change is shaped, built and checked. Use one fresh review when requested,
when a mistake cannot be cheaply undone, or when no deterministic check covers
the changed behavior. 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.
| Step | Skill | What it does with the scenarios |
|---|
| Shape | plan | Turns the request into scenarios for one small change. Skip it when intent is clear. |
| Build | implement | Makes the change and tests both scenarios. |
| Judge when needed | validate | A new session that didn't write it returns PASS, FAIL or NOT_PROVEN against the same scenarios. |
| Learn | memory | Optional: reviewed .context/ pages that later work can query. |
Enter at the step you need. An existing change can enter at Validate when an
acceptance judgment is needed. Ordinary changes finish on checks and CI. Review
is one round: repair findings and confirm with affected checks; review again only
when you ask. Report NOT_PROVEN with its gaps. The author cannot issue its own
PASS. Merging and releasing follow your repo's rules.
Goals
rpi runs Plan → Implement → checks, with Validate where a
mistake is costly, 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 (it
needs Beads: brew install beads, then bd init in your repo):