mcpField
R
reproduce

reproduce

github.com/tharsanan1测试与质量42 次安装
代码仓库

关于 reproduce

供软件工程师判断 GitHub 问题是否为可复现缺陷的分析技能。要求在运行中的产品上观察问题，并生成基于证据的分析文档。

主要功能

  1. 01分类收到的问题
  2. 02启动产品并检查健康状态
  3. 03在运行时复现行为
  4. 04收集浏览器或 API 证据
  5. 05记录分析并清理环境

适用场景

  1. 01用 Playwright 验证界面缺陷
  2. 02用 curl 测试 API 故障
  3. 03生成便于交接的问题分析

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/tharsanan1/wso2-se-agent-skills --skill reproduce

安装后在 Claude Code 中输入/reproduce确认已加载。

详细介绍

/reproduce — 问题分析与 Bug 复现

你是一名软件工程师，需要判断 GitHub 问题是否是有效且可复现的 Bug。请严格按照以下流程操作。

步骤 1：分类问题

判断这是 Bug、功能请求、问题咨询 还是 增强。

  • 如果不是 Bug，报告分类结果并停止。不要继续执行后续步骤。
  • 如果问题包含多个 Bug，请先要求开发者拆分问题，再继续操作。

步骤 2：设置环境

  1. 如果有产品 zip 包，就使用它；否则，从相关分支构建产品。
  2. 验证：端口可用，产品能够启动并通过健康检查。

如果设置失败，报告失败并停止

步骤 3：复现 Bug

此步骤为必做项。必须在运行中的产品里实际触发 Bug。

“复现”是指在运行时观察到 Bug 确实发生，而不是阅读源代码、分析逻辑或搜索编译后的输出。如果你没有通过 Playwright 截图、curl 响应或运行中服务器的日志，亲眼看到实际的错误行为，就不能算作已复现。请勿将其标记为已复现。

代码检查有助于分析根本原因（步骤 5），但不等于复现。必须先完成此步骤，再编写任何根本原因分析。

如何复现
  1. 启动产品服务器，并等待其就绪。
  2. 按照问题中的复现步骤操作（如果未提供，则推断合理的步骤）。
  3. 判断这是 前端 还是 后端 问题：
    • 前端问题（涉及 UI 行为，例如点击、表单、导航）：使用 Playwright 驱动真实浏览器。将脚本保存为 .ai/reproduce-<issue_number>.mjs，以便 verify-fix 重用。请参阅 CLAUDE.md 中的 Playwright 指南。
    • 后端问题（涉及 REST API 响应、服务器错误）：使用 curl 向运行中的服务器发送真实 HTTP 请求。
  4. 收集具体证据：
    • 前端：在每个关键步骤截取屏幕截图，展示实际发生的错误行为。
    • 后端：记录完整的 HTTP 响应（状态码、标头、正文）和服务器错误日志。
  5. 根据你观察到的情况记录预期行为与实际行为，而不是根据代码阅读结果记录。
哪些证据可以证明已复现
  • Playwright 截图显示某个 UI 元素本应显示却被隐藏
  • curl 响应显示本应为 200，却返回 HTTP 500
  • 服务器日志显示你发起的 API 调用过程中发生异常
哪些证据不能证明已复现
  • “代码分析证实了 Bug”——这不算复现
  • “逻辑显示 enableDirectToken 从未恢复”——这是分析，不是复现
  • curl -sk -o /dev/null -w "%{http_code}" <url> 返回 200——这只能证明页面可以加载，不能证明 Bug 存在 **REST API 参考：**请参阅 CLAUDE.md 中的 REST API 参考部分

步骤 4：查找相关测试

仅分析与该问题相关的单元测试覆盖情况。

步骤 5：编写输出文件

如果仓库根目录下不存在 .ai/ 目录，则创建该目录。按照以下确切格式，将分析内容写入 .ai/ia-<issue_number>.md：

# Issue Analysis — [Issue #ID]: [Issue Title]

## Classification
- **Type:** Bug / Not a Bug (with explanation)
- **Severity Assessment:** Critical / High / Medium / Low
- **Affected Component(s):** [component names]
- **Affected Feature(s):** [feature names]

## Reproducibility
- **Reproducible:** Yes / No (ONLY "Yes" if you triggered the bug at runtime and observed it. Code analysis alone = "No")
- **Reproduction method:** Playwright / curl / server logs (specify which)
- **Environment:** [branch, language/runtime version, OS, relevant config]
- **Steps Executed:**
  1. [step]
  2. [step]
- **Expected Behavior:** [what should happen]
- **Actual Behavior:** [what actually happened — describe what you OBSERVED, not what you read in code]
- **Evidence:** [screenshots in .ai/screenshots-<issue_number>/, curl output, or server log excerpts — MUST be from runtime, not code]

## Root Cause Analysis
Brief analysis of what is likely causing the bug based on reproduction results.

## Test Coverage Assessment
- **Existing tests covering this path:** [list test files/functions]
- **Coverage gaps identified:** [paths with no tests]
- **Proposed test plan:**
  - Unit test: [description]
  - Negative/edge cases: [description]

步骤 6：清理

  • 还原所有临时配置或数据更改。
  • 确保工作区干净。

重要规则

  • **切勿猜测。**如果遇到无法根据现有文档消除的歧义，请停止并询问开发者。
  • **以文件为准，而非记忆。**输出文件必须完整到足以让其他 Agent 接手继续处理。
  • **启动服务器：**启动命令和日志轮询循环必须在同一次 Bash 工具调用中执行，并设置 timeout: 200000。不要拆分成多次调用。
  • **Playwright 最佳实践：**等待元素，而不是使用固定延时（page.waitForSelector()、page.locator().waitFor()）。清晰地记录断言——打印预期值与实际值，让输出内容可用于分析文件。

评论

支持 Markdown