关于 hotfix
hotfix 是用于处理紧急生产缺陷、安全补丁和关键回归问题的工作流技能,涵盖问题调查、最小化修复与测试,直至创建 PR 并监控 CI。
主要功能
- 01确认热修复范围
- 02创建分支并调查缺陷
- 03最小化修复与回归测试
- 04针对性安全和无障碍审查
- 05创建 PR 并跟进 CI
适用场景
- 01处理生产环境故障
- 02修补安全漏洞
- 03修复关键回归问题
- 04跟踪紧急修复的 CI
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ andrewvaughan/ agent-council --skill hotfix安装后在 Claude Code 中输入/hotfix确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
agents/platform-engineer.mdqa-lead.mdsecurity-engineer.mdcouncils/deployment-council.md详细介绍
热修复工作流
通过精简流程应用紧急修复,跳过完整的规划周期。此技能适用于生产环境缺陷、安全补丁和严重回归问题。
注意
这不是功能开发的捷径。 如果变更会添加新功能、更改面向用户的行为,或涉及超过约 100 行代码,请改用
/plan-feature。热修复应当规模小、目标明确且范围清晰。
注意
范围界定:此技能会实施修复、进行审查、创建 PR 并监控 CI。它涵盖紧急修复的完整生命周期,因此用户无需串联多个技能。
第 1 步:定义修复内容
检查点:确认热修复范围
请用户描述问题。收集以下信息:
- 什么出了问题?(症状、错误消息、受影响的用户)
- 问题出在哪里?(文件、端点、组件——如果已知)
- 有多紧急?(生产环境中断、数据损坏、安全漏洞、体验降级)
- GitHub issue 编号(如果有)
如果用户提供了 GitHub issue 编号,请获取 issue:
gh issue view <number> --json title,body,labels,state,number
向用户概述问题,并请用户确认此问题适合热修复,而非功能开发。
第 2 步:创建分支并调查
-
确保当前位于
main分支且已更新至最新:git fetch origin git checkout main git pull origin main -
创建一个
fix/分支:git checkout -b fix/<short-description> -
如果存在 GitHub issue,请为其添加
in-progress标签(遵循 AGENTS.md 中的标签管理规则——先从其他 issue 中移除该标签)。 -
调查缺陷:阅读相关文件,尽可能复现问题,并找出根本原因。
继续之前,先向用户说明根本原因分析。
第 3 步:应用修复
-
只进行解决问题所需的最小改动。
-
编写或更新测试以覆盖该缺陷(回归测试)。
-
运行自检:
pnpm type-check pnpm lint pnpm test -
修复上述检查中发现的任何问题。
检查点:审查修复内容
请展示:
- 已更改的文件(简要说明每项变更)
- 新增或修改的测试
- 测试结果(通过/失败、覆盖率)
等待用户批准后再提交。
第 4 步:提交
使用约定式提交格式提交:
git add <specific-files>
git commit -m "fix(<scope>): <description>"
第 5 步:重点审查
进行轻量审查(不使用完整的 Review Council):
- 安全扫描(始终执行):对已更改的文件调用
/security-scanning:security-sast。 - 无障碍检查(如果有前端变更):对已修改的组件调用
/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
-
运行推送前检查:
pnpm type-check && pnpm lint && pnpm format:check && pnpm test如果
format:check失败,请使用pnpm format自动修复格式问题。 -
推送并创建 PR:
git push -u origin fix/<short-description> -
生成 PR 描述。如果
.github/PULL_REQUEST_TEMPLATE.md存在,请使用其中的模板。请包含:- 缺陷描述及根本原因
- 应用的修复
- 新增的测试
- 关联的 issue 编号(如适用)
检查点:PR 描述
展示 PR 标题和正文。等待用户批准。
-
创建 PR:
gh pr create --title "<title>" --body "<body>" -
监控 CI:
gh run list --branch fix/<short-description> --limit 1 --json databaseId --jq '.[0].databaseId'然后持续观察:
gh run watch <run-id> --exit-status -
如果 CI 失败,请诊断并修复。提交之前先向用户说明修复内容。
第 8 步:交接
提供已完成的热修复摘要:
- PR URL
- 更改的文件
- 新增的测试
- CI 状态
- 相关 issue(如适用)
你已完成
/hotfix。PR 已准备好合并。如果存在相关的 GitHub issue,PR 合并时会自动关闭该 issue(前提是 PR 正文中包含Closes #N)。