rhize-ops: The Claude Code Plugin for Agency Operations

rhize-ops is a Claude Code plugin from Rhize Media built for running a team, not building software. It packages two operational jobs into skills: turning a Claude Code session into a structured hand-off for a teammate, and monitoring which installed skills are actually earning their keep. It ships as part of the Rhize plugins for Claude Code marketplace.

What is rhize-ops?

rhize-ops is a Claude Code plugin that automates two everyday agency-operations tasks: delegating work to a teammate without losing context, and watching skill usage health across a team's Claude Code setup. It's explicitly scoped to running the team — its sibling plugin, rhize-devflow, handles building software.

We built rhize-ops to run our own agency. At Rhize Media, work regularly starts in a Claude Code session — research, a client call, a half-finished task — and needs to land in someone else's hands with enough context that they don't have to reconstruct it from scratch. And because we install a lot of skills across a lot of sessions, we needed a way to see which ones were actually pulling weight versus sitting there unused. rhize-ops is the tooling we wrote to solve both problems, made public through the rhize-plugins marketplace.

What problem does rhize-ops solve?

rhize-ops solves the operational gap between doing work in an AI agent and running a team around it. Two specific failure modes drove its design: delegated work losing context on hand-off, and installed skills accumulating without anyone knowing which ones are worth keeping.

The first failure mode is familiar to anyone who's delegated work after a Claude Code session: you know what needs to happen, but writing it up for someone else — with the right Jira project, the right priority, the client context from a call, starter prompts they can paste into their own session — takes almost as long as doing the work yourself. That friction means delegation happens less often than it should.

The second failure mode is specific to teams that lean on Claude Code skills heavily. Skills accumulate. Some get used daily; others were installed once for a one-off task and never touched again. Without visibility into actual usage, you can't tell which skills deserve more investment and which are dead weight cluttering the skill list. rhize-ops addresses this with an audit pipeline that reads accumulated transcript data instead of guessing.

What skills does rhize-ops ship?

rhize-ops ships two skills and one command, plus a data subsystem that powers the second skill. Together they cover delegation and skill-usage visibility — the two operational jobs the plugin exists for.

Underneath skill-dashboard sits skill-monitor/ — not a skill itself, but the audit tool the dashboard reads from. monitor.py walks Claude Code and Cowork transcripts to produce JSON snapshots, and dashboard.py aggregates those snapshots into the rendered view.

How does delegate-to-tom work?

delegate-to-tom converts a Claude Code session into a full delegation package — not just a note, but Jira issues, Slack Canvases, and a tagged Slack notification, all generated from the context already in your session. It's invoked as rhize-ops:delegate-to-tom and triggers on phrases like "delegate this to Tom," "hand this off to Tom," "assign this to Tom," or a bare "delegate," "hand off," or "assign" — Tom is the default recipient.

The skill runs the full delegation pipeline in sequence. It gathers context from your current session and the Obsidian vault, and optionally pulls in a relevant Fireflies meeting transcript if you tell it there's one to reference. It then asks a few quick questions — which Jira project each task belongs to, a due date, a priority — before creating a Jira issue per task. Any relevant vault documents get shared as Slack Canvases, and the whole package posts to #tom-tasks: a scannable main message plus a threaded reply per task, tagging Tom so he's notified. Each task in the package includes step-by-step instructions, known gotchas, starter prompts the recipient can paste straight into their own Claude session, and validation criteria so they know when the work is actually done.

Two details matter in practice. First, if you're delegating multiple tasks at once, the skill asks about the Jira project for each task individually — it doesn't assume they all land in the same place. Second, giving the skill a transcript when one exists changes the quality of the output substantially: instead of a bare task description, the recipient gets real client context — quotes, decisions, deadlines — pulled straight from the meeting.

How does skill-dashboard work?

skill-dashboard reads the accumulated skill-monitor snapshots and renders them as an interactive dashboard, instant because it doesn't rescan transcripts on every render. It's invoked as rhize-ops:skill-dashboard and triggers on "show the skill dashboard," "render the audit dashboard," "skill usage dashboard," or the /skill-dashboard command.

The dashboard covers weekly usage trends, a top-skills view with rank-of-the-week deltas, a direct-versus-indirect leverage comparison (are your subagents using a skill more than you invoke it directly?), a prune-candidates table for skills that fired historically but have gone quiet, a subagent-type breakdown, project and host-versus-Cowork rollups, and week-over-week movement. It renders as a Claude Artifact on surfaces that support it — Claude Desktop, claude.ai — or opens as HTML from Claude Code when it doesn't.

Because the dashboard reads pre-computed snapshots rather than re-scanning transcripts each time, a normal render is fast. If you want current data mid-week instead of whatever has already accumulated, ask to "refresh the dashboard" — that reruns the monitor before rendering. And if the dashboard comes back empty, it means no snapshots exist yet; running python3 rhize-ops/skill-monitor/monitor.py --days 0 seeds one.

Example prompts

A few ways these skills get invoked in practice, taken directly from how we use them day to day:

• "Delegate the SJ Glass sitemap cleanup to Tom — there's a client call transcript from Tuesday that has the details." This triggers delegate-to-tom, which pulls in the Fireflies transcript, asks for the Jira project and priority, and produces the full task package with Tom tagged in Slack.
• "Show me the skill dashboard" or simply /skill-dashboard — renders the current audit view without any transcript rescanning, since it reads existing snapshots.
• "Refresh the dashboard, then show me prune candidates" — reruns monitor.py for current data before rendering, surfacing skills that used to fire but have gone quiet.

Who is rhize-ops for?

rhize-ops is built for anyone running Claude Code across a team where work gets delegated between people and skills accumulate across projects. If you're a solo user with no one to hand work off to and a short, static skill list, the plugin has less to offer — its value comes specifically from the coordination overhead that shows up once more than one person, or more than a handful of skills, is involved.

Concretely, that's teams or agencies where a lead runs Claude Code sessions and periodically needs to route pieces of that work to someone else with full context attached, and where the Claude Code setup has grown enough skills that nobody has a clear read on which ones are actually being used. The plugin was written for exactly that situation inside Rhize Media — Jim running sessions, delegating pieces to Tom Cassidy, and needing periodic visibility into skill health across the whole setup — and it's public now for other teams in the same spot.

Setup

rhize-ops installs like any plugin in the rhize-plugins marketplace. In Claude Code, add the marketplace with /plugin marketplace add https://github.com/Rhize-Media/rhize-plugins, then install rhize-ops from the resulting list. In Cowork, go to Settings > Plugins > Add Marketplace and point it at the same repository. Once installed, the skills trigger on the natural-language phrases described above, or you can invoke them explicitly as rhize-ops:delegate-to-tom and rhize-ops:skill-dashboard.

delegate-to-tom assumes Jira and Slack access, plus an Obsidian vault and optionally Fireflies for meeting transcripts — the pipeline gathers context from all of those. skill-dashboard has no external dependencies beyond the accumulated snapshots it reads; if none exist, seed one with the monitor.py command noted above.