bug-report

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Phase 1: Parse Arguments

第一阶段：解析参数

Determine the mode from the argument:

No keyword → Description Mode: generate a structured bug report from the provided description
```
analyze [path]
```
→ Analyze Mode: read the target file(s) and identify potential bugs
```
verify [BUG-ID]
```
→ Verify Mode: confirm a reported fix actually resolved the bug
```
close [BUG-ID]
```
→ Close Mode: mark a verified bug as closed with resolution record

If no argument is provided, ask the user for a bug description before proceeding.

从参数中确定模式：

无关键词 → 描述模式：根据提供的描述生成结构化Bug报告
```
analyze [path]
```
→ 分析模式：读取目标文件并识别潜在Bug
```
verify [BUG-ID]
```
→ 验证模式：确认已报告的修复是否真正解决了Bug
```
close [BUG-ID]
```
→ 关闭模式：将已验证的Bug标记为已关闭并记录解决情况

如果未提供参数，先询问用户获取Bug描述后再继续。

Phase 2A: Description Mode

第二阶段A：描述模式

Parse the description for key information: what broke, when, how to reproduce it, and what the expected behavior is.
Search the codebase for related files using Grep/Glob to add context (affected system, likely files).
Draft the bug report:

markdown

undefined

解析描述以提取关键信息：故障内容、发生时间、复现方式以及预期行为。
搜索代码库，使用Grep/Glob查找相关文件以补充上下文（受影响的系统、可能关联的文件）。
撰写Bug报告：

markdown

undefined

Bug Report

Bug报告

Summary

摘要

Title: [Concise, descriptive title] ID: BUG-[NNNN] Severity: [S1-Critical / S2-Major / S3-Minor / S4-Trivial] Priority: [P1-Immediate / P2-Next Sprint / P3-Backlog / P4-Wishlist] Status: Open Reported: [Date] Reporter: [Name]

标题: [简洁、描述性的标题] ID: BUG-[NNNN] 严重程度: [S1-Critical / S2-Major / S3-Minor / S4-Trivial] 优先级: [P1-Immediate / P2-Next Sprint / P3-Backlog / P4-Wishlist] 状态: 待处理 报告时间: [日期] 报告人: [姓名]

Classification

Environment

环境信息

Build: [Version or commit hash]
Platform: [OS, hardware if relevant]
Scene/Level: [Where in the game]
Game State: [Relevant state -- inventory, quest progress, etc.]

版本: [版本号或提交哈希值]
平台: [操作系统，相关硬件（如有）]
场景/关卡: [游戏内位置]
游戏状态: [相关状态——物品栏、任务进度等]

Reproduction Steps

复现步骤

Preconditions: [Required state before starting]

[Exact step 1]
[Exact step 2]
[Exact step 3]

Expected Result: [What should happen] Actual Result: [What actually happens]

前置条件: [开始前所需的状态]

[具体步骤1]
[具体步骤2]
[具体步骤3]

预期结果: [应该发生的情况] 实际结果: [实际发生的情况]

Technical Context

技术上下文

Likely affected files: [List of files based on codebase search]
Related systems: [What other systems might be involved]
Possible root cause: [If identifiable from the description]

可能受影响的文件: [基于代码库搜索得到的文件列表]
关联系统: [可能涉及的其他系统]
可能的根本原因: [如果从描述中可识别]

Evidence

证据

Logs: [Relevant log output if available]
Visual: [Description of visual evidence]

日志: [相关日志输出（如有）]
视觉证据: [视觉证据的描述]

Related Issues

Notes

备注

[Any additional context or observations]

---

[任何额外的上下文或观察结果]

---

Phase 2B: Analyze Mode

第二阶段B：分析模式

Read the target file(s) specified in the argument.
Identify potential bugs: null references, off-by-one errors, race conditions, unhandled edge cases, resource leaks, incorrect state transitions.
For each potential bug, generate a bug report using the template above, with the likely trigger scenario and recommended fix filled in.

读取参数中指定的目标文件。
识别潜在Bug：空引用、差一错误、竞态条件、未处理的边缘情况、资源泄漏、错误的状态转换。
针对每个潜在Bug，使用上述模板生成Bug报告，并填写可能的触发场景和推荐修复方案。

Phase 2C: Verify Mode

第二阶段C：验证模式

Read

production/qa/bugs/[BUG-ID].md

. Extract the reproduction steps and expected result.

Re-run reproduction steps — use Grep/Glob to check whether the root cause code path still exists as described. If the fix removed or changed it, note the change.
Run the related test — if the bug's system has a test file in
```
tests/
```
, run it via Bash and report pass/fail.
Check for regression — grep the codebase for any new occurrence of the pattern that caused the bug.

Produce a verification verdict:

VERIFIED FIXED — reproduction steps no longer produce the bug; related tests pass
STILL PRESENT — bug reproduces as described; fix did not resolve the issue
CANNOT VERIFY — automated checks inconclusive; manual playtest required

Ask: "May I update

production/qa/bugs/[BUG-ID].md

to set Status: Verified Fixed / Still Present / Cannot Verify?"

If STILL PRESENT: reopen the bug, set Status back to Open, and suggest re-running

/hotfix [BUG-ID]

读取

production/qa/bugs/[BUG-ID].md

。提取复现步骤和预期结果。

重新执行复现步骤——使用Grep/Glob检查根本原因的代码路径是否仍如描述所示存在。如果修复已移除或修改了该路径，记录变更情况。
运行相关测试——如果Bug所属系统在
```
tests/
```
目录下有测试文件，通过Bash运行并报告测试结果（通过/失败）。
检查是否回归——在代码库中搜索导致该Bug的模式是否有新的出现。

生成验证结论：

VERIFIED FIXED（已验证修复）——复现步骤不再触发Bug；相关测试通过
STILL PRESENT（仍存在）——Bug仍按描述复现；修复未解决问题
CANNOT VERIFY（无法验证）——自动化检查结果不确定；需要手动测试

询问：“是否允许我更新

production/qa/bugs/[BUG-ID].md

，将状态设置为：已验证修复 / 仍存在 / 无法验证？”

如果结论为STILL PRESENT：重新打开Bug，将状态改回“待处理”，并建议运行

/hotfix [BUG-ID]

。

Phase 2D: Close Mode

第二阶段D：关闭模式

Read

production/qa/bugs/[BUG-ID].md

. Confirm Status is

Verified Fixed

before closing. If status is anything else, stop: "Bug [ID] must be Verified Fixed before it can be closed. Run

/bug-report verify [BUG-ID]

first."

Append a closure record to the bug file:

markdown

undefined

读取

production/qa/bugs/[BUG-ID].md

。关闭前确认状态为

Verified Fixed

。如果状态为其他值，终止操作：“Bug [ID]必须先标记为已验证修复才能关闭。请先运行

/bug-report verify [BUG-ID]

。”

在Bug文件末尾添加关闭记录：

markdown

undefined

Closure Record

关闭记录

Closed: [date] Resolution: Fixed — [one-line description of what was changed] Fix commit / PR: [if known] Verified by: qa-tester Closed by: [user] Regression test: [test file path, or "Manual verification"] Status: Closed


Update the top-level `**Status**: Open` field to `**Status**: Closed`.

Ask: "May I update `production/qa/bugs/[BUG-ID].md` to mark it Closed?"

After closing, check `production/qa/bug-triage-*.md` — if the bug appears in an open triage report, note: "Bug [ID] is referenced in the triage report. Run `/bug-triage` to refresh the open bug count."

---

关闭时间: [日期] 解决情况: 已修复——[对修改内容的一行描述] 修复提交/PR: [如有] 验证人: qa-tester 关闭人: [用户] 回归测试: [测试文件路径，或“手动验证”] 状态: 已关闭


将顶部的`**状态**: 待处理`字段更新为`**状态**: 已关闭`。

询问：“是否允许我更新`production/qa/bugs/[BUG-ID].md`以标记其为已关闭？”

关闭后，检查`production/qa/bug-triage-*.md`——如果该Bug出现在未处理的分类报告中，提示：“Bug [ID]被引用在分类报告中。请运行`/bug-triage`以刷新未处理Bug的计数。”

---

Phase 3: Save Report

第三阶段：保存报告

Present the completed bug report(s) to the user.

Ask: "May I write this to

production/qa/bugs/BUG-[NNNN].md

If yes, write the file, creating the directory if needed. Verdict: COMPLETE — bug report filed.

If no, stop here. Verdict: BLOCKED — user declined write.

向用户展示完成的Bug报告。

询问：“是否允许我将此报告写入

production/qa/bugs/BUG-[NNNN].md

？”

如果同意，写入文件，必要时创建目录。结论：COMPLETE（完成）——Bug报告已提交。

如果拒绝，终止操作。结论：BLOCKED（已阻止）——用户拒绝写入。

Phase 4: Next Steps

第四阶段：后续步骤

After saving, suggest based on mode:

After filing (Description/Analyze mode):

Run
```
/bug-triage
```
to prioritize alongside existing open bugs
If S1 or S2: run
```
/hotfix [BUG-ID]
```
for emergency fix workflow

After fixing the bug (developer confirms fix is in):

Run
```
/bug-report verify [BUG-ID]
```
— confirm the fix actually works before closing
Never mark a bug closed without verification — a fix that doesn't verify is still Open

After verify returns VERIFIED FIXED:

Run
```
/bug-report close [BUG-ID]
```
— write the closure record and update status
Run
```
/bug-triage
```
to refresh the open bug count and remove it from the active list

保存后，根据模式给出建议：

提交报告后（描述/分析模式）：

运行
```
/bug-triage
```
以与现有未处理Bug一同确定优先级
如果是S1或S2级别：运行
```
/hotfix [BUG-ID]
```
以启动紧急修复流程

修复Bug后（开发者确认修复已提交）：

运行
```
/bug-report verify [BUG-ID]
```
——关闭前确认修复确实有效
未经验证切勿标记Bug为已关闭——未通过验证的修复仍视为待处理

验证返回VERIFIED FIXED后：

运行
```
/bug-report close [BUG-ID]
```
——写入关闭记录并更新状态
运行
```
/bug-triage
```
以刷新未处理Bug计数并将其从活跃列表中移除

bug-report

Original

Translation

Phase 1: Parse Arguments

第一阶段：解析参数

Phase 2A: Description Mode

第二阶段A：描述模式

Bug Report

Bug报告

Summary

摘要

Classification

分类

Environment

环境信息

Reproduction Steps

复现步骤

Technical Context

技术上下文

Evidence

证据

Related Issues

相关问题

Notes

备注

Phase 2B: Analyze Mode

第二阶段B：分析模式

Phase 2C: Verify Mode

第二阶段C：验证模式

Phase 2D: Close Mode

第二阶段D：关闭模式

Closure Record

关闭记录

Phase 3: Save Report

第三阶段：保存报告

Phase 4: Next Steps

第四阶段：后续步骤