Back to Details

create-fix-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create a fix PR

创建修复PR

Overview

概述

You are investigating a problem and filing a pull request that resolves it. This builds on the 
investigate
skill — do the investigation properly first, don't jump to a fix without evidence.
Use the 
gh
CLI for all GitHub operations (auth comes from your 
gh
login) and standard 
Bash
/ 
Edit
/ 
Read
/ 
Grep
for everything else.
你正在调查一个问题并提交解决该问题的拉取请求（PR）。这建立在
investigate
技能的基础上——首先要妥善完成调查，不要在没有证据的情况下直接进行修复。
所有GitHub操作使用
gh
CLI（身份验证来自你的
gh
登录信息），其他操作使用标准的
Bash
/ 
Edit
/ 
Read
/ 
Grep
工具。

Workflow

工作流程

  1. Investigate. Use the 
    investigate
    skill to find the root cause. Cite the exact trace ID, log line, error group, and code location that pins the problem.
  2. Confirm there isn't already a PR open. Before filing anything, search GitHub for an existing open PR addressing the same issue — 
    gh pr list --search "<keywords>" --state open
    . If one exists, direct the user to it — do not create a duplicate.
  3. Judge whether a PR is the right tool. If the fix requires a config change, a flag flip, or a change outside the code you can access, describe the solution instead of filing a PR.
  4. Get the repo. Clone it if you don't already have it locally — 
    gh repo clone <owner>/<repo>
    .
  5. Check for repo conventions. Read 
    agents.md
    or 
    CLAUDE.md
    at the repo root — these describe repo-specific rules your fix needs to respect.
  6. Make the change. Minimal diff. Don't refactor surrounding code, don't add features, don't fix unrelated bugs you happen to notice. One PR, one fix.
  7. Set git identity before committing — see 
    pr-conventions.md
    .
  8. Commit, push, and file the PR. See 
    pr-conventions.md
    for branch naming and PR body rules.
  1. 调查：使用
    investigate
    技能找到问题根源。引用确切的跟踪ID、日志行、错误组和定位问题的代码位置。
  2. 确认没有已开启的PR：在提交任何内容之前，在GitHub上搜索是否已有针对同一问题的开放PR——执行
    gh pr list --search "<关键词>" --state open
    。如果存在，引导用户查看该PR，不要创建重复内容。
  3. 判断PR是否为合适工具：如果修复需要修改配置、切换标志或更改你无法访问的代码，请描述解决方案而非提交PR。
  4. 获取仓库：如果本地没有该仓库，克隆它——执行
    gh repo clone <owner>/<repo>
    。
  5. 查看仓库约定：阅读仓库根目录下的
    agents.md
    或
    CLAUDE.md
    ——这些文件描述了你的修复需要遵守的仓库特定规则。
  6. 进行修改：最小化差异。不要重构周边代码，不要添加功能，不要修复你偶然发现的无关bug。一个PR只解决一个问题。
  7. 提交前设置git身份——参考
    pr-conventions.md
    。
  8. 提交、推送并创建PR：分支命名和PR正文规则参考
    pr-conventions.md
    。

What's a good fix

什么是优质修复

  • Changes the smallest possible number of lines
  • Preserves current production behavior unless the bug IS the current behavior
  • Doesn't depend on assumptions you can't verify from the evidence
  • Would pass a 
    code-review
    skill's check if one existed
  • 修改尽可能少的代码行数
  • 保留当前生产环境行为，除非该行为本身就是bug
  • 不依赖无法从证据中验证的假设
  • 若存在
    code-review
    技能，需能通过其检查

What isn't

什么不是优质修复

  • Sweeping refactors unrelated to the reported problem
  • Speculative null checks or error handling added "while you're in there"
  • Changes to tests that hide the underlying bug
  • Bumping dependency versions to fix a symptom
  • 与报告问题无关的大规模重构
  • 额外添加的推测性空值检查或错误处理（“顺便处理”）
  • 修改测试以掩盖潜在bug
  • 升级依赖版本以解决表面症状

Restricted tools

受限工具

If 
gh
isn't installed or 
gh auth status
shows no auth, surface the error to the user and stop — don't try alternative auth schemes.
如果未安装
gh
或
gh auth status
显示未验证身份，请向用户反馈错误并停止操作——不要尝试其他身份验证方案。

Never include in a PR

PR中绝对不能包含的内容

  • GitHub access tokens or any other secrets or credentials.
  • Debugging logs or print statements you added during investigation.
Follow the repo's own commit and PR conventions for everything else.
  • GitHub访问令牌或任何其他机密凭证。
  • 调查过程中添加的调试日志或打印语句。
其他所有事项请遵循仓库自身的提交和PR约定。