Reproduce Bug 是一个与框架无关、以假设驱动的缺陷复现与调查工作流，用于根据 GitHub issue 报告系统地复现并定位缺陷，适用于任意语言、框架或项目类型。整体分为五个阶段。
第一阶段“理解问题”：通过 gh issue view $ARGUMENTS --json title,body,comments,labels,assignees 获取并分析 issue 与评论，提取报告症状、预期行为、复现步骤、环境线索（浏览器、系统、版本、用户角色、数据条件）以及出现频率（必现、偶现或仅一次）。若缺少复现步骤或描述含糊，则记录缺失信息以指导调查。若未提供编号或 URL，会先向用户索取。
第二阶段“提出假设”：使用原生内容搜索工具（如 Claude Code 中的 Grep）查找与症状相关的错误信息、功能名、路由、UI 标签及相关模型/服务/控制器，写出 2-3 个可能原因及其所在文件行范围与产生症状的原因，按可能性排序后从最可能的开始调查。
第三阶段“复现”：分三种路线。测试路线适用于后端、逻辑与数据缺陷，通过原生文件搜索工具（如 Glob）查找已有测试，运行观察是否失败，或编写最小失败测试来验证。浏览器路线适用于 UI、视觉与交互缺陷，使用 agent-browser CLI（不用其他浏览器 MCP 或内置浏览器控制工具），先执行 agent-browser open http://localhost:${PORT:-3000} 与 agent-browser snapshot -i 确认服务运行；端口可从 AGENTS.md、CLAUDE.md、package.json 的 dev 脚本、.env 依次查找，默认 3000，未运行则请用户启动。交互命令包括 click @ref、fill @ref "text"、snapshot -i、screenshot bug-evidence.png，并记录控制台错误与触发步骤。手动路线用于依赖特定数据条件、用户角色或外部服务状态、无法自动化的缺陷，需记录所需条件并请用户确认能否设置。若复现失败，则回到其余假设，检查是否环境相关，并用 git log --oneline -20 -- [affected_files] 查看近期改动。
第四阶段“调查”：结合项目可观测性检查应用日志、错误追踪（Sentry、AppSignal、Bugsnag、Datadog 等）、浏览器控制台、数据库状态与请求/响应周期；再用原生文件读取工具沿代码路径追踪，检查空值、空集合、边界条件、竞态，并用 git log --oneline -10 -- [file] 查找近期变更。
第五阶段“记录发现”：整理根因（含文件路径与行号，如 app/services/example_service.rb:42）、已确认或未确认的复现步骤、证据（截图、测试输出、日志摘录、控制台错误）、建议修复与遗留问题。报告须先呈现给用户，未经明确确认不得向 issue 发表评论或执行任何外部操作。用户选择发表时使用 gh issue comment $ARGUMENTS --body 并附包含根因、已验证复现步骤、相关代码与建议修复的模板。
适用场景为获得 GitHub issue 编号或 URL 后需要复现与调查缺陷。限制：依赖 gh CLI、原生搜索/读取工具与 agent-browser，浏览器路线仅限 agent-browser；其他如收费、平台支持等细节暂未提供。