Back to Details

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：描述模式

  1. Parse the description for key information: what broke, when, how to reproduce it, and what the expected behavior is.
  2. Search the codebase for related files using Grep/Glob to add context (affected system, likely files).
  3. Draft the bug report:
markdown
undefined
  1. 解析描述以提取关键信息：故障内容、发生时间、复现方式以及预期行为。
  2. 搜索代码库，使用Grep/Glob查找相关文件以补充上下文（受影响的系统、可能关联的文件）。
  3. 撰写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

分类

  • Category: [Gameplay / UI / Audio / Visual / Performance / Crash / Network]
  • System: [Which game system is affected]
  • Frequency: [Always / Often (>50%) / Sometimes (10-50%) / Rare (<10%)]
  • Regression: [Yes/No/Unknown -- was this working before?]
  • 类别: [游戏玩法 / UI / 音频 / 视觉 / 性能 / 崩溃 / 网络]
  • 系统: [受影响的游戏系统]
  • 出现频率: [总是 / 经常(>50%) / 有时(10-50%) / 罕见(<10%)]
  • 是否回归: [是/否/未知——之前是否正常工作？]

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]
  1. [Exact step 1]
  2. [Exact step 2]
  3. [Exact step 3]
Expected Result: [What should happen] Actual Result: [What actually happens]
前置条件: [开始前所需的状态]
  1. [具体步骤1]
  2. [具体步骤2]
  3. [具体步骤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

相关问题

  • [Links to related bugs or design documents]
  • [相关Bug或设计文档的链接]

Notes

备注

[Any additional context or observations]

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

---

Phase 2B: Analyze Mode

第二阶段B：分析模式

  1. Read the target file(s) specified in the argument.
  2. Identify potential bugs: null references, off-by-one errors, race conditions, unhandled edge cases, resource leaks, incorrect state transitions.
  3. For each potential bug, generate a bug report using the template above, with the likely trigger scenario and recommended fix filled in.
  1. 读取参数中指定的目标文件。
  2. 识别潜在Bug：空引用、差一错误、竞态条件、未处理的边缘情况、资源泄漏、错误的状态转换。
  3. 针对每个潜在Bug，使用上述模板生成Bug报告，并填写可能的触发场景和推荐修复方案。

Phase 2C: Verify Mode

第二阶段C：验证模式

Read 
production/qa/bugs/[BUG-ID].md
. Extract the reproduction steps and expected result.
  1. 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.
  2. Run the related test — if the bug's system has a test file in 
    tests/
    , run it via Bash and report pass/fail.
  3. 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
。提取复现步骤和预期结果。
  1. 重新执行复现步骤——使用Grep/Glob检查根本原因的代码路径是否仍如描述所示存在。如果修复已移除或修改了该路径，记录变更情况。
  2. 运行相关测试——如果Bug所属系统在
    tests/
    目录下有测试文件，通过Bash运行并报告测试结果（通过/失败）。
  3. 检查是否回归——在代码库中搜索导致该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计数并将其从活跃列表中移除