Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/controlplane-com/ai-plugin/workload-troubleshootingnpx skills add controlplane-com/ai-plugin --skill workload-troubleshootinggit clone --depth 1 https://github.com/controlplane-com/ai-pluginWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00049 | $0.04248 |
| Opus 5 | $0.00024 | $0.02124 |
| Sonnet 5 | $0.00010 | $0.00850 |
| Haiku 4.5 | $0.00005 | $0.00425 |
Grade A, and why
workload-troubleshooting scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 230 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Workload Troubleshooting
The symptom-first companion to the workload skill (which owns workload types, the spec shape, and the create/update tools). Given an unhealthy workload, map what you observe to its platform-specific root cause and a fix the schema will actually accept. Diagnosis is read-only and MCP-first; most failures trace to a Control Plane rule a generic engineer would not guess — deny-by-default firewalls, the secret identity+policy chain, blocked ports, the sleep-binary shutdown rule. The single most common is OOMKilled. Deep remediation for each area lives in the domain skill named in that section; this skill is the diagnostic map.
Step 1 — Gather state (read-only)
| Tool | What it tells you |
|---|---|
mcp__cpln__list_deployments |
Start here. Per-location readiness with reason/message. Pass location to drill into one failing location. |
mcp__cpln__get_workload_events |
Image pulls, crashes, scheduling, probe failures, OOMKilled. |
mcp__cpln__get_workload_logs |
App logs (LogQL); the _accesslog container holds HTTP status codes and latency. |
mcp__cpln__get_resource (kind=workload) |
The spec and current status. |
mcp__cpln__list_metrics then mcp__cpln__query_metrics |
Resource pressure — memory before OOM, CPU, latency. |
mcp__cpln__list_workload_replicas |
Confirm which replicas are currently running. Use the cpln CLI after reading the cpln skill if in-container inspection is essential. |
mcp__cpln__query_traces then mcp__cpln__get_trace |
For a slow or intermittently failing request: which span in the path spent the time or errored. Needs tracing enabled on the GVC (opt-in). Deep dive in metrics-observability. |
CLI fallback (MCP unavailable, interactive shell, or CI/CD):
cpln workload get WORKLOAD --gvc GVC -o json
cpln workload eventlog WORKLOAD --gvc GVC -o json
cpln logs '{gvc="GVC", workload="WORKLOAD"}' --limit 50 # |= "error" filters; container="_accesslog" for HTTP codes
cpln workload connect WORKLOAD --gvc GVC --location LOCATION # interactive shell
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 230 lines · 49 tokens per session scan A d1d6210234e3
workload-troubleshooting is a skill published in the GitHub repository controlplane-com/ai-plugin (10 stars, last pushed 8d ago), licensed MIT. It adds 49 tokens to every session and 4,248 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
rustfs-release-publish
Run the end-to-end RustFS console gate, version bump, preview validation, human confirmation, and final-tag publication pipeline. Use only when the user explicitly asks to release or publish a RustFS version (发版/发布).
pr-review
Review a GitHub PR end-to-end from a URL or number — fetch metadata, inspect the diff, run multi-role adversarial review, check CI status, and post the review comment. Use when the user provides a PR link and asks to review it.
issue-triage
Triage a GitHub issue — determine if it is already fixed, needs implementation, or should be closed. Searches related commits and PRs, verifies implementation status, and posts a triage comment or closes the issue. Use when the user provides an issue URL and asks whether it can be closed or needs work.
security-advisory-lessons
Perform a dedicated RustFS security/advisory review for authn/authz, IAM, RPC trust, paths, secrets, browser isolation, encryption, Object Lock, or other security boundaries. Use only when the user requests a security/advisory review or an adversarial review explicitly escalates to the full advisory map; do not…
tier-debug
Debug ILM tiering / lifecycle transition issues — NoSuchVersion on tier GET, restore failures, xl.meta inspection, remote-tier versionId tracing. Use when investigating tiered/transitioned objects, warm backends, or transition metadata.
nginx-to-higress-migration
Migrate from ingress-nginx to Higress in Kubernetes environments. Use when (1) analyzing existing ingress-nginx setup (2) reading nginx Ingress resources and ConfigMaps (3) installing Higress via helm with proper ingressClass (4) identifying unsupported nginx annotations (5) generating WASM plugins for nginx…