bug-report

name	bug-report
description	根据描述创建结构化的缺陷报告，或分析代码以识别潜在缺陷。确保每份缺陷报告包含完整的复现步骤、严重程度评估和上下文信息。
argument-hint	[description] /bug-report analyze [path-to-file]
user-invocable	true
allowed-tools	Read, Glob, Grep, Write

当通过描述调用时：

1. 解析描述，提取关键信息。

2. 搜索代码库，使用 Grep/Glob 查找相关文件以补充上下文。

3. 生成缺陷报告：

# 缺陷报告 (Bug Report)

## 概述 (Summary)
**标题**: [简洁、描述性的标题]
**ID**: BUG-[NNNN]
**严重程度 (Severity)**: [S1-严重 / S2-主要 / S3-次要 / S4-微小]
**优先级 (Priority)**: [P1-立即 / P2-下一迭代 / P3-待办 / P4-愿望清单]
**状态**: Open
**报告日期**: [日期]
**报告人**: [姓名]

## 分类 (Classification)
- **类别**: [玩法 / UI / 音频 / 视觉 / 性能 / 崩溃 / 网络]
- **系统**: [受影响的游戏系统]
- **频率**: [总是 / 经常 (>50%) / 有时 (10-50%) / 罕见 (<10%)]
- **回归 (Regression)**: [是/否/未知 —— 之前是否正常工作？]

## 环境 (Environment)
- **构建版本**: [版本号或 commit hash]
- **平台**: [操作系统、硬件（如相关）]
- **场景/关卡**: [游戏中的位置]
- **游戏状态**: [相关状态 —— 背包、任务进度等]

## 复现步骤 (Reproduction Steps)
**前置条件**: [开始前所需的状态]

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

**预期结果**: [应该发生什么]
**实际结果**: [实际发生了什么]

## 技术上下文 (Technical Context)
- **可能受影响的文件**: [基于代码库搜索的文件列表]
- **关联系统**: [可能涉及的其他系统]
- **可能的根本原因**: [如果从描述中可识别]

## 证据 (Evidence)
- **日志**: [相关日志输出（如有）]
- **视觉证据**: [视觉证据的描述]

## 关联问题 (Related Issues)
- [关联缺陷或设计文档的链接]

## 备注 (Notes)
[任何额外的上下文或观察]

当使用 analyze 调用时：

1. 读取目标文件。
2. 识别潜在缺陷：空引用（null reference）、差一错误（off-by-one error）、竞态条件（race condition）、未处理的边界情况、资源泄漏、不正确的状态转换。
3. 针对每个潜在缺陷，生成一份缺陷报告，包含可能的触发场景和修复建议。