twg-operational-health

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

twg-operational-health

twg-运营健康

Use together with the root

twg

skill. Exact command grammar comes from live

twg help

twg help describe <path>

需与根级

twg

skill配合使用。具体命令语法可通过实时的

twg help

或

twg help describe <path>

获取。

CLI launcher fallback

CLI启动器备选方案

Run

twg <command>

. On shell

command not found

, use

$HOME/.local/bin/twg

(macOS/Linux) /

$env:LOCALAPPDATA\Programs\twg\bin\twg.exe

(PowerShell), then tell user to add that directory to PATH. Do not treat auth or command errors as PATH failures.

运行

twg <command>

。若shell提示

command not found

，请使用

$HOME/.local/bin/twg

（macOS/Linux）或

$env:LOCALAPPDATA\Programs\twg\bin\twg.exe

（PowerShell），并告知用户将该目录添加至PATH。请勿将认证或命令错误视为PATH配置问题。

Use When

使用场景

"I'm taking over on-call"
"Reliability, incident, SEV, or post-incident review readout"
"Investigate an active incident and find mitigation"
"Analyze root cause or draft postmortem/PIR learning/action items"
"Open risks, blockers, overloaded people, operational health"

"我正在接手值班工作"
"可靠性、事件、严重事件（SEV）或事后复盘汇报"
"调查活跃事件并找到缓解方案"
"分析根本原因或起草事后报告（PIR）的经验总结/行动项"
"未解决的风险、障碍、人员过载、运营健康状况"

First Move

初始步骤

Resolve scope, window, anchors, owner/escalation path, status, recency, and follow-ups. Find the operational anchor before joining relevant surfaces. Run without

--site

; TWG inherits the user's pinned Jira/JSM site. Only add a site override when the user explicitly requests another tenant. Never assume a vendor-internal incident site.

明确范围、时间窗口、锚点信息、负责人/升级路径、状态、时效性以及后续跟进事项。在接入相关界面前，先找到运营锚点信息。运行命令时无需添加

--site

参数；TWG会继承用户固定的Jira/JSM站点。仅当用户明确要求其他租户时，才添加站点覆盖参数。切勿默认使用供应商内部的事件站点。

Evidence Policy

证据规则

Rank by impact, urgency, owner clarity, recurrence risk, and actionability; separate live risks from historical mentions.
Cluster compact incident, PIR, follow-up, runbook, owner, asset, or meeting evidence by service, theme, owner, and recency. Hydrate highest-risk clusters; stop once theme, owner signal, and confidence are clear.
Separate
```
working theory
```
,
```
confirmed problem
```
,
```
mitigation
```
, and
```
root cause
```
. Require a causal mechanism for confirmed root cause; a closed record is insufficient. Mark claims
```
confirmed
```
,
```
supported
```
,
```
candidate
```
, or
```
missing evidence
```
; use references for RCA details.
After one correction of a repeated backend, auth, or schema error, report the gap and use remaining evidence instead of nearby aliases or broad inventories.

按影响程度、紧急程度、负责人清晰度、复发风险和可操作性排序；区分当前风险与历史提及的风险。
按服务、主题、负责人和时效性，将事件、PIR、后续跟进、运行手册、负责人、资产或会议等相关证据进行紧凑聚类。优先处理最高风险的聚类；当主题、负责人信号和可信度明确后即可停止。
区分
```
working theory
```
（初步假设）、
```
confirmed problem
```
（已确认问题）、
```
mitigation
```
（缓解方案）和
```
root cause
```
（根本原因）。确认根本原因时需具备因果机制；仅关闭记录不足以作为依据。将结论标记为
```
confirmed
```
（已确认）、
```
supported
```
（有支持证据）、
```
candidate
```
（候选）或
```
missing evidence
```
（证据缺失）；引用相关资料说明根本原因的细节。
若重复出现后端、认证或架构错误，在纠正一次后，需报告该问题缺口，并使用剩余证据，而非相近的别名或宽泛的清单。

Recipe Cards

操作指南卡

Leadership Reliability Review / On-Call Handoff

领导力可靠性评审 / 值班交接

Load

references/reliability-review.md

. Resolve leader, platform, and window; cluster supported themes, separate cause from mitigation, connect prevention work, and rank leadership actions. For handoffs, add a first-hour checklist and escalation map.

加载

references/reliability-review.md

。明确负责人、平台和时间窗口；聚类已验证的主题，区分原因与缓解方案，关联预防工作，并排序领导力行动项。对于交接场景，需添加首小时检查清单和升级路径图。

Incident Investigation / Mitigation

事件调查 / 缓解方案

Use when the incident is active, newly mitigated, or pre-PIR. Anchor on the incident record, then pull responders, symptoms, impact, recent deploys/flags/config, topology, alert/log/metric pointers, ownership, runbooks, and similar incidents. If ticket fields are sparse, probe the four golden-signal families with bounded follow-ups. See

references/incident-investigation.md

. Output a four-signal matrix, hypotheses, confidence, next checks, and mitigation options; never call a mitigation the root cause without the causal mechanism.

适用于事件处于活跃状态、刚完成缓解或尚未进行事后复盘的场景。以事件记录为锚点，调取响应人员、症状、影响、近期部署/功能开关/配置、拓扑结构、告警/日志/指标指向、负责人、运行手册以及类似事件。若工单字段信息稀疏，可通过有限的跟进查询四类黄金信号。详见

references/incident-investigation.md

。输出四信号矩阵、假设、可信度、下一步检查以及缓解方案选项；在未明确因果机制的情况下，切勿将缓解方案等同于根本原因。

Post-Incident Root Cause / Learning

事后根本原因 / 经验总结

Use after mitigation/recovery when drafting or evaluating a postmortem/PIR. Pair the incident with the PIR, linked docs, final comms, remediation PRs, and action items; cover confirmed mitigation, causal mechanism, 5-why chain, and detection/response gaps. See

references/pir-root-cause.md

. Output root cause, contributing factors, mitigation-versus-cause, and prioritized actions.

适用于事件缓解/恢复后，起草或评估事后报告（PIR）的场景。将事件与PIR、关联文档、最终沟通内容、修复PR以及行动项配对；涵盖已确认的缓解方案、因果机制、5-why分析链以及检测/响应缺口。详见

references/pir-root-cause.md

。输出根本原因、促成因素、缓解方案与原因的区别，以及优先级排序的行动项。

Assets / Asset Refresh

资产 / 资产更新

Build contributors from project/goal/Jira/PR/doc/activity evidence. Inspect Assets schema/type metadata before AQL; join people via discovered user-like attributes such as

Calculated user

. Rank by contribution centrality plus asset risk, and report confidence and gaps. See

references/assets.md

从项目/目标/Jira/PR/文档/活动证据中构建贡献者信息。在执行AQL查询前，先检查资产的架构/类型元数据；通过发现的类用户属性（如

Calculated user

）关联人员。按贡献核心度加上资产风险进行排序，并报告可信度和缺口。详见

references/assets.md

。

Capacity / Staffing / Meetings

容量 / 人员配置 / 会议

For staffing, resolve project/topic/org and identify people by related work, ownership, review influence, docs, and project/goal involvement; check load before recommending. For meetings, query scoped recordings, preview transcripts first, fetch full transcripts only for central ones, then summarize decisions, action items, and gaps.

对于人员配置，明确项目/主题/组织，并通过相关工作、负责人身份、评审影响力、文档以及项目/目标参与情况识别人员；在推荐前需检查工作负载。对于会议，查询限定范围的录音，先预览转录文本，仅为核心会议获取完整转录文本，然后总结决策、行动项和缺口。

Output Shape

输出格式

Lead with severity, urgency, or recommendation, then owner, status, recency, impact, confidence, and evidence.
For active investigations, add a four-signal evidence matrix and an incident-to-learning timeline with confirmed problem, mitigation, root-cause status, and prevention action.
Group patterns across artifacts, give ranked next actions with a suggested owner, and call out data gaps (missing transcripts, no asset match, stale update, ACL/auth gaps, weak ownership).

先列出严重程度、紧急程度或建议，然后是负责人、状态、时效性、影响、可信度和证据。
对于活跃调查，添加四信号证据矩阵以及事件到经验总结的时间线，包含已确认问题、缓解方案、根本原因状态和预防行动。
汇总各工件中的模式，给出带建议负责人的优先级排序下一步行动，并指出数据缺口（缺失转录文本、无资产匹配、更新过时、ACL/认证缺口、负责人不明确）。

Anti-Patterns

反模式

Do not fetch every transcript or page body, or treat every incident mention as a live risk.
Do not wait for chat/comments to label RCA before surfacing directional hypotheses for pre-PIR investigation.
Do not call mitigation root cause without an established mechanism. Do not treat workflow panels, bot comments, or opaque fields as RCA narrative.
Do not use keyword matches alone as org ownership — cross-check assignee, service owner, PIR participants, or org-tree membership.
Do not join Assets by display-name guesses before inspecting schema/type fields, or recommend staffing from activity counts alone.

请勿调取所有转录文本或页面内容，也勿将所有事件提及视为当前风险。
在事后复盘前的调查阶段，无需等待聊天/评论标注根本原因，即可提出方向性假设。
在未明确机制的情况下，切勿将缓解方案等同于根本原因。请勿将工作流面板、机器人评论或不透明字段视为根本原因说明。
请勿仅通过关键词匹配确定组织负责人——需交叉核对经办人、服务负责人、PIR参与者或组织架构成员身份。
在检查架构/类型字段前，请勿通过显示名称猜测关联资产；也勿仅根据活动次数推荐人员配置。

References

参考资料

```
references/assets.md
```
- schema-first Assets queries and person/device joins
```
references/reliability-review.md
```
- bounded incident/PIR leadership review
```
references/incident-investigation.md
```
- active investigation and mitigation
```
references/pir-root-cause.md
```
- post-mitigation root-cause and PIR workflow

```
references/assets.md
```
- 基于架构的资产查询以及人员/设备关联方法
```
references/reliability-review.md
```
- 有限范围的事件/PIR领导力评审
```
references/incident-investigation.md
```
- 活跃事件调查与缓解方案
```
references/pir-root-cause.md
```
- 缓解后的根本原因分析与PIR工作流