Back to Details

fix-issue

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix a reported issue

修复已报告的 issue

A bug report is not a specification. Read the reporter's guesses and you inherit them: you look where they looked, and you stop when the symptom stops. A subagent reads the report and returns only the observable facts. You form your own hypothesis from the code.
Never read the issue yourself — no 
gh issue view
, no 
WebFetch
, no 
Read
on the file, not even later to check a detail. If the extract is thin, 
SendMessage
the extractor agent; its context still holds the report.
bug 报告不是规格说明。一旦读过报告者的猜测，你就会继承这些猜测：你会去他们查看过的地方查问题，并且只要症状消失就停止调查。一个 subagent 负责读取报告，并且只返回可观察到的事实。你则根据代码形成自己的假设。
绝不要亲自阅读 issue——不要使用 
gh issue view
，不要使用 
WebFetch
，也不要使用 
Read
读取文件，即使之后只是为了核对某个细节也不要这样做。如果提取出的事实很少，就向 extractor agent 发送消息；其上下文中仍保留着完整报告。

1. Extract the facts

1. 提取事实

Spawn one 
general-purpose
agent, 
run_in_background: false
, passing the argument through unchanged:
Read the bug report at <ARGUMENT>. For a GitHub issue use 
gh issue view <n> --comments
. For a path, read the file.
Return a factual brief. Your output is the only thing the engineer will see.
Include, each only if the report states it:
  • Symptom — what the user observed, one or two sentences.
  • Expected — what they expected instead.
  • Reproduction — exact steps, inputs, data. Verbatim, never shortened.
  • Evidence — errors, tracebacks, logs, response bodies. Verbatim and complete.
  • Environment — version, branch, database, browser, deployment type.
  • Scope — always or intermittent, one user or all, when it started.
Exclude: any proposed fix, patch, or PR link; any guess at the cause or any file, function, or commit the reporter suspects; "I think" / "probably" / "it looks like" clauses; severity, urgency, blame, +1s, greetings, bot comments; repeated restatements of the symptom.
A traceback is evidence — keep it, though it names files. A commenter writing "the bug is in x.py" is a guess — drop it.
End with Gaps: what a reproduction needs that the report does not give. "none" if complete.
Do not read the codebase, verify anything, or offer an opinion. Under 400 words plus verbatim blocks.
Spawn 一个 
general-purpose
agent，设置 
run_in_background: false
，并原样传入参数：
阅读 <ARGUMENT> 处的 bug 报告。对于 GitHub issue，使用 
gh issue view <n> --comments
。 对于路径，读取该文件。
返回一份事实简报。你的输出将是工程师唯一能看到的内容。
仅在报告明确说明时包含以下各项：
  • 症状——用户观察到的现象，用一两句话描述。
  • 预期结果——用户原本期望出现的结果。
  • 复现步骤——准确的步骤、输入和数据。必须逐字保留，绝不缩短。
  • 证据——错误、traceback、日志和响应正文。必须逐字且完整保留。
  • 环境——版本、分支、数据库、浏览器和部署类型。
  • 影响范围——始终发生还是间歇发生、仅影响一个用户还是所有用户，以及从何时开始。
排除以下内容：任何建议的修复、补丁或 PR 链接；对原因的猜测，以及报告者怀疑的任何文件、函数或 commit；“我认为”／“可能”／“看起来像是”等表述；严重程度、紧急性、责任归咎、+1、问候和机器人评论；对症状的重复描述。
traceback 属于证据——即使其中包含文件名也要保留。评论者声称“bug 在 x.py 中”属于猜测——应当删除。
最后写 缺失信息：复现所需但报告中未提供的信息。如果信息完整，则写“none”。
不要阅读代码库、验证任何内容或提出意见。除逐字引用的块外，控制在 400 词以内。

2. Reproduce before you fix

2. 修复前先复现

Reproduce the symptom from the brief. Three outcomes end the work here, and each is a valid result to report: cannot reproduce and the brief lists gaps; cannot reproduce and the brief is complete (search the log for a commit that already fixed it); or it reproduces but the behaviour is correct.
根据简报复现症状。出现以下三种结果之一时，工作到此结束，每种结果都值得报告：无法复现且简报列出了缺失信息；无法复现但简报完整（在日志中搜索已经修复该问题的 commit）；或者问题可以复现，但实际行为是正确的。

3. Find the cause yourself

3. 自行查找根因

Work backwards from the failure through the code. The report told you where the symptom surfaced, not where the defect is. Fix the cause; if you can only reach the symptom, say so rather than patching it in silence.
从失败现象出发，沿代码反向追踪。报告告诉你症状出现的位置，而不是缺陷所在的位置。修复根因；如果只能追到症状所在位置，就如实说明，不要在未说明的情况下只对症状打补丁。

4. Fix and verify

4. 修复并验证

Smallest change that removes the cause — no refactors, no adjacent fixes. Add a regression test that fails without the change and run it both ways, then the surrounding test module and 
pre-commit run --files <changed files>
.
采用能够消除根因的最小改动——不要重构，也不要顺手修复相邻问题。添加一个在没有该改动时会失败的 regression test，并分别在应用和撤销改动的情况下运行它，然后运行周边测试模块以及 
pre-commit run --files <changed files>
。

5. Review in a separate agent

5. 由独立 agent 审查

Spawn one 
general-purpose
agent, 
run_in_background: false
:
Load the 
frappe-code-review
skill and review the working diff (
git diff
plus any untracked files it adds). The change is meant to fix this bug:
<paste the Symptom and Expected lines from step 1>
Judge two things: does the change stop the bug at its cause or mask the symptom, and the skill's checklist. Report only findings worth acting on, most serious first — file and line, what breaks and for whom, the fix. No summary of the diff. If nothing is worth acting on, say so in one line.
Act on the findings and re-run the tests.
Spawn 一个 
general-purpose
agent，设置 
run_in_background: false
：
加载 
frappe-code-review
skill，并审查工作区中的 diff（
git diff
，以及改动添加的任何未跟踪文件）。该改动用于修复此 bug：
<粘贴第 1 步中的症状和预期结果>
判断以下两点：该改动是在根因处阻止了 bug，还是仅掩盖了症状；以及该改动是否符合 skill 的检查清单。仅报告值得采取行动的问题，按严重程度从高到低排列——文件和行号、会出现什么问题以及影响谁、修复方式。不要总结 diff。如果没有值得处理的问题，用一行说明。
根据审查结果采取行动，并重新运行测试。

6. Report

6. 报告

Four to six lines: the cause, the change, the test, the review outcome, anything unresolved. Commit only if asked; if you do, load 
technical-writing
for the message and add no co-author trailer.
用四到六行说明：根因、改动、测试、审查结论以及所有未解决事项。仅在被要求时提交；如果需要提交，加载 
technical-writing
来撰写提交消息，并且不要添加 co-author trailer。