Claude Code 插件实战用 Incident Commander 子代理构建结构化事件响应流程【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读本文围绕 claude-howto 仓库中devops-automation插件内的incident-commander子代理展开解析它的定位、frontmatter 配置与五大核心职责并结合/incident命令、配套子代理、Bash 脚本与 MCP 服务器说明如何在 Claude Code 中搭建一条从告警评估、团队协调到事后复盘post-mortem的完整事件响应链路。读完本文你将能独立理解并部署一套基于 Claude Code 子代理的线上故障处置工作流。什么是 Incident Commander 子代理在 Claude Code 的插件体系中子代理subagent是一种轻量级、可独立调度的专家角色。devops-automation插件见 插件说明打包了部署、监控与事件响应三大能力其中incident-commander专门负责统筹事件响应。它的完整定义位于 incident-commander.md整个文件非常简洁只包含一段 YAML frontmatter 和一段职责清单--- name: incident-commander description: Coordinates incident response tools: Read, Write, Bash, Grep --- # Incident Commander Manages incident response: - Severity assessment - Team coordination - Status updates - Resolution tracking - Post-mortem facilitation这份定义虽然简短却是整个事件响应工作流的指挥中枢它不负责具体的部署操作也不负责告警数据的底层解析而是把故障处置过程中的判断、协调、沟通与追踪收拢到一个可被反复调用的角色中。配置解析frontmatter 的三个关键字段子代理的行为边界完全由 frontmatter 决定incident-commander的配置有三个要点字段值作用nameincident-commander子代理的唯一标识供主线程或/incident命令按名称委派任务descriptionCoordinates incident response描述子代理擅长的工作Claude Code 据此在合适的场景自动选择它toolsRead, Write, Bash, Grep授予的工具权限恰好覆盖事件处置全流程读日志、写记录、跑诊断命令、检索代码与配置tools字段值得展开事件响应的每一步都依赖这四个工具的组合。Read用于读取告警详情、配置文件与相关文档Write用于创建事件记录、更新状态文件、起草事后复盘文档Bash用于执行诊断命令如kubectl get pods、curl健康检查Grep用于在代码库或日志目录中快速定位故障相关片段。相比插件中的 alert-analyzer仅授予Read, Grep, BashIncident Commander 多了Write这正是记录与复盘职责的体现——它不仅要读和查还要持续产出事件文档。五大核心职责详解1. 严重性评估Severity assessment事件处置的第一步是分级。Incident Commander 需要综合告警内容、影响范围、受影响用户规模等信息判断故障是 P0服务完全不可用、P1核心功能受损还是更低级别。这一判断直接决定后续的响应力度、升级路径与通知范围。2. 团队协调Team coordination分级之后是指挥调度。Incident Commander 负责确定谁来响应、是否需要升级、何时升级并把处置任务分派给合适的执行者。在插件内部它天然与 deployment-specialist负责回滚、蓝绿发布、金丝雀发布等部署操作和 alert-analyzer负责告警关联、趋势分析、根因识别形成分工Commander 判断做什么Specialist 执行怎么改Analyzer 回答为什么坏。3. 状态更新Status updates事件处置过程中状态同步至关重要。Incident Commander 需要持续把已确认、处置中、已缓解、已解决等状态更新到事件记录中确保所有相关方值班团队、管理层、业务方对当前进展有一致的认知避免重复操作与信息孤岛。4. 解决情况追踪Resolution tracking从确认故障到确认恢复Incident Commander 需要验证每个处置步骤是否真正生效。这一步通常与插件自带的脚本联动例如用 health-check.sh 检查 API 端点、数据库连通性与 Pod 就绪数用 rollback.sh 回滚到上一个可用版本再以健康检查结果确认解决这一结论是否成立从而把事件状态从处置中推进到已解决。5. 事后复盘Post-mortem facilitation故障解决不代表事件结束。Incident Commander 的最后一项职责是组织事后复盘梳理时间线什么时间发生了什么、谁在什么节点做了什么、分析根因、总结改进项并输出可归档的复盘文档。复盘文档既是团队的资产也是后续避免同类事故的依据。与 /incident 命令的协作一条完整的事件处理链路子代理不是孤立存在的devops-automation插件通过 incident.md 定义了/incident斜杠命令与 Incident Commander 形成了命令入口 → 指挥中枢 → 执行者的协作结构创建事件记录Create incident record评估严重度与影响Assess severity and impact通知值班团队Notify on-call team收集诊断信息Gather diagnostic information协调响应工作Coordinate response efforts记录解决方案Document resolution安排事后复盘Schedule post-mortem对照可以发现这七步与 Incident Commander 的五大职责几乎一一对应/incident命令定义了流程骨架Incident Commander 则是驱动这个骨架运转的指挥角色。在实际会话中用户输入/incident后Claude Code 会加载命令流程并在需要时把具体工作委派给incident-commander子代理执行。从源码结构看这条链路还串联了插件的其余组件形成一个完整的事件处置闭环诊断阶段调用 health-check.sh 检查 API、数据库与 Pod 状态由 alert-analyzer 完成告警关联与根因识别处置阶段由 deployment-specialist 执行部署或回滚操作必要时调用 rollback.sh 进行回滚验证阶段再次运行健康检查确认服务恢复复盘阶段由 Incident Commander 汇总时间线与根因产出事后复盘文档支撑事件响应的底层组件要理解 Incident Commander 为什么指挥得动这些操作需要看清插件为其准备的执行资源脚本层提供了可直接执行的处置工具deploy.sh 依次执行代码检查、测试、构建、kubectl apply部署与健康检查rollback.sh 通过kubectl rollout undo回滚到上一个修订版本并等待就绪health-check.sh 分别探测 API 端点、数据库pg_isready与 Pod 就绪数。这些脚本是 Commander 下达回滚、验证指令时背后的实际执行者。Hook 层提供了部署前后的质量闸门pre-deploy.js 在部署前校验kubectl是否安装、是否已连接集群post-deploy.js 在部署后等待 Pod 就绪并执行冒烟测试。这两道闸门让 Incident Commander 在协调处置时拥有可靠的部署是否成功判断依据。MCP 层让 Commander 具备对 Kubernetes 集群的实时感知能力。插件在 kubernetes-config.json 中注册了modelcontextprotocol/server-kubernetes通过KUBECONFIG环境变量接入集群Incident Commander 可以借此查询 Pod 状态、事件与资源使用情况为严重性评估和解决追踪提供第一手数据。如何在你的项目中落地安装插件/plugin install devops-automation安装后会获得四个斜杠命令/deploy、/rollback、/status、/incident、三个子代理deployment-specialist、incident-commander、alert-analyzer以及对应的脚本、Hook 与 Kubernetes MCP 服务器。前置条件Claude Code 2.1 及以上版本安装 Kubernetes CLIkubectl并配置集群访问export KUBECONFIG~/.kube/config触发事件响应/incident之后即可在会话中把处置工作交给 Incident Commander例如让它评估当前告警的严重级别并通知值班团队、协调回滚并验证服务恢复、生成本次故障的事后复盘文档。小结Incident Commander 是devops-automation插件中负责统筹的子代理角色它用Read, Write, Bash, Grep四个工具覆盖了事件处置的完整生命周期把严重性评估、团队协调、状态更新、解决追踪与事后复盘五件事收敛成可反复调用的能力。在与/incident命令、alert-analyzer/deployment-specialist两个兄弟子代理、三个运维脚本、两道部署 Hook 以及 Kubernetes MCP 的配合下它构成了 Claude Code 生态中一套结构清晰、可直接落地的线上故障处置工作流。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Claude Code 插件实战用 Incident Commander 子代理构建结构化事件响应流程【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读本文围绕 claude-howto 仓库中devops-automation插件内的incident-commander子代理展开解析它的定位、frontmatter 配置与五大核心职责并结合/incident命令、配套子代理、Bash 脚本与 MCP 服务器说明如何在 Claude Code 中搭建一条从告警评估、团队协调到事后复盘post-mortem的完整事件响应链路。读完本文你将能独立理解并部署一套基于 Claude Code 子代理的线上故障处置工作流。什么是 Incident Commander 子代理在 Claude Code 的插件体系中子代理subagent是一种轻量级、可独立调度的专家角色。devops-automation插件见 插件说明打包了部署、监控与事件响应三大能力其中incident-commander专门负责统筹事件响应。它的完整定义位于 incident-commander.md整个文件非常简洁只包含一段 YAML frontmatter 和一段职责清单--- name: incident-commander description: Coordinates incident response tools: Read, Write, Bash, Grep --- # Incident Commander Manages incident response: - Severity assessment - Team coordination - Status updates - Resolution tracking - Post-mortem facilitation这份定义虽然简短却是整个事件响应工作流的指挥中枢它不负责具体的部署操作也不负责告警数据的底层解析而是把故障处置过程中的判断、协调、沟通与追踪收拢到一个可被反复调用的角色中。配置解析frontmatter 的三个关键字段子代理的行为边界完全由 frontmatter 决定incident-commander的配置有三个要点字段值作用nameincident-commander子代理的唯一标识供主线程或/incident命令按名称委派任务descriptionCoordinates incident response描述子代理擅长的工作Claude Code 据此在合适的场景自动选择它toolsRead, Write, Bash, Grep授予的工具权限恰好覆盖事件处置全流程读日志、写记录、跑诊断命令、检索代码与配置tools字段值得展开事件响应的每一步都依赖这四个工具的组合。Read用于读取告警详情、配置文件与相关文档Write用于创建事件记录、更新状态文件、起草事后复盘文档Bash用于执行诊断命令如kubectl get pods、curl健康检查Grep用于在代码库或日志目录中快速定位故障相关片段。相比插件中的 alert-analyzer仅授予Read, Grep, BashIncident Commander 多了Write这正是记录与复盘职责的体现——它不仅要读和查还要持续产出事件文档。五大核心职责详解1. 严重性评估Severity assessment事件处置的第一步是分级。Incident Commander 需要综合告警内容、影响范围、受影响用户规模等信息判断故障是 P0服务完全不可用、P1核心功能受损还是更低级别。这一判断直接决定后续的响应力度、升级路径与通知范围。2. 团队协调Team coordination分级之后是指挥调度。Incident Commander 负责确定谁来响应、是否需要升级、何时升级并把处置任务分派给合适的执行者。在插件内部它天然与 deployment-specialist负责回滚、蓝绿发布、金丝雀发布等部署操作和 alert-analyzer负责告警关联、趋势分析、根因识别形成分工Commander 判断做什么Specialist 执行怎么改Analyzer 回答为什么坏。3. 状态更新Status updates事件处置过程中状态同步至关重要。Incident Commander 需要持续把已确认、处置中、已缓解、已解决等状态更新到事件记录中确保所有相关方值班团队、管理层、业务方对当前进展有一致的认知避免重复操作与信息孤岛。4. 解决情况追踪Resolution tracking从确认故障到确认恢复Incident Commander 需要验证每个处置步骤是否真正生效。这一步通常与插件自带的脚本联动例如用 health-check.sh 检查 API 端点、数据库连通性与 Pod 就绪数用 rollback.sh 回滚到上一个可用版本再以健康检查结果确认解决这一结论是否成立从而把事件状态从处置中推进到已解决。5. 事后复盘Post-mortem facilitation故障解决不代表事件结束。Incident Commander 的最后一项职责是组织事后复盘梳理时间线什么时间发生了什么、谁在什么节点做了什么、分析根因、总结改进项并输出可归档的复盘文档。复盘文档既是团队的资产也是后续避免同类事故的依据。与 /incident 命令的协作一条完整的事件处理链路子代理不是孤立存在的devops-automation插件通过 incident.md 定义了/incident斜杠命令与 Incident Commander 形成了命令入口 → 指挥中枢 → 执行者的协作结构创建事件记录Create incident record评估严重度与影响Assess severity and impact通知值班团队Notify on-call team收集诊断信息Gather diagnostic information协调响应工作Coordinate response efforts记录解决方案Document resolution安排事后复盘Schedule post-mortem对照可以发现这七步与 Incident Commander 的五大职责几乎一一对应/incident命令定义了流程骨架Incident Commander 则是驱动这个骨架运转的指挥角色。在实际会话中用户输入/incident后Claude Code 会加载命令流程并在需要时把具体工作委派给incident-commander子代理执行。从源码结构看这条链路还串联了插件的其余组件形成一个完整的事件处置闭环诊断阶段调用 health-check.sh 检查 API、数据库与 Pod 状态由 alert-analyzer 完成告警关联与根因识别处置阶段由 deployment-specialist 执行部署或回滚操作必要时调用 rollback.sh 进行回滚验证阶段再次运行健康检查确认服务恢复复盘阶段由 Incident Commander 汇总时间线与根因产出事后复盘文档支撑事件响应的底层组件要理解 Incident Commander 为什么指挥得动这些操作需要看清插件为其准备的执行资源脚本层提供了可直接执行的处置工具deploy.sh 依次执行代码检查、测试、构建、kubectl apply部署与健康检查rollback.sh 通过kubectl rollout undo回滚到上一个修订版本并等待就绪health-check.sh 分别探测 API 端点、数据库pg_isready与 Pod 就绪数。这些脚本是 Commander 下达回滚、验证指令时背后的实际执行者。Hook 层提供了部署前后的质量闸门pre-deploy.js 在部署前校验kubectl是否安装、是否已连接集群post-deploy.js 在部署后等待 Pod 就绪并执行冒烟测试。这两道闸门让 Incident Commander 在协调处置时拥有可靠的部署是否成功判断依据。MCP 层让 Commander 具备对 Kubernetes 集群的实时感知能力。插件在 kubernetes-config.json 中注册了modelcontextprotocol/server-kubernetes通过KUBECONFIG环境变量接入集群Incident Commander 可以借此查询 Pod 状态、事件与资源使用情况为严重性评估和解决追踪提供第一手数据。如何在你的项目中落地安装插件/plugin install devops-automation安装后会获得四个斜杠命令/deploy、/rollback、/status、/incident、三个子代理deployment-specialist、incident-commander、alert-analyzer以及对应的脚本、Hook 与 Kubernetes MCP 服务器。前置条件Claude Code 2.1 及以上版本安装 Kubernetes CLIkubectl并配置集群访问export KUBECONFIG~/.kube/config触发事件响应/incident之后即可在会话中把处置工作交给 Incident Commander例如让它评估当前告警的严重级别并通知值班团队、协调回滚并验证服务恢复、生成本次故障的事后复盘文档。小结Incident Commander 是devops-automation插件中负责统筹的子代理角色它用Read, Write, Bash, Grep四个工具覆盖了事件处置的完整生命周期把严重性评估、团队协调、状态更新、解决追踪与事后复盘五件事收敛成可反复调用的能力。在与/incident命令、alert-analyzer/deployment-specialist两个兄弟子代理、三个运维脚本、两道部署 Hook 以及 Kubernetes MCP 的配合下它构成了 Claude Code 生态中一套结构清晰、可直接落地的线上故障处置工作流。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
