/ops-inspector

name: ops-inspector
description: AIOps-style CloudBase inspection skill (v3). Use when users need health checks, log diagnosis, alarm interpretation (CPU alert normal?, peak QPS), metrics via queryEnv(action=metrics), or fault playbooks for 429 / function 404 / ACCESS_TOKEN_INVALID / zero invocations. Triggers on 巡检, 诊断, 告警, 峰值 QPS, 限频, 调用量为 0, troubleshooting.
version: 2.34.3
alwaysApply: false

Sibling skills (local only)

Sibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.

If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.

Activation Contract

Use this first when

• The user wants to check the health or status of CloudBase resources (cloud functions, CloudRun, databases, storage, etc.).
• The user reports errors, failures, or abnormal behavior and wants a quick diagnosis.
• The user asks for an "inspection", "health check", "巡检", "诊断", or "troubleshooting" of their CloudBase environment.
• The user wants to review recent error logs across services.
• The user asks **告警解读** questions: whether a **CPU 告警** is normal, what **峰值 QPS** was, or whether throttle/error metrics look healthy.
• The symptom matches a v3 fault playbook: **429 / 限频**, **云函数 404**, **ACCESS_TOKEN_INVALID**, or **调用量为 0**.

Read before writing code if

• The inspection reveals code-level issues in cloud functions or CloudRun services — then read the relevant implementation skill before suggesting fixes.
• The user wants to fix a problem found during inspection rather than just diagnose it.

Then also read

• Alarm interpretation baselines -> `references/alarm-interpretation.md`
• Fault playbooks (429 / 404 / token / zero calls) -> `references/fault-playbooks.md`
• Cloud function issues -> `../cloud-functions/SKILL.md`
• CloudRun issues -> `../cloudrun-development/SKILL.md`
• Database issues -> `../postgresql-development-cloudbase/SKILL.md` for CloudBase PG / PostgreSQL, `../relational-database-mcp-cloudbase/SKILL.md` for MySQL, or `../cloudbase-document-database-web-sdk/SKILL.md` for NoSQL
• Auth readiness (token failures) -> `../auth-tool-cloudbase/SKILL.md`
• Platform overview -> `../cloudbase-platform/SKILL.md`

Do NOT use for

• Deploying new resources or writing application code. This skill is read-only and diagnostic.
• Replacing proper monitoring/alerting infrastructure. It provides point-in-time inspection, not continuous monitoring.
• Directly fixing problems — it diagnoses and recommends; actual fixes should use the appropriate implementation skill.
• Fetching metrics by guessing cloud API Actions. **Never** use `callCloudApi` for monitor curves — always use `queryEnv(action="metrics")`.

Common mistakes / gotchas

• Running a full inspection without first confirming the environment is bound (`auth` tool must show logged-in and env-bound state).
• Ignoring CLS log service status — if CLS is not enabled, `queryLogs` will fail; always check first with `queryLogs(action="checkLogService")`.
• Searching logs without a time range — this can return excessive or irrelevant results. Always scope searches to a relevant time window.
• Treating a single error log as the root cause without correlating across resources. A function error may stem from a database or config issue.
• Answering "峰值 QPS" / "CPU 告警是否正常" from screenshots or memory instead of `queryEnv(action="metrics")`.
• Calling `callCloudApi` with invented `GetMonitorData` / `DescribeCurveData` parameters — the metrics branch already wraps Manager SDK.

Minimal checklist

• [ ] Environment is bound and accessible (`envQuery(action="info")`)
• [ ] Metrics pulled with `queryEnv(action="metrics")` when the question involves QPS / CPU / throttle / invocation volume
• [ ] CLS log service is enabled (`queryLogs(action="checkLogService")`) when log diagnosis is needed
• [ ] Matching fault playbook selected when symptoms match 429 / function 404 / ACCESS_TOKEN_INVALID / 调用量为 0
• [ ] Time range is specified for any log or metrics searches
• [ ] Findings are summarized with severity levels, **告警解读**, and actionable recommendations

---

How to use this skill (for a coding agent)

Ops Inspector v3 additions

v3 adds two mandatory capabilities on top of log/resource inspection:

1. **告警解读** — pull metrics, compare to baselines in `references/alarm-interpretation.md`, answer CPU-alert / peak-QPS style questions in plain language. 2. **故障剧本** — when symptoms match, follow `references/fault-playbooks.md` instead of ad-hoc tool fishing.

Inspection Modes

| Mode | When to use | Scope | |------|-------------|-------| | **Full inspection** | User asks for a general health check / 巡检 / 全面检查 | All resource types + core metrics | | **Targeted inspection** | User reports a specific error or asks about a specific resource | One resource type or playbook | | **Alarm interpretation** | User asks CPU 告警是否正常 / 峰值 QPS / 是否限流 | Metrics-first, then logs | | **Fault playbook** | 429 / function 404 / ACCESS_TOKEN_INVALID / 调用量为 0 | Playbook steps only |

Full Inspection Workflow

Follow these steps in order for a comprehensive environment health check:

**Step 1 — Environment Check**

envQuery(action="info")

Confirm the environment is accessible. Record the `envId` for console link generation.

**Step 2 — Metrics snapshot (v3)**

queryEnv(action="metrics", envId="<EnvId>", metricName="GatewayTraceEnvQPS")
queryEnv(action="metrics", envId="<EnvId>", metricName="FunctionInvocation")
queryEnv(action="metrics", envId="<EnvId>", metricName="MysqlCpuUsageRate")

Use returned `Summary.max` / `avg` / `allZero` / `peakTimestamp`. Add `FunctionError`, `FunctionThrottle`, or CloudRun `Tke*` metrics when those resources exist. Read `references/alarm-interpretation.md` before concluding.

**Step 3