From operator-system
Create a new operator subagent for a CLI tool and add its enforce-operator hook guard
How this skill is triggered — by the user, by Claude, or both
Slash command
/operator-system:create-operatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a new operator subagent for the specified CLI tool and register its hook guard.
Create a new operator subagent for the specified CLI tool and register its hook guard.
$ARGUMENTS
Parse the input to identify:
kubectl, terraform). If multiple related commands are given (e.g., bun / bunx), treat them as a single operator that handles both.<tool>-operator using the primary CLI name (e.g., kubectl-operator, terraform-operator).If the input is unclear, ask the user to clarify what CLI tool to wrap.
Before writing the subagent, research the CLI tool so the operator file is accurate and useful:
<cli> --help (or equivalent) to get the top-level command structureCreate .claude/agents/<operator-name>.md following the established pattern. Use existing operators in this plugin as reference (read one if needed to match the format exactly).
The file MUST include:
---
name: <operator-name>
description: "<1-2 sentence description of when to use this agent, followed by 5-6 examples in the established format>"
model: sonnet
color: <pick an unused color from: green, yellow, orange, red, blue, purple, cyan, magenta>
---
The description field must follow the established example format:
Use this agent when the user needs to <do X> via the <cli> CLI — including <list of operations>. This agent should be the default for ALL <domain> operations.
Examples:
- User: "<example request>"
Assistant: "<example response>"
(<What the agent does>)
... (5-6 examples covering common operations and proactive usage)
Follow this structure (match the tone and style of existing operators):
Opening line: "You are an expert operator. Your sole purpose is to execute <cli> CLI operations and return only the most relevant, concise information."
Core Principles section:
Operations Reference section: Organized by category with bash code blocks showing key commands
Response Formatting Rules section: How to format output for different operation types
Error Handling section: Common errors and suggested fixes
What NOT to Do section: Standard prohibitions (no verbose output, no explanations, no filler, no repeating questions)
Read or create .claude/operator-map.json and add new entries mapping each CLI command to the operator name.
Each entry is a key-value pair where the key is the CLI command and the value is the operator name:
{
"<cli-command>": "<operator-name>"
}
If wrapping multiple related CLIs (e.g., bun and bunx), add a separate entry for EACH command, all pointing to the same operator.
Important: Do NOT modify any existing entries in operator-map.json -- only add new entries.
Operator created: <operator-name>
Agent file: .claude/agents/<operator-name>.md
Hook guards: <cli-command-1>, <cli-command-2>, ...
Operator map: .claude/operator-map.json
The main agent will now be blocked from running `<cli>` directly
and redirected to use the <operator-name> subagent instead.
npx claudepluginhub htxryan/agent-operators --plugin operator-systemProvides 98 rules for building or auditing agent-safe CLI tools, covering JSON output, error handling, input contracts, safety guardrails, exit codes, and self-description. Use for new CLIs, retrofits, pipelines, audits.
Makes out-of-session agents (Managed Agents, SDK loops, sandbox jobs) AgentOps-native using skills, the ao CLI, and CI validation instead of runtime hooks.
Guides creation and configuration of autonomous agents for Claude Code plugins, covering frontmatter, triggering descriptions, system prompts, tools, teams, permissions, and best practices.