hotfix

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Hotfix Workflow

热修复工作流

Apply an urgent fix through a streamlined pipeline that skips the full planning cycle. This skill is for production bugs, security patches, and critical regressions.

[!CAUTION] This is NOT a shortcut for feature work. If the change adds new functionality, changes user-facing behavior, or touches more than ~100 lines, use
/plan-feature
instead. Hotfixes should be small, focused, and clearly scoped.

[!CAUTION] Scope boundary: This skill implements the fix, reviews it, creates a PR, and monitors CI. It covers the full lifecycle for urgent fixes so the user does not need to chain multiple skills.

通过跳过完整规划周期的简化流程应用紧急修复。该流程适用于生产环境漏洞、安全补丁和严重回归问题。

[!CAUTION] **这不是功能开发的捷径。**如果变更添加了新功能、修改了用户可见行为，或涉及代码量超过约100行，请使用
/plan-feature
替代。热修复应规模小、目标明确且范围清晰。

[!CAUTION] 范围边界：该流程负责实现修复、评审、创建PR并监控CI。它覆盖了紧急修复的完整生命周期，因此用户无需串联使用多个流程。

Step 1: Define the Fix

步骤1：定义修复内容

CHECKPOINT: Confirm Hotfix Scope

检查点：确认热修复范围

Ask the user to describe the issue. Gather:

What is broken? (symptom, error message, affected users)
Where is the bug? (file, endpoint, component — if known)
How urgent? (production down, data corruption, security vulnerability, degraded experience)
GitHub issue number (if one exists)

If the user provides a GitHub issue number, fetch it:

bash

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

Present a summary and ask the user to confirm this is appropriate for hotfix (not a feature).

请用户描述问题，收集以下信息：

哪里出现了问题？（症状、错误信息、受影响用户）
漏洞位置？（文件、端点、组件——如果已知）
紧急程度？（生产环境宕机、数据损坏、安全漏洞、体验下降）
GitHub问题编号（如果存在）

如果用户提供了GitHub问题编号，执行以下命令获取详情：

bash

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

呈现摘要并请用户确认该问题适合热修复（而非功能开发）。

Step 2: Create Branch and Investigate

步骤2：创建分支并排查问题

Ensure you are on

main

and up to date:

bash

git fetch origin
git checkout main
git pull origin main

Create a

fix/

branch:

bash

git checkout -b fix/<short-description>

If a GitHub issue exists, add the
```
in-progress
```
label (following AGENTS.md label management rules — remove from any other issue first).
Investigate the bug: read relevant files, reproduce the issue if possible, identify the root cause.

Present the root cause analysis to the user before proceeding.

确保当前处于

main

分支且代码为最新版本：

bash

git fetch origin
git checkout main
git pull origin main

创建
```
fix/
```
分支：
bash
```
git checkout -b fix/<简短描述>
```
如果存在对应的GitHub问题，添加
```
in-progress
```
标签（遵循AGENTS.md中的标签管理规则——先从其他相关问题中移除该标签）。
排查漏洞：阅读相关文件、尽可能复现问题、确定根本原因。

在继续下一步前，向用户呈现根本原因分析结果。

Step 3: Apply the Fix

步骤3：应用修复

Make the minimal change needed to resolve the issue.
Write or update tests to cover the bug (regression test).
Run self-checks:
bash
```
pnpm type-check
pnpm lint
pnpm test
```
Fix any failures from the checks above.

仅做出解决问题所需的最小变更。
编写或更新测试以覆盖该漏洞（回归测试）。
执行自检：
bash
```
pnpm type-check
pnpm lint
pnpm test
```
修复上述检查中出现的所有失败项。

CHECKPOINT: Review the Fix

检查点：评审修复内容

Present:

Files changed (with a brief description of each change)
Tests added or modified
Test results (pass/fail, coverage)

Wait for user approval before committing.

呈现以下信息：

变更的文件（附带每个变更的简要说明）
添加或修改的测试
测试结果（通过/失败、覆盖率）

等待用户批准后再提交代码。

Step 4: Commit

步骤4：提交代码

Commit with conventional commit format:

bash

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

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

bash

git add <指定文件>
git commit -m "fix(<范围>): <描述>"

Step 5: Focused Review

步骤5：针对性评审

Run a lightweight review (not the full Review Council):

Security scan (always): Invoke
```
/security-scanning:security-sast
```
on changed files.
Accessibility check (if frontend changes): Invoke
```
/ui-design:accessibility-audit
```
on modified components.

If the security scan finds Critical or High severity issues in the changed files, present them to the user. Fix any legitimate findings before proceeding.

执行轻量化评审（非完整评审委员会流程）：

安全扫描（必须执行）：对变更文件调用
```
/security-scanning:security-sast
```
。
可访问性检查（若涉及前端变更）：对修改的组件调用
```
/ui-design:accessibility-audit
```
。

如果安全扫描在变更文件中发现严重或高危问题，向用户呈现这些问题。在继续前修复所有合理的问题。

Step 6: Deployment Council (Conditional)

步骤6：部署委员会（可选）

Activate the Deployment Council only if the fix involves:

Database migrations
Docker or infrastructure changes
Environment variable modifications
Authentication or authorization code

If none of these apply, skip to Step 7.

If activated, run the Deployment Council evaluation from

.claude/councils/deployment-council.md

with all 3 members (Platform Engineer, Security Engineer, QA Lead).

仅当修复涉及以下内容时，才启动部署委员会流程：

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

如果不涉及以上任何内容，直接跳至步骤7。

若启动该流程，从

.claude/councils/deployment-council.md

中运行部署委员会评估，需包含全部3名成员（平台工程师、安全工程师、QA负责人）。

CHECKPOINT: Deployment Readiness

检查点：部署就绪状态

Present the Deployment Council verdict. Wait for user approval.

呈现部署委员会的评审结果，等待用户批准。

Step 7: Create PR and Monitor CI

步骤7：创建PR并监控CI

Run pre-push checks:

bash

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

Auto-fix formatting issues with

pnpm format

format:check

fails.

Push and create PR:

bash

git push -u origin fix/<short-description>

Generate PR description. Use the template from
```
.github/PULL_REQUEST_TEMPLATE.md
```
if it exists. Include:
- Description of the bug and root cause
- The fix applied
- Tests added
- Related issue number (if applicable)

执行推送前检查：

bash

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

如果

format:check

失败，使用

pnpm format

自动修复格式问题。

推送分支并创建PR：
bash
```
git push -u origin fix/<简短描述>
```
生成PR描述。如果存在
```
.github/PULL_REQUEST_TEMPLATE.md
```
模板，请使用该模板。内容需包含：
- 漏洞描述及根本原因
- 应用的修复方案
- 添加的测试
- 相关问题编号（如有）

CHECKPOINT: PR Description

检查点：PR描述

Present the PR title and body. Wait for user approval.

Create the PR:

bash

gh pr create --title "<title>" --body "<body>"

Monitor CI:

bash

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

Then watch:

bash

gh run watch <run-id> --exit-status

If CI fails, diagnose and fix. Present the fix to the user before committing.

呈现PR标题和正文，等待用户批准。

创建PR：

bash

gh pr create --title "<标题>" --body "<正文>"

监控CI：

bash

gh run list --branch fix/<简短描述> --limit 1 --json databaseId --jq '.[0].databaseId'

随后监控运行状态：

bash

gh run watch <run-id> --exit-status

如果CI失败，排查并修复问题。在提交前向用户呈现修复内容。

Step 8: Hand Off

步骤8：交接

Present the completed hotfix summary:

PR URL
Files changed
Tests added
CI status
Related issue (if applicable)

You completed /hotfix
. The PR is ready for merge. If there is a related GitHub issue, it will close automatically when the PR merges (if the PR body includes
Closes #N
).

呈现已完成的热修复摘要：

PR链接
变更的文件
添加的测试
CI状态
相关问题（如有）

您已完成**
/hotfix
**流程。PR已准备好合并。如果存在相关GitHub问题，当PR合并后会自动关闭（前提是PR正文中包含
Closes #N
）。