技能 incident-responder
📦
incident-responder
内容修订 r2 安全 ⚙️ 外部命令
更快解决生产事故
生产事故需要快速分诊、明确角色和准确沟通。此技能为 SRE 团队提供结构化响应步骤、恢复检查和事故后改进指导。
支持: Claude Codex Code(CC)
使用我的智能体安装
将此请求复制给你的智能体，其中包含权威 Skill 页面和清单。
智能体请求
Review the Skillstore skill "incident-responder" from https://skillstore.io/skills/sickn33-incident-responder.md and its manifest at https://skillstore.io/api/skills/sickn33-incident-responder/manifest. Verify the artifact. You may proceed after verification, subject to the environment's own policy.你的智能体仍应展示其计划，并按安全策略请求必要确认。
Agent 可读资源
当 AI Agent、爬虫或脚本需要干净上下文，而不是读取完整页面时，请使用这些链接。
测试它
正在使用“incident-responder”。 某个结账服务在部署后出现 12% 的错误率。
预期结果:
如果许多用户无法完成购买，可能的严重性为 P1。回滚或禁用有风险的变更，分配事故角色，并验证结账成功率。
正在使用“incident-responder”。 为三个区域的延迟峰值创建首批行动。
预期结果:
- 指定事故指挥官和沟通负责人。
- 在明确回滚安全性之前冻结有风险的部署。
- 比较上一个部署窗口内的错误率、延迟和饱和度。
- 每 30 分钟发布一次面向客户的更新，直到服务稳定。
正在使用“incident-responder”。 总结事故后复盘应记录哪些内容。
预期结果:
- 记录响应期间的时间线、客户影响和所做决策。
- 识别促成问题的系统因素，而不归责于个人。
- 创建有负责人的行动项，用于预防、检测和响应改进。
安全审计
安全v5 • 2026/7/24 打开版本化报告
All three static findings are false positives caused by Markdown formatting and ordinary descriptions of SRE incident response. The skill contains guidance only, with no executable commands, system reconnaissance, or prompt injection evidence.
1
已扫描文件
215
分析行数
0
复核项
0
已忽略误报
风险因素
⚙️ 外部命令 (1)
最新一次完成的静态与语义审计未检测到已确认的安全发现。这并不能证明该 Skill 没有副作用。
审计者: codex 查看审计历史 →
分享与引用此报告
分享版本化评估报告、中性徽章、嵌入卡片和引用。Skillstore 只报告证据，不判断该 Skill 是否安全。
复制报告链接
https://skillstore.io/skills/sickn33-incident-responder/audits/5?utm_source=security_passport&utm_medium=share&utm_campaign=versioned_reportMarkdown 徽章
[](https://skillstore.io/skills/sickn33-incident-responder?utm_source=security_passport_badge)HTML 徽章
<a href="https://skillstore.io/skills/sickn33-incident-responder?utm_source=security_passport_badge"><img src="https://skillstore.io/badges/skills/sickn33-incident-responder/security.svg" alt="Skillstore security assessment" loading="lazy"></a>嵌入卡片
<iframe src="https://skillstore.io/embed/skills/sickn33-incident-responder.html" title="Skillstore Security Assessment" sandbox="allow-popups allow-popups-to-escape-sandbox" loading="lazy" referrerpolicy="no-referrer" width="420" height="180"></iframe>学术引用 (APA · BibTeX · CFF)
APA 引用
sickn33. (2026). incident-responder security audit report (audit version 5) [Author version unspecified]. Skillstore. https://skillstore.io/skills/sickn33-incident-responder/audits/5BibTeX 引用
@techreport{sickn33-sickn33-incident-responder-2026,
author = {sickn33},
title = {incident-responder security audit report (audit version 5)},
institution = {Skillstore},
year = {2026},
number = {5},
url = {https://skillstore.io/skills/sickn33-incident-responder/audits/5},
note = {Author version unspecified}
}CITATION.cff
cff-version: 1.2.0
message: "If you use this Skill, cite its author and this versioned security audit report."
title: "incident-responder security audit report (audit version 5)"
version: "unspecified"
type: report
authors:
- name: "sickn33"
date-released: "2026-07-24"
url: "https://skillstore.io/skills/sickn33-incident-responder/audits/5"
identifiers:
- type: other
value: "skillstore:sickn33-incident-responder:audit:5"
description: "Skillstore immutable audit report identifier"
Skillstore 评分
评分依据 证据置信度: 高 55
架构
85
可维护性
87
内容
69
社区
83
规范符合性
你能构建什么
分诊生产故障
对故障进行分诊，分类严重性，识别可能原因，并选择最安全的首批行动。
协调实时事故
在实时事故期间设置角色、协调更新、跟踪决策，并让利益相关方保持一致。
恢复后提升可靠性
将事故数据转化为无责复盘、行动项和可靠性改进。
试试这些提示
分类事故
帮助我分类此事故。服务：[service]。症状：[symptoms]。用户影响：[impact]。近期变更：[changes]。当前指标：[metrics]。
创建响应计划
为影响 [service] 的 P1 事故创建响应计划。包括角色、首批行动、沟通节奏、验证检查和升级点。
指导实时调查
指导针对 [service] 的实时调查。使用这些信号：[metrics]、[logs]、[traces]、[deployments] 和 [dependencies]。优先考虑可逆操作。
制定事故后改进
为 [incident] 准备事故后复盘。包括时间线、影响、促成因素、后续行动、负责人、截止日期和 SLO 经验教训。
最佳实践
- 在深入根因分析之前，先关注用户影响、严重性和回滚安全性。
- 保留带日期的时间线，记录行动、决策、负责人和观察到的系统变化。
- 使用 SLI、客户体验信号和依赖项健康检查来验证恢复。
避免
- 在确认回滚路径和影响范围之前，不要执行大范围变更。
- 不要等到完全明确根因后才向利益相关方更新。
- 不要将事后复盘当作归责活动或工单列表。
常见问题
此技能可以管理实时生产事故吗？
它可以指导分诊、角色分配、沟通、调查、恢复和文档记录。人工事故指挥官仍然负责决策。
它会连接到 PagerDuty、Datadog 或 Slack 吗？
不能。它提供响应指导和检查清单，但不会与外部工具集成。
我应该先提供哪些信息？
请提供受影响的服务、用户影响、近期变更、关键指标、日志、追踪和当前缓解步骤。
它可以帮助编写客户更新吗？
可以。它可以起草状态更新，包括影响、缓解进展、下次更新时间和恢复确认。
它只适用于 SRE 团队吗？
不是。它适用于平台团队、应用团队、支持负责人和工程经理在事故期间使用。
它可以执行根因分析吗？
它可以在恢复后组织分析。它需要准确的时间线、系统上下文和响应过程中的证据。