cx-cases

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Cases Management Skill

案例管理Skill

A Case groups related alert events into one investigation unit with a status, priority, category, and assignee. Use this skill to inspect cases and drive them through their lifecycle (active → acknowledged → resolved → closed).

案例将相关告警事件分组为一个包含状态、优先级、类别和负责人的调查单元。使用此Skill查看案例并推动其完成生命周期（活跃→已确认→已解决→已关闭）。

CLI Commands

CLI命令

Command	Purpose
`cx cases get <id>`	Get a single case by ID
`cx cases update <id> [--title] [--resolution-reason]`	Update mutable fields
`cx cases comment <id> --text <text>`	Add a comment to the case timeline
`cx cases assign <id> --user <email>`	Assign a case (email, or raw user ID)
`cx cases unassign <id>`	Remove the assignee
`cx cases acknowledge <id>`	Acknowledge (signals you're working it; stops re-notification)
`cx cases unacknowledge <id>`	Remove the acknowledgment
`cx cases resolve <id> --reason <text>`	Resolve a case (irreversible — see below)
`cx cases close <id>`	Close a case (terminal)
`cx cases set-priority <id> --priority <P1..P5>`	Override the computed priority
`cx cases clear-priority <id>`	Remove a priority override
`cx cases events list <case-id>`	Event timeline (status changes, comments, assignments)
`cx cases events get <event-id>`	A single event — drill in, e.g. to expand a comment thread
`cx cases notifications <case-id> [<case-id> ...]`	Notification deliveries (connector, status, time)

Command	Purpose
`cx cases get <id>`	通过ID获取单个案例
`cx cases update <id> [--title] [--resolution-reason]`	更新可变字段
`cx cases comment <id> --text <text>`	在案例时间线添加评论
`cx cases assign <id> --user <email>`	分配案例（邮箱或原始用户ID）
`cx cases unassign <id>`	移除负责人
`cx cases acknowledge <id>`	确认（表明你正在处理该案例；停止重复通知）
`cx cases unacknowledge <id>`	取消确认
`cx cases resolve <id> --reason <text>`	解决案例（不可逆——见下文）
`cx cases close <id>`	关闭案例（终结状态）
`cx cases set-priority <id> --priority <P1..P5>`	覆盖系统计算的优先级
`cx cases clear-priority <id>`	移除优先级覆盖设置
`cx cases events list <case-id>`	事件时间线（状态变更、评论、分配记录）
`cx cases events get <event-id>`	单个事件——深入查看，例如展开评论线程
`cx cases notifications <case-id> [<case-id> ...]`	通知交付记录（连接器、状态、时间）

Case Lifecycle

案例生命周期

PENDING_ACTIVATION ──► ACTIVE ◄────────► ACKNOWLEDGED
                         │ ╲                │ ╲
                         │  ╲               │  ╲
                         ▼   ╲              ▼   ╲
                      CLOSED  ╲──► RESOLVED ◄─── (from ACK)
                                       │
                                       ▼
                                    CLOSED  (terminal)

From state	Allowed transitions	Notes
`PENDING_ACTIVATION`	→ `ACTIVE`	System-driven activation; not user-controllable
`ACTIVE`	→ `ACKNOWLEDGED` , `RESOLVED` , `CLOSED`	Ack is optional; for a false alarm, `close` directly (skip `resolve` )
`ACKNOWLEDGED`	→ `ACTIVE` , `RESOLVED` , `CLOSED`	The only "back" transition: `unacknowledge` returns it to `ACTIVE`
`RESOLVED`	→ `CLOSED` only	Irreversible — cannot reopen to `ACTIVE` / `ACKNOWLEDGED`
`CLOSED`	(none)	Terminal

Categories:

AVAILABILITY

SECURITY

. Priorities:

P1

(highest) →

P5

PENDING_ACTIVATION ──► ACTIVE ◄────────► ACKNOWLEDGED
                         │ ╲                │ ╲
                         │  ╲               │  ╲
                         ▼   ╲              ▼   ╲
                      CLOSED  ╲──► RESOLVED ◄─── (from ACK)
                                       │
                                       ▼
                                    CLOSED  (terminal)

原状态	允许的状态转换	说明
`PENDING_ACTIVATION`	→ `ACTIVE`	系统驱动激活；不可由用户控制
`ACTIVE`	→ `ACKNOWLEDGED` , `RESOLVED` , `CLOSED`	确认是可选操作；对于误报，可直接 `close` （跳过 `resolve` ）
`ACKNOWLEDGED`	→ `ACTIVE` , `RESOLVED` , `CLOSED`	唯一的“回退”转换： `unacknowledge` 将其恢复为 `ACTIVE` 状态
`RESOLVED`	→ `CLOSED` only	不可逆——无法重新打开为 `ACTIVE` / `ACKNOWLEDGED` 状态
`CLOSED`	(none)	终结状态

类别：

AVAILABILITY

或

SECURITY

。优先级：

P1

（最高）→

P5

。

Triage Workflow

分类处理工作流

Inspect —

cx cases get <id>

. The payload includes

groupings

labels

impactedEntities

kpiBreaches

aiSummary

, and both

priorityDetails.system

(computed) and

priorityDetails.override

(user-set).

Investigate — Pull the underlying telemetry by querying the alert's DataPrime / PromQL to find root cause before acting. Optionally export the investigation via
```
cx olly
```
or pull the case's
```
impactedEntities
```
/
```
groupings
```
to confirm the impact. See the
```
cx-telemetry-querying
```
skill.

Claim —

cx cases assign <id> --user you@example.com

then

cx cases acknowledge <id>

Record findings —
```
cx cases comment <id> --text "<note>"
```
to leave investigation notes on the timeline (root cause, links, next steps) as you go. Comments appear as
```
comment
```
events in
```
cx cases events list
```
.
Resolve or close — see below.
Re-prioritize if impact differs from the computed value —
```
cx cases set-priority <id> --priority P1
```
/
```
clear-priority
```
. Only possible while the case is still open; priority cannot be overridden once a case is
```
RESOLVED
```
or
```
CLOSED
```
.

查看 —

cx cases get <id>

。返回内容包含

groupings

、

labels

、

impactedEntities

、

kpiBreaches

、

aiSummary

，以及

priorityDetails.system

（系统计算）和

priorityDetails.override

（用户设置）。

调查 — 在采取行动前，通过查询告警的DataPrime/PromQL获取底层遥测数据以找到根本原因。可选择通过
```
cx olly
```
导出调查结果，或获取案例的
```
impactedEntities
```
/
```
groupings
```
来确认影响范围。详见
```
cx-telemetry-querying
```
Skill。

认领 —

cx cases assign <id> --user you@example.com

然后执行

cx cases acknowledge <id>

。

记录发现 —
```
cx cases comment <id> --text "<note>"
```
，在时间线中留下调查笔记（根本原因、链接、下一步计划）。评论会作为
```
comment
```
事件出现在
```
cx cases events list
```
中。
解决或关闭 — 见下文。
重新设置优先级 如果影响与系统计算的优先级不符 —
```
cx cases set-priority <id> --priority P1
```
/
```
clear-priority
```
。仅在案例处于未关闭状态时可操作；一旦案例变为
```
RESOLVED
```
或
```
CLOSED
```
，则无法覆盖优先级。

Resolving

解决案例

Resolution is irreversible (a

RESOLVED

case can only move to

CLOSED

), so the CLI requires both a reason and a confirmation:

Pass
```
--reason "<text>"
```
— a one-line postmortem (root cause, what fixed it, follow-up) visible to teammates in the timeline. Use
```
--no-reason
```
only when a reason genuinely doesn't apply.
In agent / non-interactive mode, also pass
```
--yes
```
; without it the command refuses and must be handed to the user to run interactively.

If uncertain, stay in

ACKNOWLEDGED

(reversible via

unacknowledge

) until confident. For non-resolution edits (title, post-hoc postmortem link), use

cx cases update

解决操作是不可逆的（

RESOLVED

状态的案例只能转为

CLOSED

），因此CLI需要同时提供原因和确认：

传入
```
--reason "<text>"
```
— 一行事后分析（根本原因、修复措施、后续计划），团队成员可在时间线中查看。仅当确实无需原因时才使用
```
--no-reason
```
。
在代理/非交互模式下，还需传入
```
--yes
```
；否则命令会拒绝执行，必须由用户以交互方式运行。

如果不确定，保持

ACKNOWLEDGED

状态（可通过

unacknowledge

回退）直到确认。对于非解决类编辑（标题、事后分析链接），使用

cx cases update

。

Bulk Operations

批量操作

There are no bulk endpoints. To act on many cases, pipe IDs through a loop, e.g.

... | jq -r '.[].id' | xargs -I {} cx cases acknowledge {}

没有批量操作端点。要对多个案例执行操作，可通过循环传递ID，例如

... | jq -r '.[].id' | xargs -I {} cx cases acknowledge {}

。

Key Principles

核心原则

Use emails, never user IDs — for
```
assign --user
```
and in all output.
resolve
is irreversible and
close
is terminal — confirm before resolving; for false alarms
```
close
```
from
```
ACTIVE
```
directly.
Always supply a resolution reason unless
```
--no-reason
```
truly applies.
P1
-style shorthand is accepted anywhere a priority/status/category is expected.
Multi-profile fan-out with
```
-p <profile>
```
(repeatable) for cross-environment triage.

使用邮箱，而非用户ID — 在
```
assign --user
```
命令和所有输出中均遵循此原则。
resolve
不可逆，
close
是终结状态 — 解决前请确认；对于误报，直接从
```
ACTIVE
```
状态执行
```
close
```
。
始终提供解决原因，除非确实适用
```
--no-reason
```
。
P1
式简写在所有需要优先级/状态/类别的场景均被接受。
使用
```
-p <profile>
```
（可重复）实现多配置文件分发，用于跨环境分类处理。