make-integration-test

star 0

This skill should be used when the user wants to run a full "集成测试" (integration test) pipeline — document quality evaluation followed by integration testing (build, compile, verify). This skill chains two phases: (1) multi-role document evaluation with reports written to Feishu, and (2) simulating a zero-experience developer following the documentation to build, compile, and test a project. Triggers on: "集成测试", "运行集成测试", "make-integration-test", "integration test", "run integration test", "文档集成测试", "接入测试", or when the user explicitly asks to both evaluate docs AND test integration. Do NOT trigger when the user only wants document evaluation (use doc-eval skill instead), or only wants to create code examples (use example-code-creator agent instead).

I-am-shy By I-am-shy schedule Updated 6/2/2026

name: make-integration-test description: > Use this skill when the user wants to run the full ZEGO documentation access-test workflow: documentation evaluation, demo construction, automated demo testing, final cross-stage synthesis, and optional Feishu publication. Triggers on: "集成测试", "接入测试", "文档接入测试", "make-integration-test", "integration test", "run full integration test", or when the user explicitly asks to both evaluate docs and verify a runnable integration demo. Do not use this skill when the user only wants doc evaluation, only wants to build a demo, or only wants to run tests; use the narrower skill directly in those cases. version: 2.0.0

接入测试总控

执行完整接入测试流程:先生成本地阶段产物,再汇总校正,最后按需写入飞书。主会话只接收阶段结论、文件路径、阻塞状态和最终综合判断。

产物目录

报告产物写入仓库根目录:

doc-test-reports/{run-name}/
  run-index.md
  doc-eval/
  build-verification/
  auto-test/
  examples/
    {demo-name}/
  build-test-report.md
  doc-eval-corrected/
  feishu-report-manifest.json
  feishu-report-links.md

示例代码写入:

doc-test-reports/{run-name}/examples/{demo-name}/

demo-name 默认使用:

{product}-{platform}-{scope}-demo

阶段状态

run-index.md 是总控维护的阶段索引。阶段开始、完成、失败、跳过时都要更新 run-index.md

每次启动 subagent 时,prompt 都要包含本次任务简介和用户特殊要求,例如测试目标、文档范围、目标分支、SDK 或测试产物来源、必须覆盖的功能级别、账号/设备/环境要求、报告写法要求等。尽量保留用户原话中的关键短语,避免改写丢信息。

run-index.md 模板:

# {run-name}

## 基本信息

| 字段 | 内容 |
|------|------|
| 产品 | {product} |
| 平台 | {platform} |
| 范围 | {scope} |
| 运行日期 | {date} |
| 目标文档 | {一个或多个文档路径/链接} |
| 示例项目 | doc-test-reports/{run-name}/examples/{demo-name}/ |

## 阶段状态

| 阶段 | 状态 | 摘要文件 | 文档链接 | 说明 |
|------|------|----------|----------|------|
| doc-eval | pending | doc-eval/doc-eval-summary.md | doc-eval/doc-eval-summary.md |  |
| build-verification | pending | build-verification/build-summary.md | build-verification/build-summary.md |  |
| auto-test | pending | auto-test/test-summary.md | auto-test/test-summary.md |  |
| report-publish | pending | feishu-report-links.md | feishu-report-links.md |  |

状态值使用:pendingrunningcompletedfailedblockedskipped文档链接 列初始写本地相对链接;写入飞书后,替换为对应飞书文档链接。

工作流程

Step 1: 收集参数并初始化目录

确认用户已提供或可从文档路径推断以下信息:

  • 产品名称
  • 目标平台
  • 测试范围
  • 一个或多个目标文档路径
  • 运行日期,默认当天,格式 YYYY-MM-DD
  • 是否写入飞书,默认完整流程结束后写入;用户明确要求本地-only 时跳过飞书

生成 run-namedemo-name

run-name = {product}-{platform}-{scope}-{date}
demo-name = {product}-{platform}-{scope}-demo

创建:

doc-test-reports/{run-name}/
doc-test-reports/{run-name}/doc-eval/
doc-test-reports/{run-name}/build-verification/
doc-test-reports/{run-name}/auto-test/
doc-test-reports/{run-name}/examples/{demo-name}/

初始化 run-index.md,将 doc-eval 置为 running

注意:涉及飞书文档的读取等操作时,可根据 lark-wiki,lark-drive,lark-doc 几个 skill 指引进行操作。

Step 2: 文档评测

启动独立 subagent,prompt 要求加载并使用 doc-eval skill,按该 skill 指引完成文档评测;不要在主会话 prompt 中写一套评测流程来替代它。传入:

  • 本次任务简介和用户特殊要求
  • 目标文档列表
  • 产品、平台、范围、日期、run-name
  • 输出目录:doc-test-reports/{run-name}/doc-eval/
  • 飞书写入模式:local-only
  • 固定句式:”加载 doc-eval skill 并按其指引完成文档评测“

要求 subagent 只返回:

## Result

- status: completed / failed / blocked
- summary_file: doc-test-reports/{run-name}/doc-eval/doc-eval-summary.md
- detail_files:
  - doc-test-reports/{run-name}/doc-eval/role-*.md
- document_link: doc-eval/doc-eval-summary.md
- summary: 综合评分 X/5,发现 N 个问题,其中 M 个阻塞
- next_action: continue / stop / needs_user_input

完成后验证文件存在并更新 run-index.md。如果 doc-eval 阻塞,需要把原因写进 run-index.md,由用户决定是否继续后续构建验证。

Step 3: 构建验证

build-verification 置为 running,启动独立 subagent,prompt 要求加载并使用 create-integration-demo skill,按该 skill 指引完成构建验证;不要在主会话 prompt 中写一套构建或代码实现流程来替代它。传入:

  • 本次任务简介和用户特殊要求
  • 目标文档列表
  • 产品、平台、范围、日期、run-namedemo-name
  • 示例项目目录:doc-test-reports/{run-name}/examples/{demo-name}/
  • 报告目录:doc-test-reports/{run-name}/build-verification/
  • 前置输入:doc-test-reports/{run-name}/doc-eval/doc-eval-summary.md
  • doc-eval 阶段返回的关键结论
  • 固定句式:”加载 create-integration-demo skill 并按其指引完成构建验证“

要求 subagent 只返回:

## Result

- status: completed / failed / blocked
- summary_file: doc-test-reports/{run-name}/build-verification/build-summary.md
- detail_files:
  - doc-test-reports/{run-name}/build-verification/build-steps.md
  - doc-test-reports/{run-name}/build-verification/build-issues.md
- demo_dir: doc-test-reports/{run-name}/examples/{demo-name}/
- document_link: build-verification/build-summary.md
- summary: 构建是否成功,发现 N 个问题,其中 M 个阻塞
- next_action: continue / stop / needs_user_input

完成后验证报告和示例项目存在并更新 run-index.md。若构建没有得到可运行入口,将 auto-test 标记为 skippedblocked,并直接进入最终综合。

Step 4: 自动化测试

只有示例项目已经可编译或可运行时才执行。将 auto-test 置为 running,启动独立 subagent,prompt 要求加载并使用 auto-test-demo skill,按该 skill 指引完成自动化测试;不要在主会话 prompt 中写一套测试流程或测试用例清单来替代它。传入:

  • 本次任务简介和用户特殊要求
  • 项目目录:doc-test-reports/{run-name}/examples/{demo-name}/
  • 平台、范围、run-namedemo-name
  • 报告目录:doc-test-reports/{run-name}/auto-test/
  • 前置报告:
    • doc-test-reports/{run-name}/build-verification/build-summary.md
    • doc-test-reports/{run-name}/build-verification/build-issues.md
  • build-verification 阶段返回的关键结论,包括示例项目入口、运行方式、已知问题和不可测试项
  • 固定句式:”加载 auto-test-demo skill 并按其指引完成自动化测试“

要求 subagent 只返回:

## Result

- status: completed / failed / blocked
- summary_file: doc-test-reports/{run-name}/auto-test/test-summary.md
- detail_files:
  - doc-test-reports/{run-name}/auto-test/test-report.md
  - doc-test-reports/{run-name}/auto-test/test-cases.json
  - doc-test-reports/{run-name}/auto-test/test-cases.sh
  - doc-test-reports/{run-name}/auto-test/test-results.jsonl
- artifact_dirs:
  - doc-test-reports/{run-name}/auto-test/logs/
  - doc-test-reports/{run-name}/auto-test/screenshots/
- document_link: auto-test/test-summary.md
- summary: 测试是否通过,通过/失败/跳过用例数,关键失败原因
- next_action: continue / stop / needs_user_input

完成后验证 auto-test-demo 要求的关键产物存在,并更新 run-index.mdauto-test-demo subagent 只负责测试用例设计、测试脚本生成、测试执行、截图、日志采集和失败诊断;不要让它在内部修复 demo 代码或为了通过测试改低预期。

如果自动化测试失败,主会话读取 test-summary.mdtest-report.mdtest-results.jsonl 和必要日志,按失败分析决定是否修复后重测。不要在总控里凭截图或症状重新判断,必须依据 auto-test-demo 已采集的诊断信息。

修复和重测流程:

  1. 判断失败类型:
    • 测试环境或测试脚本问题:例如设备未启动、浏览器会话残留、端口冲突、测试目标连接失败。由主会话修复环境、调整 test-cases.jsonruntime.*Commands 或重新生成测试脚本。
    • demo 实现问题:例如按文档构建出的 demo 代码有实现遗漏、初始化错误、UI 无法触发核心流程。由主会话直接修复 doc-test-reports/{run-name}/examples/{demo-name}/;修复依据必须来自目标文档、构建验证报告和自动化测试失败分析。
    • 文档/SDK/测试产物问题:如果失败原因是文档缺失、SDK 行为异常、测试产物不可用或用户资料不足,可以搜索整个工作区找到必要文档说明后修复,但是要记录为最终主报告的问题证据。
  2. 如果执行了环境、脚本或 demo 修复,主会话先执行必要的编译/运行验证。
  3. 把本轮失败原因、修复内容、验证结果写入:
doc-test-reports/{run-name}/auto-test/repair-attempts.md
  1. 启动新的 auto-test-demo subagent 重测。传入本次任务简介、用户特殊要求、项目目录、报告目录、上一轮测试报告路径、repair-attempts.md,并再次明确要求加载并使用 auto-test-demo skill,只重新测试和诊断,不执行修复。

最多进行 3 轮“主会话修复 + 新 subagent 重测”。每轮都要更新 repair-attempts.mdrun-index.md 说明列。

Step 5: 整理报告发布输入

report-publish 置为 running。确认以下本地产物存在,并整理成给报告发布 subagent 的输入清单:

  • doc-test-reports/{run-name}/doc-eval/doc-eval-summary.md
  • doc-test-reports/{run-name}/doc-eval/role-*.md
  • doc-test-reports/{run-name}/build-verification/build-summary.md
  • doc-test-reports/{run-name}/build-verification/build-issues.md
  • doc-test-reports/{run-name}/auto-test/test-summary.md(如存在)
  • doc-test-reports/{run-name}/auto-test/test-report.md(如存在)
  • doc-test-reports/{run-name}/auto-test/test-results.jsonl(如存在)
  • doc-test-reports/{run-name}/auto-test/screenshots/(如存在)
  • doc-test-reports/{run-name}/auto-test/logs/(如存在)
  • doc-test-reports/{run-name}/examples/{demo-name}/
  • doc-test-reports/{run-name}/run-index.md

不要在主会话里生成最终飞书报告内容。最终飞书报告、校正后 doc-eval 报告和附件上传交给 report-doc-test-in-feishu skill。

Step 6: 按需写入飞书

如果用户要求不写飞书,跳过本步骤,最终回复给出本地目录和关键报告路径。

如果需要写入飞书,启动独立 subagent,prompt 要求加载并使用 report-doc-test-in-feishu skill,按该 skill 指引完成报告创建、内容写入、附件上传和链接回写;不要在主会话 prompt 中写一套飞书报告生成流程来替代它。传入:

  • 本次任务简介和用户特殊要求
  • 本地 run 目录:doc-test-reports/{run-name}/
  • 固定句式:”加载 report-doc-test-in-feishu skill 并按其指引发布飞书报告“

只有在 report-doc-test-in-feishu 无法从 run 目录推断时,才补充传入产品、平台、范围、日期、demo-name、目标文档列表、已有飞书节点或实际 midscene_run 路径。

report-doc-test-in-feishu 必须完成两类飞书报告,并把最终结论集中到 【文档评测报告】汇总报告

  1. 构建与自动化测试报告:根据 build-verification 和 auto-test 生成并写入飞书,同时上传自动化测试报告压缩包、截图、源码压缩包。
  2. 校正后的 doc-eval 报告:根据 build-verification 和 auto-test 校正 doc-eval 本地 Markdown,然后创建并写入各角色报告和 summary 飞书文档。【文档评测报告】汇总报告 是最终主报告,必须合并角色评分、问题摘要、问题详情、构建/测试新增或校正问题。

要求 report subagent 只返回:

## Result

- status: completed / failed / blocked
- feishu_folder: {folder_url}
- build_test_report: {url}
- doc_eval_summary: {url}
- doc_eval_roles:
  - {role-id}: {url}
- local_links_file: doc-test-reports/{run-name}/feishu-report-links.md
- summary: {一句话说明发布结果}
- next_action: continue / stop / needs_user_input

完成后验证 feishu-report-links.mdrun-index.md 已更新。飞书写入失败时不要丢弃本地产物;在 run-index.mdreport-publish 说明列记录失败原因和已完成的本地报告路径。

Step 7: 回复用户

最终回复只给高信号结论:

  • 本地报告目录
  • 如已写飞书,飞书文件夹和最终报告链接
  • 文档评测评分和校正结论
  • 构建是否成功
  • 自动化测试是否通过
  • 阻塞问题数量和最高优先级问题

不要粘贴完整报告内容。

Install via CLI
npx skills add https://github.com/I-am-shy/uikit_docs --skill make-integration-test
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator