用途
reproduce 是一个用于软件工程场景的 AI 技能，目标是判断一个 GitHub issue 是否为有效、可复现的 bug，并产出结构化的 issue 分析产物。它把“复现”定义为在运行中的产品里真实观察到错误行为，而不是阅读源码、分析逻辑或检索编译产物。
主要能力
该技能按六个步骤执行：
- Issue 分类：判断 issue 属于 Bug、功能请求（Feature Request）、问题（Question）还是增强（Enhancement）。如果不是 bug，报告分类并停止；如果 issue 捆绑了多个 bug，要求开发者先拆分。
- 环境搭建：若有产品 zip 则使用，否则从相关分支构建产品。验证端口可用、产品启动并通过健康检查；若搭建失败，报告失败并停止。
- 复现 bug（强制步骤）：必须实际在运行中的产品里触发 bug。前端问题（涉及 UI 行为，如点击、表单、导航）使用 Playwright 驱动真实浏览器，脚本保存为 .ai/reproduce-<issue_number>.mjs 以便 verify-fix 复用；后端问题（涉及 REST API 响应、服务端错误）使用 curl 向运行中的服务器发起真实 HTTP 请求。需采集具体证据：前端为各关键步骤的截图，后端为完整 HTTP 响应（状态码、响应头、响应体）与服务端错误日志。记录基于观察到的预期行为与实际行为。
- 定位相关测试：仅分析与该 issue 相关的单元测试覆盖。
- 编写输出产物：在仓库根目录创建 .ai/ 目录（若不存在），将分析写入 .ai/ia-<issue_number>.md，格式包含分类（类型、严重程度评估、受影响组件、受影响功能）、可复现性（是否可复现、复现方法、环境、执行步骤、预期行为、实际行为、证据）、根因分析、测试覆盖评估（现有测试、覆盖缺口、建议测试计划）。
- 清理：还原任何临时配置或数据改动，确保工作树干净。
使用方式
该技能以 /reproduce 形式调用，遵循上述固定流程。资料中给出的重要规则包括：不得猜测，遇到无法从现有文档解决的歧义须停止并询问开发者；产物优先于记忆，输出产物须完整到让另一个 agent 能接手；服务器启动命令与日志轮询循环必须在同一个 Bash 工具调用中完成，超时设为 200000，不得拆分为多次调用；Playwright 最佳实践为等待元素而非固定 sleep（page.waitForSelector()、page.locator().waitFor()），并清晰记录断言，打印预期与实际值以便产物使用。
适用场景
适用于需要判断 GitHub issue 是否为真实可复现 bug 的软件工程流程，尤其是需要区分前端与后端问题、需要运行时证据而非代码分析的场景。
限制
资料明确强调：代码检查不能算作复现；仅证明页面加载（如 curl 返回 200）不能证明 bug 存在；只有在运行时触发并观察到 bug 才能标记为可复现。若 issue 不是 bug 或捆绑多个 bug，流程会停止或要求拆分。若环境搭建失败，流程也会停止。关于收费、价格、平台支持范围等信息，资料暂未提供。