mcpField
H
hotfix

hotfix

github.com/andrewvaughan开发1596 次安装35 周前更新
代码仓库

关于 hotfix

hotfix 是用于处理紧急生产缺陷、安全补丁和关键回归问题的工作流技能,涵盖问题调查、最小化修复与测试,直至创建 PR 并监控 CI。

主要功能

  1. 01确认热修复范围
  2. 02创建分支并调查缺陷
  3. 03最小化修复与回归测试
  4. 04针对性安全和无障碍审查
  5. 05创建 PR 并跟进 CI

适用场景

  1. 01处理生产环境故障
  2. 02修补安全漏洞
  3. 03修复关键回归问题
  4. 04跟踪紧急修复的 CI

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/andrewvaughan/agent-council --skill hotfix

安装后在 Claude Code 中输入/hotfix确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
platform-engineer.md
qa-lead.md
security-engineer.md
councils/
deployment-council.md

详细介绍

热修复工作流

通过精简流程应用紧急修复,跳过完整的规划周期。此技能适用于生产环境缺陷、安全补丁和严重回归问题。

注意

这不是功能开发的捷径。 如果变更会添加新功能、更改面向用户的行为,或涉及超过约 100 行代码,请改用 /plan-feature。热修复应当规模小、目标明确且范围清晰。

注意

范围界定:此技能会实施修复、进行审查、创建 PR 并监控 CI。它涵盖紧急修复的完整生命周期,因此用户无需串联多个技能。

第 1 步:定义修复内容

检查点:确认热修复范围

请用户描述问题。收集以下信息:

  1. 什么出了问题?(症状、错误消息、受影响的用户)
  2. 问题出在哪里?(文件、端点、组件——如果已知)
  3. 有多紧急?(生产环境中断、数据损坏、安全漏洞、体验降级)
  4. GitHub issue 编号(如果有)

如果用户提供了 GitHub issue 编号,请获取 issue:

gh issue view <number> --json title,body,labels,state,number

向用户概述问题,并请用户确认此问题适合热修复,而非功能开发。

第 2 步:创建分支并调查

  1. 确保当前位于 main 分支且已更新至最新:

    git fetch origin
    git checkout main
    git pull origin main
    
  2. 创建一个 fix/ 分支:

    git checkout -b fix/<short-description>
    
  3. 如果存在 GitHub issue,请为其添加 in-progress 标签(遵循 AGENTS.md 中的标签管理规则——先从其他 issue 中移除该标签)。

  4. 调查缺陷:阅读相关文件,尽可能复现问题,并找出根本原因。

继续之前,先向用户说明根本原因分析。

第 3 步:应用修复

  1. 只进行解决问题所需的最小改动。

  2. 编写或更新测试以覆盖该缺陷(回归测试)。

  3. 运行自检:

    pnpm type-check
    pnpm lint
    pnpm test
    
  4. 修复上述检查中发现的任何问题。

检查点:审查修复内容

请展示:

  • 已更改的文件(简要说明每项变更)
  • 新增或修改的测试
  • 测试结果(通过/失败、覆盖率)

等待用户批准后再提交。

第 4 步:提交

使用约定式提交格式提交:

git add <specific-files>
git commit -m "fix(<scope>): <description>"

第 5 步:重点审查

进行轻量审查(不使用完整的 Review Council):

  1. 安全扫描(始终执行):对已更改的文件调用 /security-scanning:security-sast。
  2. 无障碍检查(如果有前端变更):对已修改的组件调用 /ui-design:accessibility-audit。

如果安全扫描在已更改的文件中发现严重或高危问题,请告知用户。继续之前,修复所有合理的问题。

第 6 步:部署委员会(有条件启用)

仅当修复涉及以下内容时,才启用 Deployment Council:

  • 数据库迁移
  • Docker 或基础设施变更
  • 环境变量修改
  • 身份验证或授权代码

如果均不涉及,请跳至第 7 步。

如果已启用,请根据 .claude/councils/deployment-council.md,由全部 3 名成员(Platform Engineer、Security Engineer、QA Lead)进行 Deployment Council 评估。

检查点:部署就绪情况

展示 Deployment Council 的评估结论。等待用户批准。

第 7 步:创建 PR 并监控 CI

  1. 运行推送前检查:

    pnpm type-check && pnpm lint && pnpm format:check && pnpm test
    

    如果 format:check 失败,请使用 pnpm format 自动修复格式问题。

  2. 推送并创建 PR:

    git push -u origin fix/<short-description>
    
  3. 生成 PR 描述。如果 .github/PULL_REQUEST_TEMPLATE.md 存在,请使用其中的模板。请包含:

    • 缺陷描述及根本原因
    • 应用的修复
    • 新增的测试
    • 关联的 issue 编号(如适用)
检查点:PR 描述

展示 PR 标题和正文。等待用户批准。

  1. 创建 PR:

    gh pr create --title "<title>" --body "<body>"
    
  2. 监控 CI:

    gh run list --branch fix/<short-description> --limit 1 --json databaseId --jq '.[0].databaseId'
    

    然后持续观察:

    gh run watch <run-id> --exit-status
    
  3. 如果 CI 失败,请诊断并修复。提交之前先向用户说明修复内容。

第 8 步:交接

提供已完成的热修复摘要:

  • PR URL
  • 更改的文件
  • 新增的测试
  • CI 状态
  • 相关 issue(如适用)

你已完成 /hotfix。PR 已准备好合并。如果存在相关的 GitHub issue,PR 合并时会自动关闭该 issue(前提是 PR 正文中包含 Closes #N)。

评论

支持 Markdown