claude-ops turns Claude Code into a business dashboard with 68 skills and 21 agents

The morning briefing is the product, not the skills

claude-ops presents itself as a business operating system for Claude Code, and the promise is one command and sixty seconds to see everything. The banner in the README is the interface: a single panel with rows for INFRA, CI/CD, INBOX, PRs, SPRINT and REVENUE, each with a bar and a one line status, ending with a next action line that names the specific thing to do.

What that panel pulls together is the reason the project exists. Infrastructure health with the ECS task count, RDS and Redis status. CI/CD with the number of passing and failing tests and the failing run named. A unified inbox counting Slack, Telegram and Gmail messages. Open pull requests marked ready to merge or needing review. Sprint progress as issues completed out of total. And revenue, which the description lists as Stripe plus RevenueCat, along with AWS.

That last row is the surprising one, and it tells you what the intended user is. This is not a developer dashboard with a revenue widget bolted on. It is a single-person or small-team operator who wants a morning view of a business, where the code is one part of the estate alongside marketing, ecommerce, support messages and money in.

The README describes the C-suite agents as autonomous and acting on your behalf, and the topics list names inbox-zero, morning-briefing, pr-automation, revenue, ecommerce and marketing alongside the more technical aws, devops and mcp. The integrations are named in the project description too, with WhatsApp, Email, Slack and Telegram for the inbox, Shopify for ecommerce, Klaviyo, Meta and GA4 for marketing, Bland and ElevenLabs for voice, and Datadog, New Relic and OpenTelemetry for APM.

So the scope is deliberately wide, and the cost of that scope is the thing to weigh before installing anything.

One plugin, three harnesses, and a skill shape that follows the official convention

The v3.6 section describes the current architecture, and it is the part of the README that most directly affects how you would install and maintain this.

The project is one plugin that targets three harnesses. Hermes gets an installer that mirrors the skills into ~/.hermes/skills so working slash commands are available, and links a hermes-plugin/ directory for a skill_view("ops:*") style call. Grok loads the Claude plugin as-is, with no .grok-plugin of its own. Claude Code itself needs none of that, since it is the plugin's native format.

The skills follow a stated shape: third-person trigger descriptions, a shared preamble, and an ops-rules skill, with the plugin-root CLAUDE.md reduced to a pointer rather than a wall of text. Oversized skills are split into a references/ subdirectory so the always-loaded part stays small.

Version consistency is handled by a tool rather than by discipline. The README says plugin.json equals the Hermes plugin.yaml equals the installer pin, and that an ops-release command keeps them together. That is a small thing that prevents a whole class of problem, where a user updates the plugin but the installer still writes an older manifest.

The MCP configuration is worth a separate look, because it inverts a common assumption. The plugin's .mcp.json is empty, and servers start on demand rather than once per session. For a project with 22 integrations, that is the difference between every Claude Code session starting a dozen MCP servers and starting none of them.

The documentation is split into a docs/ tree with per-harness port documentation, per-skill markdown under skills/, and a CHANGELOG that the README treats as the authoritative record of what changed.

v2 added the autonomy layer, and the safety hooks are the part to read first

The v2 release turned claude-ops from what the README calls a briefing plus comms surface into an autonomy layer for Claude Code itself, and it states that the change is purely additive with no v1 behaviour changes by default.

The mechanism for the auto-fix subsystem is PostToolUse hooks feeding a headless Haiku fixer. The idea is that when a merge lands and the build breaks, or when a build fails outright, the plugin drives a cheap model to attempt the repair rather than waiting for a human to notice a red build. The v2 table also lists pre-installed specialist agents with silent routing from general-purpose to a specialist, so a request goes to the agent best suited to it without the user choosing.

Then there are the safety hooks, described as universal and always-on. Three are named: a secret scan, an rm -rf anchor block, and a warning on pushes to main. These are the ones to read before enabling anything else, because they are the layer that stands between an autonomous agent and a production branch.

The other v2 capabilities are more specialised. A multi-account Claude Max rotator runs on a launchd daemon with what the README calls an AI-brain, meaning jittered post-rotation respawn plus a /login re-auth so a freshly rotated account is not hit by a synchronised first-call burst. The rationale is practical: rotating accounts on a timer without jitter means every account gets its first request at the same moment.

A recap skill produces a multi-session digest in the tmux status-right area or the statusLine, which is a specific choice that places the summary where you already look rather than in a chat window. A periodic Task tracking nudge runs as a PostToolUse hook. And the marketing skill gained Windsor.ai as a live data source for the dashboards, marketing, socials and ecommerce views.

A separate note in the repository root, APPROVAL_POLICY.md, exists separately from the README, and the README's feature description also mentions a YOLO mode. Both point at the same question: how much autonomy do you want an agent to have over a system that touches AWS, Stripe and your inbox.

Installing means a plugin update and an installer pin

The quick start for the auto-fix subsystem is the part of the README that shows the actual command:

# 1. Upgrade
/plugin update ops@ops-marketplace

So the distribution mechanism is a Claude Code marketplace, with the plugin published under the ops name at ops-marketplace, and the upgrade path is the plugin update command rather than a git clone.

The repository layout explains how much more than a plugin this is. There is a .claude-plugin/ directory for the plugin manifest, an installer/ directory, a claude-ops/ directory that holds the skills, scripts/ for the shell that ties it together, docs/ for the documentation tree, plus AGENTS.md, CLAUDE.md, APPROVAL_POLICY.md, SECURITY.md and CONTRIBUTING.md at the root. Three directories suggest separate workstreams: .cursor/ for Cursor, desktop-act/ for a desktop automation component, and pocket-ops-ui/ for a user interface.

There is also a .githooks/ directory and a .github/ directory, and a .planning/ directory that suggests the project plans its own work in the repository. The primary language is Shell, which fits the design: the plugin is a lot of small scripts that gather state from various APIs and format it into the panel.

The repository is MIT licensed, with a LICENSE file at the root and a badge in the README, which is a permissive grant with no copyleft obligation on what you build with it. That is a licensing note rather than legal advice, and it says nothing about the terms of the third party services you will connect.

The release cadence is fast enough to matter for pinning. The repository listing shows v3.11.0 on 2026-10-09, v3.10.29 the same day and v3.10.28 on 2026-10-04, and the version badge in the README reads 3.11.2, which is ahead of the tags. The last push was on 2026-10-20 and the repository is not archived.

Where claude-ops is the wrong tool

The first limit is the trust surface, and it is large. Connecting WhatsApp, email, Slack, Telegram, Stripe, RevenueCat, AWS, Shopify, Klaviyo, Meta, GA4, Bland, ElevenLabs, Datadog, New Relic and OpenTelemetry means holding live credentials for systems where a mistake costs money or leaks data. The safety hooks reduce that risk, but they are a mitigation layer, not a boundary, and a project with 68 skills and 21 agents has a much wider blast radius than a script you wrote yourself.

The second limit is the autonomy setting itself. The project advertises autonomous C-suite agents, autonomous PR merge, and a YOLO mode. Each of those is a decision to remove a confirmation step, and the combination of auto-merge with an autonomous agent that can push to main is a configuration where a hallucinated diagnosis becomes a production change. The rm -rf anchor block and the main push warning are aimed at exactly this, but they are guardrails inside a system designed to act without asking.

The third limit is that the multi-account rotator is about account mechanics rather than business operation. Rotating between Claude Max accounts on a timer, with jitter and re-auth handling, is a workaround for a usage limit, and it means the tool is coupled to how a vendor meters a subscription. If that changes, the rotator is work you now maintain.

The fourth is the assumption that one dashboard fits. The briefing is well suited to a single operator with one estate. A team with several services, several inboxes and a proper issue tracker will find that a tmux panel cannot carry the state they need, and that the sprint row in particular duplicates something their tracker already knows better.

The alternative to weigh is doing the aggregation yourself, which is what most teams do with a scheduled script that queries a handful of APIs and posts a summary. The difference in approach is that your script has three integrations and one credential, and claude-ops has 22 integrations and a daemon, and it can act on what it finds rather than only report it. If you want the panel and nothing else, the plugin is larger than you need. If you want the agent to fix the failing build and merge the PR, the skills and hooks are the reason to take the dependency.

Editorial conclusion

Adopt claude-ops if you run Claude Code across several services and want one briefing that combines infrastructure, CI, inbox, pull requests and revenue, and if you are willing to give an agent layer real credentials for those systems. Do not adopt it as a light personal setup, because 68 skills and 21 agents is a large surface to trust with AWS, Stripe and inbox access, and YOLO mode removes the confirmation prompts entirely. Verify first which skills you actually enable, that the safety hooks for secret scanning and the rm -rf anchor block are active, and that the plugin version pinned by the installer matches the version in plugin.json.

Frequently asked questions

Official sources

1. License: MIT
2. Lifecycle-Innovations-Limited/claude-ops on GitHub
3. Project website
4. README
5. Releases