/ops-inspector

name: ops-inspector
description: AIOps-style one-click inspection skill for CloudBase resources. Use this skill when users need to diagnose errors, check resource health, inspect logs, or run a comprehensive health check across cloud functions, CloudRun services, databases, and other CloudBase resources.
version: 2.26.0
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.

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

• 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
• 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.

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.

Minimal checklist

• [ ] Environment is bound and accessible (`envQuery(action="info")`)
• [ ] CLS log service is enabled (`queryLogs(action="checkLogService")`)
• [ ] All target resources are listed before diving into details
• [ ] Time range is specified for any log searches
• [ ] Findings are summarized with severity levels and actionable recommendations

---

How to use this skill (for a coding agent)

Inspection Modes

The skill supports two modes based on user intent:

| Mode | When to use | Scope | |------|-------------|-------| | **Full inspection** | User asks for a general health check / 巡检 / 全面检查 | All resource types in the environment | | **Targeted inspection** | User reports a specific error or asks about a specific resource | One resource type or a specific resource |

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 — Log Service Status**

queryLogs(action="checkLogService")

If CLS is not enabled, note this as a **warning** — log-based diagnosis will be unavailable. Recommend enabling CLS in the console: `https://tcb.cloud.tencent.com/dev?envId=${envId}#/devops/log`

**Step 3 — Cloud Functions Inspection**

queryFunctions(action="listFunctions")

For each function, check:

• **Status**: Is the function in an active/deployed state?
• **Recent errors**: `queryFunctions(action="listFunctionLogs", functionName="<name>", startTime="<recent>")`
• **Common issues**:
• Timeout errors (execution exceeded limit)
• Memory limit exceeded
• Runtime errors (unhandled exceptions)
• Cold start frequency

**Step 4 — CloudRun Services Inspection**

queryCloudRun(action="list")

For each service, check:

• **Status**: Is the service running?
• **Detail**: `queryCloudRun(action="detail", detailServerName="<name>")`
• **Common issues**:
• Service not running (scaled to zero or crashed)
• Image pull failures
• OOMKilled events
• Health check failures

**Step 5 — Error Log Aggregation** (if CLS is enabled)

queryLogs(action="searchLogs", queryString="ERROR", service="tcb", startTime="<24h-ago>", limit=50)
queryLogs(action="searchLogs", queryString="ERROR", service="tcbr", startTime="<24h-ago>", limit=50)

Look for patterns:

• Repeated error messages (same error many times)
• Cascading failures (errors in multiple services around the same time)
• Timeout patterns

**Step 6 — Summary Report**

Generate a structured report:

# CloudBase Resource Inspection Report

**Environment**: ${envId}
**Inspection Time**: ${timestamp}

## Overall Health: ✅ Healthy / ⚠️ Warnings Found / ❌ Issues Found

### Cloud Functions
| Function | Status | Recent Errors | Severity |
|----------|--------|---------------|----------|
| ... | ... | ... | ... |

### CloudRun Services
| Service | Status | Issues | Severity |
|---------|--------|--------|----------|
| ... | ... | ... | ... |

### Error Log Summary
- Total errors in last 24h: N
- Top error patterns: ...

## Recommendations
1. ...
2. .