菜单
Use when a user asks to inspect, health-check, patrol/巡检, diagnose, or troubleshoot a Kubernetes cluster managed by the DCE/kpanda module. Covers cluster health overview, node status, abnormal Pods, events, cluster unavailability, node NotReady, pending or failed Pods, and Chinese requests like 集群巡检、集群体检、检查集群健康状态、排查集群异常、查看集群状态.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when operating the dce generated CLI. Discover commands, inspect parameters, check auth state, and execute API operations safely.
Generate a Chinese daily GPU operations snapshot for system resource utilization, idle headroom, and the trade-off between higher utilization and elastic buffer. Use for requests containing 今日系统运维摘要, 系统资源利用率, 空闲余量, GPU利用率, 资源利用效率, or 弹性缓冲. Query only the Crane API endpoint /apis/crane.io/v1alpha1/singlepage/gpu-resource-status through its DCE command.
Query Crane for model cost and revenue over the most recent N complete calendar days and produce a chart-first operations summary. Use for model cost, model revenue, model gross profit, and recent-N-day model finance requests. Default N is 3. Chinese trigger keywords: 模型成本、模型收入、模型毛利、最近N天模型经营数据. Use only Crane-backed business-cockpit queries; never call other DCE modules.
Query recent Token costs for users or tenants through Crane, rank the top M entries by cost, and produce an operational report with a chart. Trigger this skill for requests containing Chinese keywords such as “Token 费用排名”, “费用 Top 用户”, or “最近几天费用最高用户”. N defaults to 3 and M defaults to 5. This skill only ranks costs; it does not split results by model or perform write operations.
Generate a concise leadership-facing AI operations daily summary and business-value analysis from DaoCloud Enterprise DCE / LLM Studio / Hydra data. Use when the user asks for today's AI operations summary, AI usage report, LLM Studio operating metrics, boss/leadership AI daily report, token/API key/model service overview, business value, operating value, risk identification, or wants available DCE CLI data turned into the most important conclusions, especially in table form.
Diagnose OpenClaw request failures or slow requests with DCE Insight tracing, alerts, logs, and pod status. Use when the user asks for OpenClaw request root-cause analysis, R.E.D analysis, error-chain details, or mitigation advice.
基于 SOC 职业分类
| name | container-management:cluster-diagnosis |
| description | Use when a user asks to inspect, health-check, patrol/巡检, diagnose, or troubleshoot a Kubernetes cluster managed by the DCE/kpanda module. Covers cluster health overview, node status, abnormal Pods, events, cluster unavailability, node NotReady, pending or failed Pods, and Chinese requests like 集群巡检、集群体检、检查集群健康状态、排查集群异常、查看集群状态. |
Diagnose cluster health through a standardized 4-step inspection workflow.
REQUIRED SUB-SKILL: Use dce for all command execution, auth checks, and catalog discovery.
dce container-management cluster get-cluster --name <cluster> -o jsondce container-management core list-nodes --cluster <cluster> -o jsondce container-management core list-pods --cluster <cluster> -o jsondce container-management core list-cluster-events --cluster <cluster> -o jsondce container-management core get-pod --cluster <cluster> --namespace <ns> --name <pod> -o jsonRun dce container-management cluster list-clusters -o json, present list, ask user to pick one.
Stop and instruct user to run dce auth login --hostname <host>.
Present the final answer as structured Markdown. Do not include a step-by-step tool execution log, skill loading details, API retry details, JSON parsing details, or other internal process unless the user explicitly asks for them. If data is incomplete, explicitly say that the judgment is based on currently available data in the conclusion.
Use these top-level sections in this order. Treat the template as the report spine, not as a limit on evidence: preserve domain-specific tables and details inside the matching sections when they are needed to support the conclusion.
Use 1-2 sentences to state the current judgment, risk level
(normal / watch / risk / critical), and the most important issue.
For user-facing answers, localize the section title and risk labels to the
user's language.
Start with a Markdown summary table with 3-6 key indicators. Prefer these fields when available: cluster status, node Ready ratio, NotReady/Cordoned node count, abnormal Pod count, warning event count, and top affected namespace.
| Metric | Current Value | Status |
|---|---|---|
| Cluster status | <value> | <normal/watch/risk/critical> |
If the cluster has meaningful abnormalities, include supporting detail tables under this section, such as:
Node | Ready | Schedulable | Pressure | Key conditionNamespace | Phase/Reason | Count | ImpactType | Reason | Object | Last seen | ImpactUse a numbered list with 2-3 findings. Each finding must explain the impact. Do not collapse multiple independent cluster risks into one generic finding; if nodes, Pods, and events point to different risks, keep them distinct.
Analyze 2-3 causes around the main findings. For each cause, include:
Cause N: <cause>
Evidence: <specific event, node state, pod state, or metric>.
Impact: <user-visible or operational impact>.
Group concrete actions by:
Provide 2-3 copyable follow-up questions in the user's language. They should guide the user toward deeper root-cause analysis, remediation planning, or an exportable stakeholder report.
-o json for machine-readable output.dce commands show before executing unfamiliar commands.