用途
create-fix-pr 用于针对已报告的 bug 或可观测性发现，调查根因并提交一个最小化的修复 PR。它强调先调查、后修复，不鼓励在没有证据的情况下直接跳到修复方案。
主要能力
- 基于 investigate 技能定位根因，并引用确切的 trace ID、日志行、错误分组和代码位置。
- 在提交前搜索 GitHub 上是否已有处理同一问题的开放 PR，避免重复创建。
- 判断 PR 是否为合适的解决方式：若修复需要配置变更、开关切换或涉及无法访问的代码，则改为描述解决方案而非提交 PR。
- 克隆仓库并阅读仓库根目录的 agents.md 或 CLAUDE.md，遵循仓库特定规则。
- 进行最小改动，保持一次 PR 只解决一个修复。
- 设置 git 身份，按 pr-conventions.md 的规则进行分支命名、提交、推送和创建 PR。
使用方式
所有 GitHub 操作使用 gh CLI（认证来自 gh login），其余操作使用标准 Bash、Edit、Read、Grep。工作流程为：调查根因 → 确认没有已存在的开放 PR → 判断 PR 是否合适 → 获取仓库（如 gh repo clone <owner>/<repo>）→ 检查仓库约定（agents.md 或 CLAUDE.md）→ 进行最小改动 → 设置 git 身份 → 提交、推送并创建 PR。
适用场景
适用于需要针对 bug 或可观测性发现提交修复 PR 的开发工作流，尤其是希望修复范围最小、有证据支撑、并遵循仓库自身约定的情况。
限制
- 若 gh 未安装或 gh auth status 显示未认证，应向用户报错并停止，不尝试其他认证方式。
- PR 中绝不能包含 GitHub 访问令牌或其他密钥、凭据，也不能包含调查期间添加的调试日志或打印语句。
- 好的修复应改动行数最少、保持当前生产行为（除非 bug 本身就是当前行为）、不依赖无法从证据验证的假设。
- 不推荐的修复包括：与报告问题无关的大规模重构、顺手添加的推测性空值检查或错误处理、掩盖底层 bug 的测试改动、为修复症状而升级依赖版本。
- 其他提交和 PR 约定需遵循仓库自身规则。