技能 incident-response-smart-fix
📦

incident-response-smart-fix

安全

使用多智能体AI编排解决生产事件

生产事件需要跨多个系统和域进行协调调查。该工作流通过经过验证的五阶段管道编排专业AI智能体，以诊断根本原因、实施修复并防止再次发生。

支持: Claude Codex Code(CC)
🥉 74 青铜
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“incident-response-smart-fix”。 用户结账页面每小时间歇超时错误超过500次

预期结果:

根本原因已识别：user_id列缺少数据库索引导致查询时间5秒。修复实施：添加索引将查询时间降至50ms，为用户画像添加Redis缓存。测试：24个单元测试，8个集成测试，全部通过。监控：配置了查询p95延迟和缓存命中率的告警。部署：金丝雀推送到5%流量并定义了中止标准。

正在使用“incident-response-smart-fix”。 TypeError Cannot read property map of undefined影响Safari iOS 14用户

预期结果:

根本原因已识别：API在无结果时返回null而非空数组。修复实施：在前端添加空值检查和类型守卫，更新后端按API契约返回空数组。测试：跨浏览器测试套件通过，包括iOS 14 Safari。预防措施：启用TypeScript严格空值检查，更新OpenAPI规范以记录数组返回类型。

安全审计

安全
v1 • 2/25/2026

Static analyzer detected 62 patterns but all are FALSE POSITIVES. The skill consists entirely of Markdown documentation files (.md) describing incident response workflows. Patterns flagged as 'external commands' are bash code blocks in documentation, not executable code. 'Windows SAM database' and 'weak crypto' references appear in example output templates, not actual implementations. No executable code, network calls, or file system operations present.

2
已扫描文件
871
分析行数
0
发现项
1
审计总数
未发现安全问题
审计者: claude

质量评分

38
架构
100
可维护性
87
内容
50
社区
100
安全
91
规范符合性

你能构建什么

生产错误调查和修复

当生产错误影响用户且需要快速诊断和解决时使用。工作流分析错误特征，通过git bisect和代码分析识别根本原因，实施修复并编写测试，在部署前验证无回归。

跨系统性能下降

当性能问题跨越多个服务或层（数据库、应用、缓存）时使用。工作流协调数据库优化器、性能工程师和DevOps专家来识别瓶颈，并通过监控实施优化。

安全漏洞修复

当安全扫描发现需要代码更改的漏洞时使用。工作流将问题路由给安全专家进行修复实施，添加安全测试，进行渗透测试验证，并记录安全改进。

试试这些提示

快速修复简单bug并基本测试 
分析此错误并实施修复：[粘贴错误消息]。运行基本测试以验证修复有效。专注于以最小更改解决 immediate 问题。
标准事件响应及完整验证 
调查此生产事件：[描述症状]。遵循四阶段工作流：(1) 分析错误追踪和日志，(2) 通过git bisect和代码分析识别根本原因，(3) 通过综合测试实施修复，(4) 运行回归套件和性能验证。包含回滚计划。
高严重性事件及预防措施 
响应此关键事件：[描述影响]。执行完整的五阶段工作流，包括长期预防。添加静态分析规则、类型系统增强、监控告警，并创建事后分析报告。配置金丝雀部署，包含成功指标和中止标准。
复杂问题的多域协调 
编排解决此跨系统问题：[描述涉及的系统]。按顺序协调智能体：[列出智能体]。在各阶段之间传递明确的上下文，包括已完成的工作、主要发现和剩余任务。验证集成点和端到端行为。

最佳实践

  • 在实施修复前务必识别根本原因 - 使用git bisect和可观测数据了解故障机制，而不仅仅是症状
  • 为高严重性事件实施预防措施 - 添加静态分析规则、类型增强和监控，以尽早检测类似问题
  • 在部署前记录回滚计划和成功指标 - 在金丝雀推广期间定义明确的中止标准并监控关键指标

避免

  • 不了解根本原因就修复症状 - 这会导致问题反复出现和技术债务
  • 为提速跳过验证阶段 - 不充分的测试会导致回归并延长平均恢复时间
  • 实施修复时没有预防措施 - 相同的漏洞模式将再次出现在其他代码位置

常见问题

如何选择适当的验证级别？
对于文档或 cosmetic 修复等低风险更改使用minimal。对于大多数生产bug使用standard。对于安全问题、性能问题或影响收入或大量用户的高影响事件使用comprehensive。
如果问题跨越多个技术域怎么办？
使用多域协调模式。按顺序安排专业智能体（例如：数据库优化器然后性能工程师然后devops故障排除者），在每个阶段之间使用上下文传递模板进行明确的上下文传递。
如何处理没有专业智能体的语言的问题？
将问题路由到通用调试器和代码审查员智能体进行分析。对于实施，使用具有类似范式的可用智能体，或根据审查阶段提供的修复设计手动实施。
此工作流能否处理需要立即行动的事件？
是的，对于热修复使用minimal验证级别和即时推广策略。首先专注于快速缓解，然后在立即影响解决后进行综合分析和预防措施的后续跟进。
需要提供哪些可观测性数据？
理想情况下提供来自Sentry或类似的错误追踪、带关联ID的相关日志、来自OpenTelemetry或Jaeger的分布式追踪，以及显示延迟和错误率趋势的APM指标。更多数据能够实现更快、更准确的根本原因识别。
如何知道事件已完全解决？
当以下条件满足时事件已解决：所有测试通过且无回归，性能基准在可接受阈值内，监控显示错误率恢复到基线，回滚计划已记录，以及预防措施到位以检测类似问题。

开发者详情

作者

sickn33

许可证

MIT

仓库

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/incident-response-smart-fix

引用

main

文件结构

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md