用途：hotfix 用于生产故障、安全补丁、严重回归等紧急修复，走精简流程、跳过多余的 Product/Feature Council 规划环节。它不适合功能开发；若改动新增功能、改变面向用户行为或涉及约 100 行以上代码，应改用 /plan-feature。
主要阶段：先确认修复范围，收集故障现象、错误信息、受影响用户、问题位置、紧急程度及 GitHub issue 编号，可用 gh issue view <number> --json title,body,labels,state,number 读取 issue，并让用户确认这属于 hotfix。随后更新 main 并创建 fix/ 分支：git fetch origin、git checkout main、git pull origin main、git checkout -b fix/<short-description>，排查并给出根因分析。
修复环节做最小改动，补充回归测试，并执行 pnpm type-check、pnpm lint、pnpm test 自检。经用户确认后用约定式提交：git add <specific-files>、git commit -m "fix(<scope>): <description>"。
评审环节为轻量评审：对改动文件运行 /security-scanning:security-sast；如涉及前端改动，运行 /ui-design:accessibility-audit；若发现 Critical 或 High 问题需先修复。仅当涉及数据库迁移、Docker/基础设施变更、环境变量修改或认证授权代码时，才启用 Deployment Council（Platform Engineer、Security Engineer、QA Lead），否则跳过。
最后运行 pnpm type-check && pnpm lint && pnpm format:check && pnpm test（可用 pnpm format 自动修复格式），推送并创建 PR：git push -u origin fix/<short-description>、gh pr create --title "<title>" --body "<body>"。随后用 gh run list 与 gh run watch <run-id> --exit-status 监控 CI，失败则诊断修复并再确认。完成后输出 PR URL、改动文件、测试、CI 状态及相关 issue。
限制：hotfix 应小、聚焦、范围明确，不应用于功能开发；流程含多个需用户确认的检查点；关于收费、平台、效果等信息暂未提供。