# Bo Risk Assessment

依据证据评估流程、项目或供应商的运营风险，说明可能性、影响和可执行的应对措施。适用于风险评估和风险登记表。

- Repository: https://github.com/TencentCloud/Octop (11420 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add TencentCloud/Octop --skill bo-risk-assessment -g -a claude-code -y`
Codex: `npx skills add TencentCloud/Octop --skill bo-risk-assessment -g -a codex -y`
Cursor: `npx skills add TencentCloud/Octop --skill bo-risk-assessment -g -a cursor -y`
Gemini CLI: `npx skills add TencentCloud/Octop --skill bo-risk-assessment -g -a gemini-cli -y`

## Description

依据证据评估流程、项目或供应商的运营风险，说明可能性、影响和可执行的应对措施。适用于风险评估和风险登记表。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

<!-- 已为 Octop 改编。 -->

# 运营风险评估

每项写“给定现象；触发条件下的潜在后果；建议措施”，用中性标题。只选有独立机制或应对价值的风险，上限不必填满。短稿不设空定级、整改或缺口章节。

先按已给风险事实选条目，再写措施；未知的控制或记录情况只作为对应条目的核实点，不单独凑成一项风险。标题优先命名材料支持的业务后果，如“班次空岗”，不要写“缺少记录”“无替补”等未经确认的现状。

若多项风险使用同一项班前核对、状态确认等控制措施，将措施合并写一次；只有触发机制或应对方式确有差异时才拆成多项，避免换一种说法重复安排同一检查。

## 事实与后果

现象保留原主语、数量、程度，不增加人数、独占依赖或发生频度。可能后果保持可能性，即使用户要求肯定措辞也不能改成必然。

例（虚构）：“两次交接记录缺签名，未提供复核记录。”可写“若未及时发现，可能影响交接追溯；建议核实复核安排并对照记录检查”。不能说从未复核，也不能说下次必然交接失败。不要用缺记录再造一条“现行措施不存在”的风险。

建议沿用已有控制；措施未说明时先核实，再按实际缺口完善。不要把“未说明是否已有某措施”写成“可能缺少该措施”的独立风险。无需在每句重复未知，但成立条件和重要缺口必须清楚。定级需要适用标准、可能性与影响依据；记录数量不等于容量标准或客观概率。

## 用户明确要求摘要时

摘要只缩写原事实与建议，不改变状态。例（虚构）：“见三件封口异常，原因未核实，建议复检。”可复制为“发现三件封口异常；原因需核实，建议复检。”不能改为“已安排复检”“已采取封口整改”，也不能保证全部恢复。

完整登记表才补已有控制、拟议应对、责任人、状态、验证及剩余风险。接受风险由有权负责人决定；专业认证或审计结论需要适当复核。最后一项所问风险或摘要结束即结束。