关于 incident-status-page-ops-review
该技能将事故状态页、公开沟通和通知相关问题整理为包含责任人、门槛、指标与恢复路径的运营方案。适用于负责事件沟通和状态页运营的团队。
主要功能
- 01识别事件影响与沟通责任
- 02分类状态页事件类型
- 03制定组件与更新规则
- 04生成决策表和事件演练计划
适用场景
- 01规划服务中断期间的状态页更新
- 02协调支持团队与订阅者通知
- 03设计事故复盘和后续跟进
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/incident-status-page-ops-review确认已加载。
附带文件agents/openai.yamlreferences/incident-status-page-ops-patterns.md
详细介绍
事件状态页运营审查
使用此技能，将事件状态页、公开沟通、订阅者通知、维护、组件和事件后问题转化为具体产物，并明确负责人、关卡、指标和恢复路径。
工作流
- 确定产品组件、客户细分群体、事件严重程度、检测来源、SLO／客户影响、沟通负责人、支持负载、法律／安全限制，以及当前状态页存在的差距。
- 阅读
references/incident-status-page-ops-patterns.md。 - 将沟通分类为调查中、已确认、监控中、已解决、计划维护、性能下降、部分中断、涉及安全事项或事件后跟进。
- 明确组件分类体系、声明阈值、更新频率、模板、审批流程、订阅者渠道、支持协调，以及历史记录／事后分析关联方式。
- 产出状态页运营计划、状态机、决策表、事件架构、沟通检查清单和事件演练计划。
不适用情形
- 如果基础模型无需此技能的特定产物规范即可处理一般性建议，请勿使用。
防护措施
- 在根本原因完全明朗前，不要延迟向客户确认事件。
- 不要通过隐瞒性能下降的组件、区域影响或部分中断来夸大正常运行时间。
- 未经批准，不要发布敏感安全细节、客户数据或推测性的根本原因。
- 不要让支持团队、状态页、应用内横幅、销售团队和客户团队发送相互矛盾的事件消息。
输出格式
Status-page context:
Audience / source of truth / risk boundary:
Incident communication plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |
Components, updates, subscribers, and follow-up:
- <trigger> -> <policy, metric, edge case, support note>
评论
支持 Markdown